Anyone have issues with node communication in a cluster?

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.

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 samueldoyle@gmail.com wrote:

I am testing in a staging environment with several servers but have unable
to successfully get Elasticsearch 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 Elasticsearch after disabling
multicast with no luck.

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
shay.banon@elasticsearch.comwrote:

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 samueldoyle@gmail.comwrote:

I am testing in a staging environment with several servers but have unable
to successfully get Elasticsearch 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 Elasticsearch after disabling
multicast with no luck.

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 samueldoyle@gmail.comwrote:

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 <shay.banon@elasticsearch.com

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 samueldoyle@gmail.comwrote:

I am testing in a staging environment with several servers but have
unable to successfully get Elasticsearch 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 Elasticsearch after disabling
multicast with no luck.

Yeah I tried that as well, no luck.

On Sun, Jul 25, 2010 at 12:32 PM, Shay Banon
shay.banon@elasticsearch.comwrote:

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 samueldoyle@gmail.comwrote:

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 <
shay.banon@elasticsearch.com> 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 samueldoyle@gmail.comwrote:

I am testing in a staging environment with several servers but have
unable to successfully get Elasticsearch 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 Elasticsearch after disabling
multicast with no luck.

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 samueldoyle@gmail.comwrote:

Yeah I tried that as well, no luck.

On Sun, Jul 25, 2010 at 12:32 PM, Shay Banon <shay.banon@elasticsearch.com

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 samueldoyle@gmail.comwrote:

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 <
shay.banon@elasticsearch.com> 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 samueldoyle@gmail.comwrote:

I am testing in a staging environment with several servers but have
unable to successfully get Elasticsearch 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 Elasticsearch after
disabling multicast with no luck.

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 shay.banon@elasticsearch.comwrote:

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 samueldoyle@gmail.comwrote:

Yeah I tried that as well, no luck.

On Sun, Jul 25, 2010 at 12:32 PM, Shay Banon <
shay.banon@elasticsearch.com> 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 samueldoyle@gmail.comwrote:

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 <
shay.banon@elasticsearch.com> 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 samueldoyle@gmail.comwrote:

I am testing in a staging environment with several servers but have
unable to successfully get Elasticsearch 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 Elasticsearch after
disabling multicast with no luck.

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 samueldoyle@gmail.comwrote:

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 shay.banon@elasticsearch.comwrote:

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 samueldoyle@gmail.comwrote:

Yeah I tried that as well, no luck.

On Sun, Jul 25, 2010 at 12:32 PM, Shay Banon <
shay.banon@elasticsearch.com> 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 samueldoyle@gmail.comwrote:

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 <
shay.banon@elasticsearch.com> 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 samueldoyle@gmail.comwrote:

I am testing in a staging environment with several servers but have
unable to successfully get Elasticsearch 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 Elasticsearch
after disabling multicast with no luck.

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 shay.banon@elasticsearch.comwrote:

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 samueldoyle@gmail.comwrote:

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 <shay.banon@elasticsearch.com

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 samueldoyle@gmail.comwrote:

Yeah I tried that as well, no luck.

On Sun, Jul 25, 2010 at 12:32 PM, Shay Banon <
shay.banon@elasticsearch.com> 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 samueldoyle@gmail.comwrote:

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 <
shay.banon@elasticsearch.com> 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 <samueldoyle@gmail.com

wrote:

I am testing in a staging environment with several servers but have
unable to successfully get Elasticsearch 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 Elasticsearch
after disabling multicast with no luck.

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 samueldoyle@gmail.com 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 shay.banon@elasticsearch.comwrote:

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 samueldoyle@gmail.comwrote:

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 <
shay.banon@elasticsearch.com> 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 samueldoyle@gmail.comwrote:

Yeah I tried that as well, no luck.

On Sun, Jul 25, 2010 at 12:32 PM, Shay Banon <
shay.banon@elasticsearch.com> 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 <samueldoyle@gmail.com

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 <
shay.banon@elasticsearch.com> 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 <
samueldoyle@gmail.com> wrote:

I am testing in a staging environment with several servers but have
unable to successfully get Elasticsearch 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 Elasticsearch
after disabling multicast with no luck.

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 samueldoyle@gmail.com 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 samueldoyle@gmail.comwrote:

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 <shay.banon@elasticsearch.com

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 samueldoyle@gmail.comwrote:

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 <
shay.banon@elasticsearch.com> 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 samueldoyle@gmail.comwrote:

Yeah I tried that as well, no luck.

On Sun, Jul 25, 2010 at 12:32 PM, Shay Banon <
shay.banon@elasticsearch.com> 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 <
samueldoyle@gmail.com> 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 <
shay.banon@elasticsearch.com> 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 <
samueldoyle@gmail.com> wrote:

I am testing in a staging environment with several servers but
have unable to successfully get Elasticsearch 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 Elasticsearch
after disabling multicast with no luck.

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 samueldoyle@gmail.com 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 samueldoyle@gmail.comwrote:

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 samueldoyle@gmail.comwrote:

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 <
shay.banon@elasticsearch.com> 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 samueldoyle@gmail.comwrote:

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 <
shay.banon@elasticsearch.com> 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 <samueldoyle@gmail.com

wrote:

Yeah I tried that as well, no luck.

On Sun, Jul 25, 2010 at 12:32 PM, Shay Banon <
shay.banon@elasticsearch.com> 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 <
samueldoyle@gmail.com> 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 <
shay.banon@elasticsearch.com> 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 <
samueldoyle@gmail.com> wrote:

I am testing in a staging environment with several servers but
have unable to successfully get Elasticsearch 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 Elasticsearch
after disabling multicast with no luck.

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 samueldoyle@gmail.com 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 samueldoyle@gmail.comwrote:

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 samueldoyle@gmail.comwrote:

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 samueldoyle@gmail.comwrote:

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 <
shay.banon@elasticsearch.com> 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 samueldoyle@gmail.comwrote:

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 <
shay.banon@elasticsearch.com> 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 <
samueldoyle@gmail.com> wrote:

Yeah I tried that as well, no luck.

On Sun, Jul 25, 2010 at 12:32 PM, Shay Banon <
shay.banon@elasticsearch.com> 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 <
samueldoyle@gmail.com> 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 <
shay.banon@elasticsearch.com> 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 <
samueldoyle@gmail.com> wrote:

I am testing in a staging environment with several servers but
have unable to successfully get Elasticsearch 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 Elasticsearch
after disabling multicast with no luck.