Simultaneous indexing and searching in 2 threads gets "Failed to execute phase" exception

Answers inlined

--
David :wink:
Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs

Le 22 janv. 2015 à 20:19, TimOnGmail timbessie@gmail.com a écrit :

Thanks for your suggestions!

I'm generally created a fresh client for each index/search request. So that's not correct? I had thought it was better to do it that way.

No. You should create a singleton.

Any problems with using separate clients in the same VM, different threads, that you know of?

You don't need them so that's a waste of resources IMHO.

The indexes are already created, incidentally; the calls I'm making are in adding items to the index or in searching the index only.

That's super strange that shards are failing if the index has been created with success.

  • Tim

On Wednesday, January 21, 2015 at 10:57:52 PM UTC-8, David Pilato wrote:
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 timb...@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 elasticsearc...@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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/b81b3d52-a3c0-4222-9009-117ea6f28c93%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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/38937576-391B-4341-B861-338E389B5FFD%40pilato.fr.
For more options, visit https://groups.google.com/d/optout.