# Error in promotion to master?
**URL:** https://discuss.elastic.co/t/error-in-promotion-to-master/2998
**Category:** Elasticsearch
**Created:** [June 6, 2010, 4:26pm UTC](https://discuss.elastic.co/t/error-in-promotion-to-master/2998 "2010-06-06T16:26:26Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@talsalmona](https://discuss.elastic.co/u/talsalmona)
#### Post date: [June 6, 2010, 4:26pm UTC](https://discuss.elastic.co/t/error-in-promotion-to-master/2998/1 "2010-06-06T16:26:26Z")
Hi,
I have the following scenario (Windows Vista, ElasticSearch 0.8.0)
Configuration:
discovery.zen.ping.multicast:
enabled: false
discovery.zen.ping.unicast:
hosts: ["localhost:9300"]
1. Start node A --\> It starts as master.
2. Start node B.
3. Stop A --\> Node B prints that it has been promoted to master.
4. Start node C.
Expected behavior: Node C discovers node B as a master.
Actual Behavior: Node C does not discover B and starts as a new master
Any idea why?
BTW, when I stop node B (A, the master keeps running) and start node C
then node C discovers A as the master.
Thanks,
Tal
---
### Author:  [@kimchy](https://discuss.elastic.co/u/kimchy)
#### Post date: [June 7, 2010, 12:57pm UTC](https://discuss.elastic.co/t/error-in-promotion-to-master/2998/2 "2010-06-07T12:57:07Z")
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.
-shay.banon
On Sun, Jun 6, 2010 at 7:26 PM, Tal [talsalmona@gmail.com](mailto:talsalmona@gmail.com) wrote:
> Hi,
>
> I have the following scenario (Windows Vista, Elasticsearch 0.8.0)
>
> Configuration:
>
> discovery.zen.ping.multicast:
> enabled: false
> discovery.zen.ping.unicast:
> hosts: ["localhost:9300"]
>
> 1. Start node A --\> It starts as master.
> 2. Start node B.
> 3. Stop A --\> Node B prints that it has been promoted to master.
> 4. Start node C.
> Expected behavior: Node C discovers node B as a master.
> Actual Behavior: Node C does not discover B and starts as a new master
>
> Any idea why?
> BTW, when I stop node B (A, the master keeps running) and start node C
> then node C discovers A as the master.
>
> Thanks,
> Tal
---
### Author:  [@talsalmona](https://discuss.elastic.co/u/talsalmona)
#### Post date: [June 7, 2010, 2:29pm UTC](https://discuss.elastic.co/t/error-in-promotion-to-master/2998/3 "2010-06-07T14:29:03Z")
Got it.
Thanks,
Tal
On Jun 7, 3:57 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
> 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.
>
> -shay.banon
>
> On Sun, Jun 6, 2010 at 7:26 PM, Tal [talsalm...@gmail.com](mailto:talsalm...@gmail.com) wrote:
>
> > Hi,
>
> > I have the following scenario (Windows Vista, Elasticsearch 0.8.0)
>
> > Configuration:
>
> > discovery.zen.ping.multicast:
> > enabled: false
> > discovery.zen.ping.unicast:
> > hosts: ["localhost:9300"]
>
> > 1. Start node A --\> It starts as master.
> > 2. Start node B.
> > 3. Stop A --\> Node B prints that it has been promoted to master.
> > 4. Start node C.
> > Expected behavior: Node C discovers node B as a master.
> > Actual Behavior: Node C does not discover B and starts as a new master
>
> > Any idea why?
> > BTW, when I stop node B (A, the master keeps running) and start node C
> > then node C discovers A as the master.
>
> > Thanks,
> > Tal
---
### Author:  [@Lenak](https://discuss.elastic.co/u/Lenak)
#### Post date: [June 8, 2010, 6:43am UTC](https://discuss.elastic.co/t/error-in-promotion-to-master/2998/4 "2010-06-08T06:43:23Z")
Hi,
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:
node:
data: false
client: true
discovery.zen.ping.multicast:
enabled: false
discovery.zen.ping.unicast:
hosts: ["localhost:9300","localhost:9301","localhost:9302"]
and for the data node:
discovery.zen.ping.multicast:
enabled: false
discovery.zen.ping.unicast:
hosts: ["localhost:9300","localhost:9301","localhost:9302"]
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.
Thanks,
Tal
On Jun 7, 5:29 pm, Tal [talsalm...@gmail.com](mailto:talsalm...@gmail.com) wrote:
> Got it.
>
> Thanks,
> Tal
>
> On Jun 7, 3:57 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
>
> > 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.
>
> > -shay.banon
>
> > On Sun, Jun 6, 2010 at 7:26 PM, Tal [talsalm...@gmail.com](mailto:talsalm...@gmail.com) wrote:
> >
> > > Hi,
>
> > > I have the following scenario (Windows Vista, Elasticsearch 0.8.0)
>
> > > Configuration:
>
> > > discovery.zen.ping.multicast:
> > > enabled: false
> > > discovery.zen.ping.unicast:
> > > hosts: ["localhost:9300"]
>
> > > 1. Start node A --\> It starts as master.
> > > 2. Start node B.
> > > 3. Stop A --\> Node B prints that it has been promoted to master.
> > > 4. Start node C.
> > > Expected behavior: Node C discovers node B as a master.
> > > Actual Behavior: Node C does not discover B and starts as a new master
>
> > > Any idea why?
> > > BTW, when I stop node B (A, the master keeps running) and start node C
> > > then node C discovers A as the master.
>
> > > Thanks,
> > > Tal
---
### Author:  [@kimchy](https://discuss.elastic.co/u/kimchy)
#### Post date: [June 8, 2010, 9:20am UTC](https://discuss.elastic.co/t/error-in-promotion-to-master/2998/5 "2010-06-08T09:20:42Z")
mmm, strange... . Let me have a look at this and report back.
-shay.banon
On Tue, Jun 8, 2010 at 9:43 AM, Lenak [lenakovganov@gmail.com](mailto:lenakovganov@gmail.com) wrote:
> Hi,
>
> 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:
>
> node:
> data: false
> client: true
> discovery.zen.ping.multicast:
> enabled: false
> discovery.zen.ping.unicast:
> hosts: ["localhost:9300","localhost:9301","localhost:9302"]
>
> and for the data node:
>
> discovery.zen.ping.multicast:
> enabled: false
> discovery.zen.ping.unicast:
> hosts: ["localhost:9300","localhost:9301","localhost:9302"]
>
> 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.
>
> Thanks,
> Tal
>
> On Jun 7, 5:29 pm, Tal [talsalm...@gmail.com](mailto:talsalm...@gmail.com) wrote:
>
> > Got it.
> >
> > Thanks,
> > Tal
> >
> > On Jun 7, 3:57 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
> >
> > > 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.
> >
> > > -shay.banon
> >
> > > On Sun, Jun 6, 2010 at 7:26 PM, Tal [talsalm...@gmail.com](mailto:talsalm...@gmail.com) wrote:
> > >
> > > > Hi,
> >
> > > > I have the following scenario (Windows Vista, Elasticsearch 0.8.0)
> >
> > > > Configuration:
> >
> > > > discovery.zen.ping.multicast:
> > > > enabled: false
> > > > discovery.zen.ping.unicast:
> > > > hosts: ["localhost:9300"]
> >
> > > > 1. Start node A --\> It starts as master.
> > > > 2. Start node B.
> > > > 3. Stop A --\> Node B prints that it has been promoted to master.
> > > > 4. Start node C.
> > > > Expected behavior: Node C discovers node B as a master.
> > > > Actual Behavior: Node C does not discover B and starts as a new
> > > > master
> >
> > > > Any idea why?
> > > > BTW, when I stop node B (A, the master keeps running) and start node
> > > > C
> > > > then node C discovers A as the master.
> >
> > > > Thanks,
> > > > Tal
---
### Author:  [@talsalmona](https://discuss.elastic.co/u/talsalmona)
#### Post date: [July 30, 2010, 2:00pm UTC](https://discuss.elastic.co/t/error-in-promotion-to-master/2998/6 "2010-07-30T14:00:31Z")
This is fixed in 0.9.0. Client will never become a master.
Tal
On Jun 8, 12:20 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
> mmm, strange... . Let me have a look at this and report back.
>
> -shay.banon
>
> On Tue, Jun 8, 2010 at 9:43 AM, Lenak [lenakovga...@gmail.com](mailto:lenakovga...@gmail.com) wrote:
>
> > Hi,
>
> > 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:
>
> > node:
> > data: false
> > client: true
> > discovery.zen.ping.multicast:
> > enabled: false
> > discovery.zen.ping.unicast:
> > hosts: ["localhost:9300","localhost:9301","localhost:9302"]
>
> > and for the data node:
>
> > discovery.zen.ping.multicast:
> > enabled: false
> > discovery.zen.ping.unicast:
> > hosts: ["localhost:9300","localhost:9301","localhost:9302"]
>
> > 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.
>
> > Thanks,
> > Tal
>
> > On Jun 7, 5:29 pm, Tal [talsalm...@gmail.com](mailto:talsalm...@gmail.com) wrote:
> >
> > > Got it.
>
> > > Thanks,
> > > Tal
>
> > > On Jun 7, 3:57 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
>
> > > > 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.
>
> > > > -shay.banon
>
> > > > On Sun, Jun 6, 2010 at 7:26 PM, Tal [talsalm...@gmail.com](mailto:talsalm...@gmail.com) wrote:
> > > >
> > > > > Hi,
>
> > > > > I have the following scenario (Windows Vista, Elasticsearch 0.8.0)
>
> > > > > Configuration:
>
> > > > > discovery.zen.ping.multicast:
> > > > > enabled: false
> > > > > discovery.zen.ping.unicast:
> > > > > hosts: ["localhost:9300"]
>
> > > > > 1. Start node A --\> It starts as master.
> > > > > 2. Start node B.
> > > > > 3. Stop A --\> Node B prints that it has been promoted to master.
> > > > > 4. Start node C.
> > > > > Expected behavior: Node C discovers node B as a master.
> > > > > Actual Behavior: Node C does not discover B and starts as a new
> > > > > master
>
> > > > > Any idea why?
> > > > > BTW, when I stop node B (A, the master keeps running) and start node
> > > > > C
> > > > > then node C discovers A as the master.
>
> > > > > Thanks,
> > > > > Tal
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 6, 2017, 4:21am UTC](https://discuss.elastic.co/t/error-in-promotion-to-master/2998/7 "2017-07-06T04:21:23Z")