Some ideas: You can/should share the same client within all threads. So only one client for the full JVM. You should create first the index and wait for the index to be created, using actionGet(). It's a quick operation. Then run your code as you wrote.
My 2 cents. David > Le 22 janv. 2015 à 06:12, TimOnGmail <timbes...@gmail.com> a écrit : > > I have a situation where, using the Java API, I initiate a bunch of indexing > operations, but throw away the Future object (I don't need the return > status). This is so I can do a lot of indexing reasonably asynchronously, so > I don't have to hold up the GUI that triggers these calls. > > However, if I fire off these indexing operations, and immediately after do a > search operation on the same index, I get the following exception: > > Caused by: org.elasticsearch.action.search.SearchPhaseExecutionException: > Failed to execute phase [init_scan], all shards failed > at > org.elasticsearch.action.search.type.TransportSearchTypeAction$BaseAsyncAction.onFirstPhaseResult(TransportSearchTypeAction.java:233) > [elasticsearch-1.4.1.jar:] > at > org.elasticsearch.action.search.type.TransportSearchTypeAction$BaseAsyncAction$1.onFailure(TransportSearchTypeAction.java:179) > [elasticsearch-1.4.1.jar:] > at > org.elasticsearch.search.action.SearchServiceTransportAction$23.run(SearchServiceTransportAction.java:565) > [elasticsearch-1.4.1.jar:] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > [rt.jar:1.7.0_60] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > [rt.jar:1.7.0_60] > ... 1 more > > ... however, if I wait awhile after indexing before searching, the search > succeeds, no errors. > > Does anyone know what is going on there? Shouldn't initiating an index > operation asynchronously not affect search operations made in a different > client? > > This is happening only when I use 2 separate threads (and two separate > TransportClients) for each operation... thus: > > 1. Thread 1: Fork Thread 2 > 2. Thread 2: Create new TransportClient; Index list of items, not waiting for > Future objects (i.e. not calling actionGet()) > 3. Thread 1: While Thread 2 is running, create new TransportClient and do > search > 4. Get exception above > > ... compared to: > > 1. Thread 1: Fork Thread 2 > 2. Thread 2: Create new TransportClient; Index list of items, not waiting for > Future objects (i.e. not calling actionGet()) > 3. Wait a bit > 4. Thread 1: (Thread 2 has presumably finished by now); create new > TransportClient and do search > 5. Don't get exception above > > ... also, if, instead, I do it one thread: > > 1. Create new TransportClient; Index list of items, not waiting for Future > objects (i.e. not calling actionGet()) > 2. Close TransportClient > 3. Create new TransportClient; do search > > ... it works fine. So it seems to have something to do with simultaneous > actions on 2 different TransportClients to the same index. It might also > have something to do with internal client state, even though I'm using 2 > separate client objects. > > Does this sound unusual to anyone? > > - Tim > > -- > 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/b1992277-4e72-4ba9-9cdd-f00a6917e55a%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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/2B6FE107-606F-4314-8CC8-D5708ECCFD6F%40pilato.fr. For more options, visit https://groups.google.com/d/optout.
