Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

River name re-use not possible between node shutdowns #1921

Closed
jprante opened this issue May 7, 2012 · 0 comments
Closed

River name re-use not possible between node shutdowns #1921

jprante opened this issue May 7, 2012 · 0 comments

Comments

@jprante
Copy link
Contributor

jprante commented May 7, 2012

While playing with https://github.com/jprante/elasticsearch-river-oai I was looking for a method how to restart rivers gracefully, with slightly modified parameters. I found some interesting behavior on a single node cluster.

  1. After a river is created, a river can be deleted, and a new river with the same river name can be created without problems.

    curl -XPUT 'localhost:9200/_river/my_river/_meta' -d ' { ... }'
    river runs
    curl -XDELETE 'localhost:9200/_river/my_river/'
    river stops
    curl -XPUT 'localhost:9200/_river/my_river/_meta' -d ' { ... }'
    river runs

  2. But when the node is being shutdown after river deletion, and the node is being started up again, there is a response, but no reaction and no activity when re-using the river name.

    curl -XPUT 'localhost:9200/_river/my_river/_meta' -d ' { ... }'
    river runs
    curl -XDELETE 'localhost:9200/_river/my_river/'
    river stops
    node stop
    node start
    curl -XPUT 'localhost:9200/_river/my_river/_meta' -d ' { ... }'
    no river activity

The only workaround I am aware of is to use a different river name, e.g. by enumerating rivers (my_river_1, my_river_2 ...)

Is this behavior intentional? I think it should be possible to re-use a river name in any case.

@kimchy kimchy closed this as completed in ded5b77 Jun 23, 2012
hibnico pushed a commit to hibnico/elasticsearch that referenced this issue Jun 25, 2012
…#1921.

This effectively happens because we don't flush before deleting a mapping, which causes it to still reply the changes happening for it on the transaction log, meaning the mapping are still around on the index level.
mute pushed a commit to mute/elasticsearch that referenced this issue Jul 29, 2015
…#1921.

This effectively happens because we don't flush before deleting a mapping, which causes it to still reply the changes happening for it on the transaction log, meaning the mapping are still around on the index level.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants