-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
INDEX DELETE with wildcard doesn't delete all matching indexes #7295
Comments
@andrassy Could you try this instead:
I suspect that the |
Related to #6736 |
i'm facing the same issue using 1.3.2 |
We still face the same issue with DELETE/event.2013 so it's not explicitly the wildcarding. Sometimes I get an acknowledged:true and other times I get "ProcessClusterEventTimeoutException[failed to process cluster event (delete-index [.......................]) within 30s]". Might be related to #7799 where executions are rejected as the master is stressed (which is why I'm trying to delete lots of historic indexes). |
@clintongormley index delete even without wildcard is failing to remove all indices. Creating 25 indices
Same, but removing with wildcard:
I'm on 1.4.1 |
Logs are here:
This is probably not the best idea to tell user that index is deleted when it is not. |
I could replicate this in master by starting two nodes, then running this shell script:
In the logs were lines like:
The |
Will it return an error if only one index was requested and removal is timed out? What if I pass two indices and both timed out? I think it's better to return an error so clients can implement logic that is sane for them. |
I had a look at this, I see the problem and I will work on fixing it. It all boils down to how delete index works internally. One cluster state update per index gets processed by |
also happens with |
This issue will be solved when we get #11189 in, which is a good fix but needs a proper test written for it. With that fix we will return a reliable last failure at least. That said #11258 (or something along those lines) would improve things even better, as it would treat the request as a single cluster state update task. The annoying part in fact is that we have one single failure in the response at the moment, but that's only the last failure, while we could have more potentially. |
Fixed via #11258 . Closing |
When trying to delete multiple indexes, Issuing a DELETE with a wildcard seems to delete 20 indexes at a time and then returns with an {"acknowledge":"true"}. If this is correct behavior then this should be added to the documentation index\delete documentation, otherwise it needs to be fixed.
For example...
DELETE http://192.168.10.73:55590/*event.2013-* HTTP/1.1
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=UTF-8
Content-Length: 21
{"acknowledged":true}
The text was updated successfully, but these errors were encountered: