When you use unicast discovery, you need to list (as many as you can) nodes
that will form the cluster. In your case, you should list also
"localhost:9301" and "localhost:9302". Its ok if they are not up, as long as
a node that start up with an existing cluster has at least another node to
ask regarding the state of the cluster.
When you use unicast discovery, you need to list (as many as you can) nodes
that will form the cluster. In your case, you should list also
"localhost:9301" and "localhost:9302". Its ok if they are not up, as long as
a node that start up with an existing cluster has at least another node to
ask regarding the state of the cluster.
Another problem I've found is this...
After a client node was promoted to master, new nodes cannot connect
to it (they have the following exception):
[09:24:12,455][WARN ][discovery.zen ] [Oracle] Failed to
send join request to master [[Brand, Abigail][339bdebd-
e4ec-489b-9029-4b4c8eef6d66][inet[/16.59.79.252:9300]]], retrying...
org.elasticsearch.transport.RemoteTransportException: [Oracle][inet[/
16.59.79.252:9300]][discovery/zen/join]
Caused by: org.elasticsearch.ElasticSearchIllegalStateException: Node
[[Oracle][b371a93a-a0e6-44af-b291-78dc091e53a3][inet[/
16.59.79.252:9300]]{client=true, data=false, zen.master=false}] not
master for join request from [[Oracle][b371a93a-a0e6-44af-
b291-78dc091e53a3][inet[/16.59.79.252:9300]]{client=true, data=false,
zen.master=false}]
at
org.elasticsearch.discovery.zen.ZenDiscovery.handleJoinRequest(ZenDiscovery.java:
386)
at org.elasticsearch.discovery.zen.ZenDiscovery.access
$900(ZenDiscovery.java:58)
at org.elasticsearch.discovery.zen.ZenDiscovery
$MembershipListener.onJoin(ZenDiscovery.java:450)
at org.elasticsearch.discovery.zen.membership.MembershipAction
$JoinRequestRequestHandler.messageReceived(MembershipAction.java:113)
at org.elasticsearch.discovery.zen.membership.MembershipAction
$JoinRequestRequestHandler.messageReceived(MembershipAction.java:104)
at org.elasticsearch.transport.netty.MessageChannelHandler
$3.run(MessageChannelHandler.java:175)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
The configuration I used for the client node is this:
Using two data nodes every thing works great.
The reason for this might be that when I start a client node it does
not become a master and although in the scenario mentioned above the
client prints it has become a master it actually did not. I think a
client could become the master in previous versions.
When you use unicast discovery, you need to list (as many as you can) nodes
that will form the cluster. In your case, you should list also
"localhost:9301" and "localhost:9302". Its ok if they are not up, as long as
a node that start up with an existing cluster has at least another node to
ask regarding the state of the cluster.
Another problem I've found is this...
After a client node was promoted to master, new nodes cannot connect
to it (they have the following exception):
[09:24:12,455][WARN ][discovery.zen ] [Oracle] Failed to
send join request to master [[Brand, Abigail][339bdebd-
e4ec-489b-9029-4b4c8eef6d66][inet[/16.59.79.252:9300]]], retrying...
org.elasticsearch.transport.RemoteTransportException: [Oracle][inet[/
16.59.79.252:9300]][discovery/zen/join]
Caused by: org.elasticsearch.ElasticSearchIllegalStateException: Node
[[Oracle][b371a93a-a0e6-44af-b291-78dc091e53a3][inet[/
16.59.79.252:9300]]{client=true, data=false, zen.master=false}] not
master for join request from [[Oracle][b371a93a-a0e6-44af-
b291-78dc091e53a3][inet[/16.59.79.252:9300]]{client=true, data=false,
zen.master=false}]
at
org.elasticsearch.discovery.zen.ZenDiscovery.handleJoinRequest(ZenDiscovery.java:
386)
at org.elasticsearch.discovery.zen.ZenDiscovery.access
$900(ZenDiscovery.java:58)
at org.elasticsearch.discovery.zen.ZenDiscovery
$MembershipListener.onJoin(ZenDiscovery.java:450)
at org.elasticsearch.discovery.zen.membership.MembershipAction
$JoinRequestRequestHandler.messageReceived(MembershipAction.java:113)
at org.elasticsearch.discovery.zen.membership.MembershipAction
$JoinRequestRequestHandler.messageReceived(MembershipAction.java:104)
at org.elasticsearch.transport.netty.MessageChannelHandler
$3.run(MessageChannelHandler.java:175)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
The configuration I used for the client node is this:
Using two data nodes every thing works great.
The reason for this might be that when I start a client node it does
not become a master and although in the scenario mentioned above the
client prints it has become a master it actually did not. I think a
client could become the master in previous versions.
When you use unicast discovery, you need to list (as many as you can)
nodes
that will form the cluster. In your case, you should list also
"localhost:9301" and "localhost:9302". Its ok if they are not up, as
long as
a node that start up with an existing cluster has at least another node
to
ask regarding the state of the cluster.
Another problem I've found is this...
After a client node was promoted to master, new nodes cannot connect
to it (they have the following exception):
[09:24:12,455][WARN ][discovery.zen ] [Oracle] Failed to
send join request to master [[Brand, Abigail][339bdebd-
e4ec-489b-9029-4b4c8eef6d66][inet[/16.59.79.252:9300]]], retrying...
org.elasticsearch.transport.RemoteTransportException: [Oracle][inet[/
16.59.79.252:9300]][discovery/zen/join]
Caused by: org.elasticsearch.ElasticSearchIllegalStateException: Node
[[Oracle][b371a93a-a0e6-44af-b291-78dc091e53a3][inet[/
16.59.79.252:9300]]{client=true, data=false, zen.master=false}] not
master for join request from [[Oracle][b371a93a-a0e6-44af-
b291-78dc091e53a3][inet[/16.59.79.252:9300]]{client=true, data=false,
zen.master=false}]
at
org.elasticsearch.discovery.zen.ZenDiscovery.handleJoinRequest(ZenDiscovery.java:
386)
at org.elasticsearch.discovery.zen.ZenDiscovery.access
$900(ZenDiscovery.java:58)
at org.elasticsearch.discovery.zen.ZenDiscovery
$MembershipListener.onJoin(ZenDiscovery.java:450)
at org.elasticsearch.discovery.zen.membership.MembershipAction
$JoinRequestRequestHandler.messageReceived(MembershipAction.java:113)
at org.elasticsearch.discovery.zen.membership.MembershipAction
$JoinRequestRequestHandler.messageReceived(MembershipAction.java:104)
at org.elasticsearch.transport.netty.MessageChannelHandler
$3.run(MessageChannelHandler.java:175)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
The configuration I used for the client node is this:
Using two data nodes every thing works great.
The reason for this might be that when I start a client node it does
not become a master and although in the scenario mentioned above the
client prints it has become a master it actually did not. I think a
client could become the master in previous versions.
When you use unicast discovery, you need to list (as many as you can)
nodes
that will form the cluster. In your case, you should list also
"localhost:9301" and "localhost:9302". Its ok if they are not up, as
long as
a node that start up with an existing cluster has at least another node
to
ask regarding the state of the cluster.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.