I got this working by creating my own TransportClient instance instead of using the injected Client. Still, it would be nice to understand what's going on here, also locking up the node like this seems like a pretty serious bug.
On Tuesday, February 10, 2015 at 12:27:07 PM UTC, Mauricio Scheffer wrote: > > Hi, I'm writing a plugin that implements a ScoreFunction that needs to > look up some data from a separate index. It does that by having a Client > instance injected. This works perfectly in my box, but when I deploy it to > an EC2 cluster, one of the nodes simply hangs when calling the Client. > The output for /_cat/thread_pool is: > > elasticsearch-cluster3.localdomain 127.0.1.1 0 0 0 0 0 0 3 18 0 > elasticsearch-cluster2.localdomain 127.0.1.1 0 0 0 0 0 0 0 0 0 > elasticsearch-cluster1.localdomain 127.0.1.1 0 0 0 0 0 0 0 0 0 > > those 3 active requests never finish, and even worse, blocks the node > entirely, it stops responding to all other search requests (which get > queued up and eventually the queue fills up and starts rejecting requests). > There is no CPU usage on that hanging node. > Obviously all the nodes are configured identically (deployed through > opsworks). > > Any ideas? I guess injecting Client is not the way to go here? Any > alternatives worth trying? > > Thanks, > Mauricio > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/0a29cd69-bb0d-4a60-9563-28fa694f5a85%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
