Getting a stack trace from Elasticsearch when ever it processes a
delete from a CouchDB river. See https://gist.github.com/1563960
ES seems to be complaining about a version mismatch, but I can't
figure out why.
It means that it tried to delete a document that does not exists in
elasticsearch.
On Thu, Jan 5, 2012 at 8:06 AM, Dan Everton dan@iocaine.org wrote:
Getting a stack trace from Elasticsearch when ever it processes a
delete from a CouchDB river. See Stack trace on delete in Elasticsearch · GitHubES seems to be complaining about a version mismatch, but I can't
figure out why.
On Jan 5, 11:43 pm, Shay Banon kim...@gmail.com wrote:
It means that it tried to delete a document that does not exists in
elasticsearch.
So the next question: is that a problem and is there a way to maybe
suppress that error in this case?
I'm trying to work around the delete event from CouchDB not including
the original document by creating a river for each type of document in
the database. The end result is that all the rivers will get the same
delete event, but only one of them will succeed.
Hrm, actually, maybe it's more complicated than that. The document
being deleted is a child document but since I can't know the parent ID
the routing isn't getting set for the delete. Would this be why I get
the error? The document does exist prior to the delete.
Yes, it sounds like this might be the case, as the document is not routed
to the shard it exists on.
On Fri, Jan 6, 2012 at 12:17 AM, Dan Everton dan@iocaine.org wrote:
Hrm, actually, maybe it's more complicated than that. The document
being deleted is a child document but since I can't know the parent ID
the routing isn't getting set for the delete. Would this be why I get
the error? The document does exist prior to the delete.
Okay, so the delete is then routed to all shards and those that don't
have the document log an error. The delete does actually work as in
the document is gone from the index, but the error messages are a bit
disconcerting. Is there a way to suppress the error logging in this
case? I can set the 'action.bulk' category to be something higher than
TRACE to suppress it, but that means we won't see other bulk errors.
In master those log messages are no longer logged.
On Fri, Jan 6, 2012 at 2:02 AM, Dan Everton dan@iocaine.org wrote:
Okay, so the delete is then routed to all shards and those that don't
have the document log an error. The delete does actually work as in
the document is gone from the index, but the error messages are a bit
disconcerting. Is there a way to suppress the error logging in this
case? I can set the 'action.bulk' category to be something higher than
TRACE to suppress it, but that means we won't see other bulk errors.