In one part of our application we use Elasticsearch as an object store. Therefore, when indexing, we supply our own _id. Likewise, when accessing a document we use the simple GET method to fetch by _id. This has worked well for us, up until recently. Normally, this is what we get:
curl -XGET 'http://127.0.0.1:9200/data-2014.06.06/key/test1?pretty=true' { "_index" : "data-2014.06.06", "_type" : "key", "_id" : "test1", "_version" : 1, "found" : true, "_source":{"sData":"test data 1"} } Now, we often encounter a recently indexed document that throws the following error when we try to fetch it: curl -XGET 'http://127.0.0.1:9200/data-2014.06.06/key/test2?pretty=true' { "error":"IllegalArgumentException[No type mapped for [43]]", "status":500 } This condition persists anywhere from 1 to 25 minutes or so, at which point we no longer receive the error for that document and the GET succeeds as normal. From that point on, we are able to consistently retrieve that document by _id without issue. But, soon after, we will find a different newly indexed document caught in the same bad state. We know the documents are successfully indexed. Our bulk sender (which uses the Java transport client) indicates no error during indexing and we are still able to locate the document by doing an ids query, such as: curl -XPOST "http://127.0.0.1:9200/data-2014.06.06/key/_search?pretty=true"; -d ' { "query": { "ids": { "values": ["test2"] } } }' Which responds: { "took": 543, "timed_out": false, "_shards": { "total": 10, "successful": 10, "failed": 0 }, "hits": { "total": 1, "max_score": 1.0, "hits": [ { "_index": "data-2014.06.06", "_type": "key", "_id": "test2", "_score": 1.0, "_source":{"sData": "test data 2"} } ] } } We first noticed this behavior in version 1.2.0. When we upgraded to 1.2.1, we deleted all indexes and started with a fresh cluster. We hoped our problem would be solved by the big fix that came in 1.2.1, but we are still regularly seeing it. Although our situation may sound like the routing bug introduced in 1.2.0, we are certain that it is not. This appears to be a significant issue with the translog - we hope the developers will be able to look at what may have changed. We did not notice this problem in version 1.1.1. Just in case, here is the mapping being used: curl -XGET 'http://127.0.0.1:9200/data-2014.06.06/key/_mapping?pretty=true' { "data-2014.06.06" : { "mappings" : { "key" : { "_all" : { "enabled" : false }, "properties" : { "sData" : { "type" : "string", "index" : "no" } } } } } } Thanks for your help. -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/20c45cf8-3459-47f5-8cc3-1e63c93b2c0c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
