Anyone have issues with node communication in a cluster?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Anyone have issues with node communication in a cluster?

Samuel Doyle
I am testing in a staging environment with several servers but have unable to successfully get elastic search to recognize each peer.
Multicast is enabled and being used by other parts of our application. I have also tried going the unicast route with elastic search after disabling multicast with no luck.
Reply | Threaded
Open this post in threaded view
|

Re: Anyone have issues with node communication in a cluster?

kimchy
Administrator
Can you post your unicast configuration? In general, you can set discovery.zen to TRACE to see whats going on...

On Sun, Jul 25, 2010 at 8:08 PM, Samuel Doyle <[hidden email]> wrote:
I am testing in a staging environment with several servers but have unable to successfully get elastic search to recognize each peer.
Multicast is enabled and being used by other parts of our application. I have also tried going the unicast route with elastic search after disabling multicast with no luck.

Reply | Threaded
Open this post in threaded view
|

Re: Anyone have issues with node communication in a cluster?

Samuel Doyle
Ah great, I'll give that a shot to see if I can get some more info.

Thanks

Here is a current config, I've been trying various versions.

name: stage01

cluster:
  name: esstagetest

node:
  data: true

http:
  enabled: true

gateway:
  type: fs
  fs:
    location: /home/esearch/gateway/indices

index :
  gateawy:
    snapshot_interval: 30s
  number_of_shards : 5
  number_of_replicas : 4
  analysis :
    analyzer :
      standard :
        type : standard

store:
  type: memory
  memory:
    cache_size: 100m
    buffer_size: 10k

#discovery:
#  zen:
#    ping:
#      multicast:
#        enabled: false
#      unicast:
#        hosts: ["stage01:9301", "stage02:9302"]

transport:
  tcp:
    port: 9300

path:
 logs: /home/esearch/gateway/logs/stage01


On Sun, Jul 25, 2010 at 11:52 AM, Shay Banon <[hidden email]> wrote:
Can you post your unicast configuration? In general, you can set discovery.zen to TRACE to see whats going on...


On Sun, Jul 25, 2010 at 8:08 PM, Samuel Doyle <[hidden email]> wrote:
I am testing in a staging environment with several servers but have unable to successfully get elastic search to recognize each peer.
Multicast is enabled and being used by other parts of our application. I have also tried going the unicast route with elastic search after disabling multicast with no luck.


Reply | Threaded
Open this post in threaded view
|

Re: Anyone have issues with node communication in a cluster?

kimchy
Administrator
Can you try and replace stage01 and stage02 with the actual IPs, maybe they are not resolved properly?

On Sun, Jul 25, 2010 at 10:06 PM, Samuel Doyle <[hidden email]> wrote:
Ah great, I'll give that a shot to see if I can get some more info.

Thanks

Here is a current config, I've been trying various versions.

name: stage01

cluster:
  name: esstagetest

node:
  data: true

http:
  enabled: true

gateway:
  type: fs
  fs:
    location: /home/esearch/gateway/indices

index :
  gateawy:
    snapshot_interval: 30s
  number_of_shards : 5
  number_of_replicas : 4
  analysis :
    analyzer :
      standard :
        type : standard

store:
  type: memory
  memory:
    cache_size: 100m
    buffer_size: 10k

#discovery:
#  zen:
#    ping:
#      multicast:
#        enabled: false
#      unicast:
#        hosts: ["stage01:9301", "stage02:9302"]

transport:
  tcp:
    port: 9300

path:
 logs: /home/esearch/gateway/logs/stage01



On Sun, Jul 25, 2010 at 11:52 AM, Shay Banon <[hidden email]> wrote:
Can you post your unicast configuration? In general, you can set discovery.zen to TRACE to see whats going on...


On Sun, Jul 25, 2010 at 8:08 PM, Samuel Doyle <[hidden email]> wrote:
I am testing in a staging environment with several servers but have unable to successfully get elastic search to recognize each peer.
Multicast is enabled and being used by other parts of our application. I have also tried going the unicast route with elastic search after disabling multicast with no luck.



Reply | Threaded
Open this post in threaded view
|

Re: Anyone have issues with node communication in a cluster?

Samuel Doyle
Yeah I tried that as well, no luck.

On Sun, Jul 25, 2010 at 12:32 PM, Shay Banon <[hidden email]> wrote:
Can you try and replace stage01 and stage02 with the actual IPs, maybe they are not resolved properly?


On Sun, Jul 25, 2010 at 10:06 PM, Samuel Doyle <[hidden email]> wrote:
Ah great, I'll give that a shot to see if I can get some more info.

Thanks

Here is a current config, I've been trying various versions.

name: stage01

cluster:
  name: esstagetest

node:
  data: true

http:
  enabled: true

gateway:
  type: fs
  fs:
    location: /home/esearch/gateway/indices

index :
  gateawy:
    snapshot_interval: 30s
  number_of_shards : 5
  number_of_replicas : 4
  analysis :
    analyzer :
      standard :
        type : standard

store:
  type: memory
  memory:
    cache_size: 100m
    buffer_size: 10k

#discovery:
#  zen:
#    ping:
#      multicast:
#        enabled: false
#      unicast:
#        hosts: ["stage01:9301", "stage02:9302"]

transport:
  tcp:
    port: 9300

path:
 logs: /home/esearch/gateway/logs/stage01



On Sun, Jul 25, 2010 at 11:52 AM, Shay Banon <[hidden email]> wrote:
Can you post your unicast configuration? In general, you can set discovery.zen to TRACE to see whats going on...


On Sun, Jul 25, 2010 at 8:08 PM, Samuel Doyle <[hidden email]> wrote:
I am testing in a staging environment with several servers but have unable to successfully get elastic search to recognize each peer.
Multicast is enabled and being used by other parts of our application. I have also tried going the unicast route with elastic search after disabling multicast with no luck.




Reply | Threaded
Open this post in threaded view
|

Re: Anyone have issues with node communication in a cluster?

kimchy
Administrator
Just saw that (I assume) the configuration you set for stage01 is to start on port 9300, yet you configure it in the unicast hosts with port 9301. Is that intentional?

-shay.banon

On Mon, Jul 26, 2010 at 12:38 AM, Samuel Doyle <[hidden email]> wrote:
Yeah I tried that as well, no luck.


On Sun, Jul 25, 2010 at 12:32 PM, Shay Banon <[hidden email]> wrote:
Can you try and replace stage01 and stage02 with the actual IPs, maybe they are not resolved properly?


On Sun, Jul 25, 2010 at 10:06 PM, Samuel Doyle <[hidden email]> wrote:
Ah great, I'll give that a shot to see if I can get some more info.

Thanks

Here is a current config, I've been trying various versions.

name: stage01

cluster:
  name: esstagetest

node:
  data: true

http:
  enabled: true

gateway:
  type: fs
  fs:
    location: /home/esearch/gateway/indices

index :
  gateawy:
    snapshot_interval: 30s
  number_of_shards : 5
  number_of_replicas : 4
  analysis :
    analyzer :
      standard :
        type : standard

store:
  type: memory
  memory:
    cache_size: 100m
    buffer_size: 10k

#discovery:
#  zen:
#    ping:
#      multicast:
#        enabled: false
#      unicast:
#        hosts: ["stage01:9301", "stage02:9302"]

transport:
  tcp:
    port: 9300

path:
 logs: /home/esearch/gateway/logs/stage01



On Sun, Jul 25, 2010 at 11:52 AM, Shay Banon <[hidden email]> wrote:
Can you post your unicast configuration? In general, you can set discovery.zen to TRACE to see whats going on...


On Sun, Jul 25, 2010 at 8:08 PM, Samuel Doyle <[hidden email]> wrote:
I am testing in a staging environment with several servers but have unable to successfully get elastic search to recognize each peer.
Multicast is enabled and being used by other parts of our application. I have also tried going the unicast route with elastic search after disabling multicast with no luck.





Reply | Threaded
Open this post in threaded view
|

Re: Anyone have issues with node communication in a cluster?

Samuel Doyle
I had tried various configurations this is just the latest, I tried 9300 as well wasn't sure about that.

On Sun, Jul 25, 2010 at 2:40 PM, Shay Banon <[hidden email]> wrote:
Just saw that (I assume) the configuration you set for stage01 is to start on port 9300, yet you configure it in the unicast hosts with port 9301. Is that intentional?

-shay.banon


On Mon, Jul 26, 2010 at 12:38 AM, Samuel Doyle <[hidden email]> wrote:
Yeah I tried that as well, no luck.


On Sun, Jul 25, 2010 at 12:32 PM, Shay Banon <[hidden email]> wrote:
Can you try and replace stage01 and stage02 with the actual IPs, maybe they are not resolved properly?


On Sun, Jul 25, 2010 at 10:06 PM, Samuel Doyle <[hidden email]> wrote:
Ah great, I'll give that a shot to see if I can get some more info.

Thanks

Here is a current config, I've been trying various versions.

name: stage01

cluster:
  name: esstagetest

node:
  data: true

http:
  enabled: true

gateway:
  type: fs
  fs:
    location: /home/esearch/gateway/indices

index :
  gateawy:
    snapshot_interval: 30s
  number_of_shards : 5
  number_of_replicas : 4
  analysis :
    analyzer :
      standard :
        type : standard

store:
  type: memory
  memory:
    cache_size: 100m
    buffer_size: 10k

#discovery:
#  zen:
#    ping:
#      multicast:
#        enabled: false
#      unicast:
#        hosts: ["stage01:9301", "stage02:9302"]

transport:
  tcp:
    port: 9300

path:
 logs: /home/esearch/gateway/logs/stage01



On Sun, Jul 25, 2010 at 11:52 AM, Shay Banon <[hidden email]> wrote:
Can you post your unicast configuration? In general, you can set discovery.zen to TRACE to see whats going on...


On Sun, Jul 25, 2010 at 8:08 PM, Samuel Doyle <[hidden email]> wrote:
I am testing in a staging environment with several servers but have unable to successfully get elastic search to recognize each peer.
Multicast is enabled and being used by other parts of our application. I have also tried going the unicast route with elastic search after disabling multicast with no luck.






Reply | Threaded
Open this post in threaded view
|

Re: Anyone have issues with node communication in a cluster?

kimchy
Administrator
Basically, when you start a node, you see the transport module prints the publish address it uses, this address should be used in the hosts list.

-shay.banon

On Mon, Jul 26, 2010 at 12:50 AM, Samuel Doyle <[hidden email]> wrote:
I had tried various configurations this is just the latest, I tried 9300 as well wasn't sure about that.


On Sun, Jul 25, 2010 at 2:40 PM, Shay Banon <[hidden email]> wrote:
Just saw that (I assume) the configuration you set for stage01 is to start on port 9300, yet you configure it in the unicast hosts with port 9301. Is that intentional?

-shay.banon


On Mon, Jul 26, 2010 at 12:38 AM, Samuel Doyle <[hidden email]> wrote:
Yeah I tried that as well, no luck.


On Sun, Jul 25, 2010 at 12:32 PM, Shay Banon <[hidden email]> wrote:
Can you try and replace stage01 and stage02 with the actual IPs, maybe they are not resolved properly?


On Sun, Jul 25, 2010 at 10:06 PM, Samuel Doyle <[hidden email]> wrote:
Ah great, I'll give that a shot to see if I can get some more info.

Thanks

Here is a current config, I've been trying various versions.

name: stage01

cluster:
  name: esstagetest

node:
  data: true

http:
  enabled: true

gateway:
  type: fs
  fs:
    location: /home/esearch/gateway/indices

index :
  gateawy:
    snapshot_interval: 30s
  number_of_shards : 5
  number_of_replicas : 4
  analysis :
    analyzer :
      standard :
        type : standard

store:
  type: memory
  memory:
    cache_size: 100m
    buffer_size: 10k

#discovery:
#  zen:
#    ping:
#      multicast:
#        enabled: false
#      unicast:
#        hosts: ["stage01:9301", "stage02:9302"]

transport:
  tcp:
    port: 9300

path:
 logs: /home/esearch/gateway/logs/stage01



On Sun, Jul 25, 2010 at 11:52 AM, Shay Banon <[hidden email]> wrote:
Can you post your unicast configuration? In general, you can set discovery.zen to TRACE to see whats going on...


On Sun, Jul 25, 2010 at 8:08 PM, Samuel Doyle <[hidden email]> wrote:
I am testing in a staging environment with several servers but have unable to successfully get elastic search to recognize each peer.
Multicast is enabled and being used by other parts of our application. I have also tried going the unicast route with elastic search after disabling multicast with no luck.







Reply | Threaded
Open this post in threaded view
|

Re: Anyone have issues with node communication in a cluster?

Samuel Doyle
How do I control which port it publishes to, it doesn't appear I have any control over that.

Thanks

On Sun, Jul 25, 2010 at 3:02 PM, Shay Banon <[hidden email]> wrote:
Basically, when you start a node, you see the transport module prints the publish address it uses, this address should be used in the hosts list.

-shay.banon


On Mon, Jul 26, 2010 at 12:50 AM, Samuel Doyle <[hidden email]> wrote:
I had tried various configurations this is just the latest, I tried 9300 as well wasn't sure about that.


On Sun, Jul 25, 2010 at 2:40 PM, Shay Banon <[hidden email]> wrote:
Just saw that (I assume) the configuration you set for stage01 is to start on port 9300, yet you configure it in the unicast hosts with port 9301. Is that intentional?

-shay.banon


On Mon, Jul 26, 2010 at 12:38 AM, Samuel Doyle <[hidden email]> wrote:
Yeah I tried that as well, no luck.


On Sun, Jul 25, 2010 at 12:32 PM, Shay Banon <[hidden email]> wrote:
Can you try and replace stage01 and stage02 with the actual IPs, maybe they are not resolved properly?


On Sun, Jul 25, 2010 at 10:06 PM, Samuel Doyle <[hidden email]> wrote:
Ah great, I'll give that a shot to see if I can get some more info.

Thanks

Here is a current config, I've been trying various versions.

name: stage01

cluster:
  name: esstagetest

node:
  data: true

http:
  enabled: true

gateway:
  type: fs
  fs:
    location: /home/esearch/gateway/indices

index :
  gateawy:
    snapshot_interval: 30s
  number_of_shards : 5
  number_of_replicas : 4
  analysis :
    analyzer :
      standard :
        type : standard

store:
  type: memory
  memory:
    cache_size: 100m
    buffer_size: 10k

#discovery:
#  zen:
#    ping:
#      multicast:
#        enabled: false
#      unicast:
#        hosts: ["stage01:9301", "stage02:9302"]

transport:
  tcp:
    port: 9300

path:
 logs: /home/esearch/gateway/logs/stage01



On Sun, Jul 25, 2010 at 11:52 AM, Shay Banon <[hidden email]> wrote:
Can you post your unicast configuration? In general, you can set discovery.zen to TRACE to see whats going on...


On Sun, Jul 25, 2010 at 8:08 PM, Samuel Doyle <[hidden email]> wrote:
I am testing in a staging environment with several servers but have unable to successfully get elastic search to recognize each peer.
Multicast is enabled and being used by other parts of our application. I have also tried going the unicast route with elastic search after disabling multicast with no luck.








Reply | Threaded
Open this post in threaded view
|

Re: Anyone have issues with node communication in a cluster?

Samuel Doyle
If I specify a network: [some ip address] it then publishes on another differently nic:

[18:44:09,586][INFO ][http                     ] [stage01] bound_address {inet[/0:0:0:0:0:0:0:0:9200]}, publish_address {inet[/192.168.122.1:9200]}
[18:44:09,795][INFO ][jmx                      ] [stage01] bound_address {service:jmx:rmi:///jndi/rmi://:9400/jmxrmi}, publish_address {service:jmx:rmi:///jndi/rmi://192.168.122.1:9400/jmxrmi}

That is not the ip or nic I specify




On Sun, Jul 25, 2010 at 4:38 PM, Samuel Doyle <[hidden email]> wrote:
How do I control which port it publishes to, it doesn't appear I have any control over that.

Thanks


On Sun, Jul 25, 2010 at 3:02 PM, Shay Banon <[hidden email]> wrote:
Basically, when you start a node, you see the transport module prints the publish address it uses, this address should be used in the hosts list.

-shay.banon


On Mon, Jul 26, 2010 at 12:50 AM, Samuel Doyle <[hidden email]> wrote:
I had tried various configurations this is just the latest, I tried 9300 as well wasn't sure about that.


On Sun, Jul 25, 2010 at 2:40 PM, Shay Banon <[hidden email]> wrote:
Just saw that (I assume) the configuration you set for stage01 is to start on port 9300, yet you configure it in the unicast hosts with port 9301. Is that intentional?

-shay.banon


On Mon, Jul 26, 2010 at 12:38 AM, Samuel Doyle <[hidden email]> wrote:
Yeah I tried that as well, no luck.


On Sun, Jul 25, 2010 at 12:32 PM, Shay Banon <[hidden email]> wrote:
Can you try and replace stage01 and stage02 with the actual IPs, maybe they are not resolved properly?


On Sun, Jul 25, 2010 at 10:06 PM, Samuel Doyle <[hidden email]> wrote:
Ah great, I'll give that a shot to see if I can get some more info.

Thanks

Here is a current config, I've been trying various versions.

name: stage01

cluster:
  name: esstagetest

node:
  data: true

http:
  enabled: true

gateway:
  type: fs
  fs:
    location: /home/esearch/gateway/indices

index :
  gateawy:
    snapshot_interval: 30s
  number_of_shards : 5
  number_of_replicas : 4
  analysis :
    analyzer :
      standard :
        type : standard

store:
  type: memory
  memory:
    cache_size: 100m
    buffer_size: 10k

#discovery:
#  zen:
#    ping:
#      multicast:
#        enabled: false
#      unicast:
#        hosts: ["stage01:9301", "stage02:9302"]

transport:
  tcp:
    port: 9300

path:
 logs: /home/esearch/gateway/logs/stage01



On Sun, Jul 25, 2010 at 11:52 AM, Shay Banon <[hidden email]> wrote:
Can you post your unicast configuration? In general, you can set discovery.zen to TRACE to see whats going on...


On Sun, Jul 25, 2010 at 8:08 PM, Samuel Doyle <[hidden email]> wrote:
I am testing in a staging environment with several servers but have unable to successfully get elastic search to recognize each peer.
Multicast is enabled and being used by other parts of our application. I have also tried going the unicast route with elastic search after disabling multicast with no luck.









Reply | Threaded
Open this post in threaded view
|

Re: Anyone have issues with node communication in a cluster?

Samuel Doyle
I've also tried setting the address for multicast seems I have no control over what it does.

On Sun, Jul 25, 2010 at 4:46 PM, Samuel Doyle <[hidden email]> wrote:
If I specify a network: [some ip address] it then publishes on another differently nic:

[18:44:09,586][INFO ][http                     ] [stage01] bound_address {inet[/0:0:0:0:0:0:0:0:9200]}, publish_address {inet[/192.168.122.1:9200]}
[18:44:09,795][INFO ][jmx                      ] [stage01] bound_address {service:jmx:rmi:///jndi/rmi://:9400/jmxrmi}, publish_address {service:jmx:rmi:///jndi/rmi://192.168.122.1:9400/jmxrmi}

That is not the ip or nic I specify





On Sun, Jul 25, 2010 at 4:38 PM, Samuel Doyle <[hidden email]> wrote:
How do I control which port it publishes to, it doesn't appear I have any control over that.

Thanks


On Sun, Jul 25, 2010 at 3:02 PM, Shay Banon <[hidden email]> wrote:
Basically, when you start a node, you see the transport module prints the publish address it uses, this address should be used in the hosts list.

-shay.banon


On Mon, Jul 26, 2010 at 12:50 AM, Samuel Doyle <[hidden email]> wrote:
I had tried various configurations this is just the latest, I tried 9300 as well wasn't sure about that.


On Sun, Jul 25, 2010 at 2:40 PM, Shay Banon <[hidden email]> wrote:
Just saw that (I assume) the configuration you set for stage01 is to start on port 9300, yet you configure it in the unicast hosts with port 9301. Is that intentional?

-shay.banon


On Mon, Jul 26, 2010 at 12:38 AM, Samuel Doyle <[hidden email]> wrote:
Yeah I tried that as well, no luck.


On Sun, Jul 25, 2010 at 12:32 PM, Shay Banon <[hidden email]> wrote:
Can you try and replace stage01 and stage02 with the actual IPs, maybe they are not resolved properly?


On Sun, Jul 25, 2010 at 10:06 PM, Samuel Doyle <[hidden email]> wrote:
Ah great, I'll give that a shot to see if I can get some more info.

Thanks

Here is a current config, I've been trying various versions.

name: stage01

cluster:
  name: esstagetest

node:
  data: true

http:
  enabled: true

gateway:
  type: fs
  fs:
    location: /home/esearch/gateway/indices

index :
  gateawy:
    snapshot_interval: 30s
  number_of_shards : 5
  number_of_replicas : 4
  analysis :
    analyzer :
      standard :
        type : standard

store:
  type: memory
  memory:
    cache_size: 100m
    buffer_size: 10k

#discovery:
#  zen:
#    ping:
#      multicast:
#        enabled: false
#      unicast:
#        hosts: ["stage01:9301", "stage02:9302"]

transport:
  tcp:
    port: 9300

path:
 logs: /home/esearch/gateway/logs/stage01



On Sun, Jul 25, 2010 at 11:52 AM, Shay Banon <[hidden email]> wrote:
Can you post your unicast configuration? In general, you can set discovery.zen to TRACE to see whats going on...


On Sun, Jul 25, 2010 at 8:08 PM, Samuel Doyle <[hidden email]> wrote:
I am testing in a staging environment with several servers but have unable to successfully get elastic search to recognize each peer.
Multicast is enabled and being used by other parts of our application. I have also tried going the unicast route with elastic search after disabling multicast with no luck.










Reply | Threaded
Open this post in threaded view
|

Re: Anyone have issues with node communication in a cluster?

Samuel Doyle
Disregard this, the ip address wasn't set due to a config error I had, I still seem to not be able to set the port however.

Thanks

On Sun, Jul 25, 2010 at 4:59 PM, Samuel Doyle <[hidden email]> wrote:
I've also tried setting the address for multicast seems I have no control over what it does.


On Sun, Jul 25, 2010 at 4:46 PM, Samuel Doyle <[hidden email]> wrote:
If I specify a network: [some ip address] it then publishes on another differently nic:

[18:44:09,586][INFO ][http                     ] [stage01] bound_address {inet[/0:0:0:0:0:0:0:0:9200]}, publish_address {inet[/192.168.122.1:9200]}
[18:44:09,795][INFO ][jmx                      ] [stage01] bound_address {service:jmx:rmi:///jndi/rmi://:9400/jmxrmi}, publish_address {service:jmx:rmi:///jndi/rmi://192.168.122.1:9400/jmxrmi}

That is not the ip or nic I specify





On Sun, Jul 25, 2010 at 4:38 PM, Samuel Doyle <[hidden email]> wrote:
How do I control which port it publishes to, it doesn't appear I have any control over that.

Thanks


On Sun, Jul 25, 2010 at 3:02 PM, Shay Banon <[hidden email]> wrote:
Basically, when you start a node, you see the transport module prints the publish address it uses, this address should be used in the hosts list.

-shay.banon


On Mon, Jul 26, 2010 at 12:50 AM, Samuel Doyle <[hidden email]> wrote:
I had tried various configurations this is just the latest, I tried 9300 as well wasn't sure about that.


On Sun, Jul 25, 2010 at 2:40 PM, Shay Banon <[hidden email]> wrote:
Just saw that (I assume) the configuration you set for stage01 is to start on port 9300, yet you configure it in the unicast hosts with port 9301. Is that intentional?

-shay.banon


On Mon, Jul 26, 2010 at 12:38 AM, Samuel Doyle <[hidden email]> wrote:
Yeah I tried that as well, no luck.


On Sun, Jul 25, 2010 at 12:32 PM, Shay Banon <[hidden email]> wrote:
Can you try and replace stage01 and stage02 with the actual IPs, maybe they are not resolved properly?


On Sun, Jul 25, 2010 at 10:06 PM, Samuel Doyle <[hidden email]> wrote:
Ah great, I'll give that a shot to see if I can get some more info.

Thanks

Here is a current config, I've been trying various versions.

name: stage01

cluster:
  name: esstagetest

node:
  data: true

http:
  enabled: true

gateway:
  type: fs
  fs:
    location: /home/esearch/gateway/indices

index :
  gateawy:
    snapshot_interval: 30s
  number_of_shards : 5
  number_of_replicas : 4
  analysis :
    analyzer :
      standard :
        type : standard

store:
  type: memory
  memory:
    cache_size: 100m
    buffer_size: 10k

#discovery:
#  zen:
#    ping:
#      multicast:
#        enabled: false
#      unicast:
#        hosts: ["stage01:9301", "stage02:9302"]

transport:
  tcp:
    port: 9300

path:
 logs: /home/esearch/gateway/logs/stage01



On Sun, Jul 25, 2010 at 11:52 AM, Shay Banon <[hidden email]> wrote:
Can you post your unicast configuration? In general, you can set discovery.zen to TRACE to see whats going on...


On Sun, Jul 25, 2010 at 8:08 PM, Samuel Doyle <[hidden email]> wrote:
I am testing in a staging environment with several servers but have unable to successfully get elastic search to recognize each peer.
Multicast is enabled and being used by other parts of our application. I have also tried going the unicast route with elastic search after disabling multicast with no luck.











Reply | Threaded
Open this post in threaded view
|

Re: Anyone have issues with node communication in a cluster?

Samuel Doyle
Ok it doesn't really matter the port, I was able to get the multicast working. There are several nics on the servers we have all which indicate that multicast is enabled (or so when I do an ifconfig) but there was some configuration required on one nic on each server which is specific to our private network. The support at our colo. applied whatever changes needed and it is fine now.

Thanks for your help again

On Sun, Jul 25, 2010 at 5:16 PM, Samuel Doyle <[hidden email]> wrote:
Disregard this, the ip address wasn't set due to a config error I had, I still seem to not be able to set the port however.

Thanks


On Sun, Jul 25, 2010 at 4:59 PM, Samuel Doyle <[hidden email]> wrote:
I've also tried setting the address for multicast seems I have no control over what it does.


On Sun, Jul 25, 2010 at 4:46 PM, Samuel Doyle <[hidden email]> wrote:
If I specify a network: [some ip address] it then publishes on another differently nic:

[18:44:09,586][INFO ][http                     ] [stage01] bound_address {inet[/0:0:0:0:0:0:0:0:9200]}, publish_address {inet[/192.168.122.1:9200]}
[18:44:09,795][INFO ][jmx                      ] [stage01] bound_address {service:jmx:rmi:///jndi/rmi://:9400/jmxrmi}, publish_address {service:jmx:rmi:///jndi/rmi://192.168.122.1:9400/jmxrmi}

That is not the ip or nic I specify





On Sun, Jul 25, 2010 at 4:38 PM, Samuel Doyle <[hidden email]> wrote:
How do I control which port it publishes to, it doesn't appear I have any control over that.

Thanks


On Sun, Jul 25, 2010 at 3:02 PM, Shay Banon <[hidden email]> wrote:
Basically, when you start a node, you see the transport module prints the publish address it uses, this address should be used in the hosts list.

-shay.banon


On Mon, Jul 26, 2010 at 12:50 AM, Samuel Doyle <[hidden email]> wrote:
I had tried various configurations this is just the latest, I tried 9300 as well wasn't sure about that.


On Sun, Jul 25, 2010 at 2:40 PM, Shay Banon <[hidden email]> wrote:
Just saw that (I assume) the configuration you set for stage01 is to start on port 9300, yet you configure it in the unicast hosts with port 9301. Is that intentional?

-shay.banon


On Mon, Jul 26, 2010 at 12:38 AM, Samuel Doyle <[hidden email]> wrote:
Yeah I tried that as well, no luck.


On Sun, Jul 25, 2010 at 12:32 PM, Shay Banon <[hidden email]> wrote:
Can you try and replace stage01 and stage02 with the actual IPs, maybe they are not resolved properly?


On Sun, Jul 25, 2010 at 10:06 PM, Samuel Doyle <[hidden email]> wrote:
Ah great, I'll give that a shot to see if I can get some more info.

Thanks

Here is a current config, I've been trying various versions.

name: stage01

cluster:
  name: esstagetest

node:
  data: true

http:
  enabled: true

gateway:
  type: fs
  fs:
    location: /home/esearch/gateway/indices

index :
  gateawy:
    snapshot_interval: 30s
  number_of_shards : 5
  number_of_replicas : 4
  analysis :
    analyzer :
      standard :
        type : standard

store:
  type: memory
  memory:
    cache_size: 100m
    buffer_size: 10k

#discovery:
#  zen:
#    ping:
#      multicast:
#        enabled: false
#      unicast:
#        hosts: ["stage01:9301", "stage02:9302"]

transport:
  tcp:
    port: 9300

path:
 logs: /home/esearch/gateway/logs/stage01



On Sun, Jul 25, 2010 at 11:52 AM, Shay Banon <[hidden email]> wrote:
Can you post your unicast configuration? In general, you can set discovery.zen to TRACE to see whats going on...


On Sun, Jul 25, 2010 at 8:08 PM, Samuel Doyle <[hidden email]> wrote:
I am testing in a staging environment with several servers but have unable to successfully get elastic search to recognize each peer.
Multicast is enabled and being used by other parts of our application. I have also tried going the unicast route with elastic search after disabling multicast with no luck.