NodeClosedException trying to close a local node

Elastic Stack Elasticsearch
1

Hi,

for testing purpose I am using a client created from a node configured to be local [nodeBuilder.local(true)]. Every time I call close() on that node I get the following exception:

org.elasticsearch.node.NodeClosedException: node closed [Junta][1][local[1]]{local=true}
at org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction$3.onClose(TransportShardReplicationOperationAction.java:392)
at org.elasticsearch.cluster.service.InternalClusterService.doStop(InternalClusterService.java:106)
at org.elasticsearch.common.component.AbstractLifecycleComponent.stop(AbstractLifecycleComponent.java:98)
at org.elasticsearch.node.internal.InternalNode.stop(InternalNode.java:221)
at org.elasticsearch.node.internal.InternalNode.close(InternalNode.java:242)

even if I am sure it's the first time I close the node. Is there an automatic mechanism that closes it? Anyway if I don't call close() the test runs forever. Any suggestion to fix that?

More in general (and even worse) there is no way to check if a Node has been already closed or not and the exception is thrown in a separate thread so there is no way to catch it. Is there something that I am missing?

Cheers,
Mario

2

The failure is logged because there is an operation still happening (index request for example) and its being aborted because the node is being closed. Its fine to ignore it in your test.

You can call close() how many times you want, only the first one will cause the node to be closed, no harm in calling it again.

On Wednesday, June 22, 2011 at 5:21 PM, Mario Fusco wrote:

Hi,

for testing purpose I am using a client created from a node configured to be
local [nodeBuilder.local(true)]. Every time I call close() on that node I
get the following exception:

org.elasticsearch.node.NodeClosedException: node closed
[Junta][1][local[1]]{local=true}
at
org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction$3.onClose(TransportShardReplicationOperationAction.java:392)
at
org.elasticsearch.cluster.service.InternalClusterService.doStop(InternalClusterService.java:106)
at
org.elasticsearch.common.component.AbstractLifecycleComponent.stop(AbstractLifecycleComponent.java:98)
at org.elasticsearch.node.internal.InternalNode.stop(InternalNode.java:221)
at
org.elasticsearch.node.internal.InternalNode.close(InternalNode.java:242)

even if I am sure it's the first time I close the node. Is there an
automatic mechanism that closes it? Anyway if I don't call close() the test
runs forever. Any suggestion to fix that?

More in general (and even worse) there is no way to check if a Node has been
already closed or not and the exception is thrown in a separate thread so
there is no way to catch it. Is there something that I am missing?

Cheers,
Mario

--
View this message in context: http://elasticsearch-users.115913.n3.nabble.com/NodeClosedException-trying-to-close-a-local-node-tp3095740p3095740.html
Sent from the Elasticsearch Users mailing list archive at Nabble.com (http://Nabble.com).

3
The failure is logged because there is an operation still happening (index request for example) and its being aborted because the node is being closed. Its fine to ignore it in your test.

You can call close() how many times you want, only the first one will cause the node to be closed, no harm in calling it again.

Unfortunately it is not that simple. What you wrote is true in Java if you use Maven as building-tool, but it isn't in Scala while using sbt. As I said the Exception is thrown in a separate thread so Maven (or Ant) happily ignore it while running the test. Sbt is more smart, so it's capable to recognize that a thread (even if not the main one) failed by throwing an Exception during the execution of the test and then it makes your test failing as well.

Is there a way I can work around this problem?

4

Do you execute any operation in an async manner (not waiting for the response)?

On Saturday, June 25, 2011 at 12:03 PM, Mario Fusco wrote:

kimchy wrote:

The failure is logged because there is an operation still happening (index
request for example) and its being aborted because the node is being
closed. Its fine to ignore it in your test.

You can call close() how many times you want, only the first one will
cause the node to be closed, no harm in calling it again.

Unfortunately it is not that simple. What you wrote is true in Java if you
use Maven as building-tool, but it isn't in Scala while using sbt. As I said
the Exception is thrown in a separate thread so Maven (or Ant) happily
ignore it while running the test. Sbt is more smart, so it's capable to
recognize that a thread (even if not the main one) failed by throwing an
Exception during the execution of the test and then it makes your test
failing as well.

Is there a way I can work around this problem?

--
View this message in context: http://elasticsearch-users.115913.n3.nabble.com/NodeClosedException-trying-to-close-a-local-node-tp3095740p3107389.html
Sent from the Elasticsearch Users mailing list archive at Nabble.com (http://Nabble.com).

5

Is there a way I can work around this problem?

Try to make sure e.g. indexing operations are done (call refresh after
them)

6

Just to fix a (seem to be) common mistake. When you index a document, its indexed, you don't need to call refresh to "wait for it to be indexed". Refresh makes it visible for search, which is a different matter.

Regarding what I mean, using the Java API, this code for example will produce the mentioned failure:

node.client().prepareIndex(...).execute();
node.close();

Why? because execute just returns a future, it does not wait for the operation to be executed (possibly on another node, possibly replicated, yada yada yada). If you want to wait for the index operation to happen, you can call (note the actionGet):

node.client().prepareIndex(...).execute().actionGet();
node.close();

On Tuesday, July 5, 2011 at 12:53 AM, Karussell wrote:

Is there a way I can work around this problem?

Try to make sure e.g. indexing operations are done (call refresh after
them)