# Can connect with http, but NOT through Java API
**URL:** https://discuss.elastic.co/t/can-connect-with-http-but-not-through-java-api/8754
**Category:** Elasticsearch
**Created:** [August 15, 2012, 11:18pm UTC](https://discuss.elastic.co/t/can-connect-with-http-but-not-through-java-api/8754 "2012-08-15T23:18:26Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@phill](https://discuss.elastic.co/u/phill)
#### Post date: [August 15, 2012, 11:18pm UTC](https://discuss.elastic.co/t/can-connect-with-http-but-not-through-java-api/8754/1 "2012-08-15T23:18:26Z")
Can anyone explain what is going on? Did I code the following Java
wrong or did someone move some cables or port configuration on me?
1. I can use http REST from a Firefox browser and get information from
an index:
[http://172.16.0.164:9200/test\_index0\_copy/\_status?pretty=1](http://172.16.0.164:9200/test_index0_copy/_status?pretty=1)
{
"ok" : true,
"\_shards" : {
"total" : 9,
"successful" : 3,
"failed" : 0
},
"indices" : {
"test\_index0\_copy" : {
"index" : {
"primary\_size" : "521.4mb",
"primary\_size\_in\_bytes" : 546827732,
"size" : "521.4mb",
"size\_in\_bytes" : 546827732
},
"translog" : {
"operations" : 0
},
...
and
[http://172.16.0.164:9200/\_cluster/nodes/stats?pretty=true](http://172.16.0.164:9200/_cluster/nodes/stats?pretty=true)
shows
{
"cluster\_name" : "metajure",
"nodes" : {
"Nfs\_5wldQEi0TO9QR0a1Cg" : {
"timestamp" : 1345072330400,
"name" : "Zartra",
"transport\_address" : "inet[/172.16.0.164:9300]",
and
curl -XGET
'[http://172.16.0.164:9200/test\_index0\_copy/\_search?q=text:company&pretty=true](http://172.16.0.164:9200/test_index0_copy/_search?q=text:company&pretty=true)'
gets a page of results
But
2. I can NOT connect from the same machine via the Java API using the
following code (using the other appropriate port, 9300 as shown) running
in Eclipse.
private static TransportClient connectToElasticSearch() {
```
Settings settings;
// once we find one node in the cluster ask about the others
Builder settingsBuilder = ImmutableSettings.settingsBuilder().put("client.transport.sniff", true);
settingsBuilder.put("cluster.name", "metajure");
settingsBuilder.put("client.transport.ping_timeout", "10s");
settings = settingsBuilder.build();
return new TransportClient(settings).addTransportAddress(new InetSocketTransportAddress("172.16.0.164", 9300));
}
```
The above code dies when it tries to addTransportAddress and I get the
trace listed below:
Does the line just above the stack trace:
"DEBUG - [Contemplator] connected to node
[[#transport#-1][inet[/172.16.0.164:9300]]]"
Actual mean it got there, but that something got garbled on the return
as stated in the next line:
"INFO - [Contemplator] failed to get local cluster state for
[#transport#-1][inet[/172.16.0.164:9300]], disconnecting..."
?
Any suggestions on how to track down where the problem lies would be
appreciated. There are NO extra JVMs running on the machine running the
above code.
-Paul
INFO - [Contemplator] loaded [], sites []
DEBUG - using [UnsafeChunkDecoder] decoder
DEBUG - [Contemplator] creating thread\_pool [generic], type [cached],
keep\_alive [30s]
DEBUG - [Contemplator] creating thread\_pool [index], type [cached],
keep\_alive [5m]
DEBUG - [Contemplator] creating thread\_pool [bulk], type [cached],
keep\_alive [5m]
DEBUG - [Contemplator] creating thread\_pool [get], type [cached],
keep\_alive [5m]
DEBUG - [Contemplator] creating thread\_pool [search], type [cached],
keep\_alive [5m]
DEBUG - [Contemplator] creating thread\_pool [percolate], type [cached],
keep\_alive [5m]
DEBUG - [Contemplator] creating thread\_pool [management], type
[scaling], min [1], size [5], keep\_alive [5m]
DEBUG - [Contemplator] creating thread\_pool [flush], type [scaling], min
[1], size [10], keep\_alive [5m]
DEBUG - [Contemplator] creating thread\_pool [merge], type [scaling], min
[1], size [20], keep\_alive [5m]
DEBUG - [Contemplator] creating thread\_pool [refresh], type [cached],
keep\_alive [1m]
DEBUG - [Contemplator] creating thread\_pool [cache], type [scaling], min
[1], size [4], keep\_alive [5m]
DEBUG - [Contemplator] creating thread\_pool [snapshot], type [scaling],
min [1], size [5], keep\_alive [5m]
DEBUG - [Contemplator] using worker\_count[16], port[9300-9400],
bind\_host[null], publish\_host[null], compress[false],
connect\_timeout[30s], connections\_per\_node[2/6/1]
DEBUG - [Contemplator] node\_sampler\_interval[5s]
DEBUG - Using the autodetected NIO constraint level: 0
DEBUG - [Contemplator] adding address
[[#transport#-1][inet[/172.16.0.164:9300]]]
DEBUG - [Contemplator] connected to node
[[#transport#-1][inet[/172.16.0.164:9300]]]
INFO - [Contemplator] failed to get local cluster state for
[#transport#-1][inet[/172.16.0.164:9300]], disconnecting...
org.elasticsearch.transport.RemoteTransportException: Failed to
deserialize response of type
[org.elasticsearch.action.admin.cluster.state.ClusterStateResponse]
Caused by: org.elasticsearch.transport.TransportSerializationException:
Failed to deserialize response of type
[org.elasticsearch.action.admin.cluster.state.ClusterStateResponse]
at
org.elasticsearch.transport.netty.MessageChannelHandler.handleResponse(MessageChannelHandler.java:150)
at
org.elasticsearch.transport.netty.MessageChannelHandler.messageReceived(MessageChannelHandler.java:127)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:75)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:563)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at
org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:458)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:439)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:75)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:563)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:558)
at
org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
at
org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:91)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:373)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:247)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)
at
org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:102)
at
org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.IndexOutOfBoundsException: Readable byte limit
exceeded: 110
at
org.jboss.netty.buffer.AbstractChannelBuffer.readByte(AbstractChannelBuffer.java:236)
at
org.elasticsearch.transport.netty.ChannelBufferStreamInput.readByte(ChannelBufferStreamInput.java:126)
at
org.elasticsearch.common.io.stream.StreamInput.readString(StreamInput.java:178)
at
org.elasticsearch.common.io.stream.StreamInput.readUTF(StreamInput.java:207)
at
org.elasticsearch.common.io.stream.HandlesStreamInput.readUTF(HandlesStreamInput.java:50)
at
org.elasticsearch.cluster.routing.ImmutableShardRouting.readFromThin(ImmutableShardRouting.java:200)
at
org.elasticsearch.cluster.routing.ImmutableShardRouting.readFrom(ImmutableShardRouting.java:189)
at
org.elasticsearch.cluster.routing.ImmutableShardRouting.readShardRoutingEntry(ImmutableShardRouting.java:182)
at
org.elasticsearch.cluster.routing.IndexShardRoutingTable$Builder.readFromThin(IndexShardRoutingTable.java:463)
at
org.elasticsearch.cluster.routing.IndexRoutingTable$Builder.readFrom(IndexRoutingTable.java:256)
at
org.elasticsearch.cluster.routing.RoutingTable$Builder.readFrom(RoutingTable.java:387)
at
org.elasticsearch.cluster.ClusterState$Builder.readFrom(ClusterState.java:252)
at
org.elasticsearch.action.admin.cluster.state.ClusterStateResponse.readFrom(ClusterStateResponse.java:66)
at
org.elasticsearch.transport.netty.MessageChannelHandler.handleResponse(MessageChannelHandler.java:148)
... 22 more
-Paul
--
---
### Author:  [@Ivan](https://discuss.elastic.co/u/Ivan)
#### Post date: [August 15, 2012, 11:35pm UTC](https://discuss.elastic.co/t/can-connect-with-http-but-not-through-java-api/8754/2 "2012-08-15T23:35:09Z")
Is port 9300 open? Can you do a simple telnet to it?
On Wed, Aug 15, 2012 at 4:19 PM, P. Hill [parehill1@gmail.com](mailto:parehill1@gmail.com) wrote:
> Can anyone explain what is going on? Did I code the following Java wrong or
> did someone move some cables or port configuration on me?
>
> 1. I can use http REST from a Firefox browser and get information from an
> index:
> [http://172.16.0.164:9200/test\_index0\_copy/\_status?pretty=1](http://172.16.0.164:9200/test_index0_copy/_status?pretty=1)
>
> {
> "ok" : true,
> "\_shards" : {
> "total" : 9,
> "successful" : 3,
> "failed" : 0
> },
> "indices" : {
> "test\_index0\_copy" : {
> "index" : {
> "primary\_size" : "521.4mb",
> "primary\_size\_in\_bytes" : 546827732,
> "size" : "521.4mb",
> "size\_in\_bytes" : 546827732
> },
> "translog" : {
> "operations" : 0
> },
> ...
> and
> [http://172.16.0.164:9200/\_cluster/nodes/stats?pretty=true](http://172.16.0.164:9200/_cluster/nodes/stats?pretty=true)
> shows
> {
> "cluster\_name" : "metajure",
> "nodes" : {
> "Nfs\_5wldQEi0TO9QR0a1Cg" : {
> "timestamp" : 1345072330400,
> "name" : "Zartra",
> "transport\_address" : "inet[/172.16.0.164:9300]",
> and
>
> curl -XGET
> '[http://172.16.0.164:9200/test\_index0\_copy/\_search?q=text:company&pretty=true](http://172.16.0.164:9200/test_index0_copy/_search?q=text:company&pretty=true)'
> gets a page of results
>
> But
> 2. I can NOT connect from the same machine via the Java API using the
> following code (using the other appropriate port, 9300 as shown) running in
> Eclipse.
> private static TransportClient connectToElasticSearch() {
>
> ```
> Settings settings;
> // once we find one node in the cluster ask about the others
> Builder settingsBuilder =
>
> ```
>
> ImmutableSettings.settingsBuilder().put("client.transport.sniff", true);
> settingsBuilder.put("cluster.name", "metajure");
> settingsBuilder.put("client.transport.ping\_timeout", "10s");
> settings = settingsBuilder.build();
> return new TransportClient(settings).addTransportAddress(new
> InetSocketTransportAddress("172.16.0.164", 9300));
> }
>
> The above code dies when it tries to addTransportAddress and I get the trace
> listed below:
> Does the line just above the stack trace:
> "DEBUG - [Contemplator] connected to node
> [[#transport#-1][inet[/172.16.0.164:9300]]]"
> Actual mean it got there, but that something got garbled on the return as
> stated in the next line:
> "INFO - [Contemplator] failed to get local cluster state for
> [#transport#-1][inet[/172.16.0.164:9300]], disconnecting..."
> ?
>
> Any suggestions on how to track down where the problem lies would be
> appreciated. There are NO extra JVMs running on the machine running the
> above code.
> -Paul
>
> INFO - [Contemplator] loaded , sites
> DEBUG - using [UnsafeChunkDecoder] decoder
> DEBUG - [Contemplator] creating thread\_pool [generic], type [cached],
> keep\_alive [30s]
> DEBUG - [Contemplator] creating thread\_pool [index], type [cached],
> keep\_alive [5m]
> DEBUG - [Contemplator] creating thread\_pool [bulk], type [cached],
> keep\_alive [5m]
> DEBUG - [Contemplator] creating thread\_pool [get], type [cached], keep\_alive
> [5m]
> DEBUG - [Contemplator] creating thread\_pool [search], type [cached],
> keep\_alive [5m]
> DEBUG - [Contemplator] creating thread\_pool [percolate], type [cached],
> keep\_alive [5m]
> DEBUG - [Contemplator] creating thread\_pool [management], type [scaling],
> min [1], size [5], keep\_alive [5m]
> DEBUG - [Contemplator] creating thread\_pool [flush], type [scaling], min
> [1], size [10], keep\_alive [5m]
> DEBUG - [Contemplator] creating thread\_pool [merge], type [scaling], min
> [1], size [20], keep\_alive [5m]
> DEBUG - [Contemplator] creating thread\_pool [refresh], type [cached],
> keep\_alive [1m]
> DEBUG - [Contemplator] creating thread\_pool [cache], type [scaling], min
> [1], size [4], keep\_alive [5m]
> DEBUG - [Contemplator] creating thread\_pool [snapshot], type [scaling], min
> [1], size [5], keep\_alive [5m]
> DEBUG - [Contemplator] using worker\_count[16], port[9300-9400],
> bind\_host[null], publish\_host[null], compress[false], connect\_timeout[30s],
> connections\_per\_node[2/6/1]
> DEBUG - [Contemplator] node\_sampler\_interval[5s]
> DEBUG - Using the autodetected NIO constraint level: 0
> DEBUG - [Contemplator] adding address
> [[#transport#-1][inet[/172.16.0.164:9300]]]
> DEBUG - [Contemplator] connected to node
> [[#transport#-1][inet[/172.16.0.164:9300]]]
> INFO - [Contemplator] failed to get local cluster state for
> [#transport#-1][inet[/172.16.0.164:9300]], disconnecting...
> org.elasticsearch.transport.RemoteTransportException: Failed to deserialize
> response of type
> [org.elasticsearch.action.admin.cluster.state.ClusterStateResponse]
> Caused by: org.elasticsearch.transport.TransportSerializationException:
> Failed to deserialize response of type
> [org.elasticsearch.action.admin.cluster.state.ClusterStateResponse]
> at
> org.elasticsearch.transport.netty.MessageChannelHandler.handleResponse(MessageChannelHandler.java:150)
> at
> org.elasticsearch.transport.netty.MessageChannelHandler.messageReceived(MessageChannelHandler.java:127)
> at
> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:75)
> at
> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:563)
> at
> org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
> at
> org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
> at
> org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:458)
> at
> org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:439)
> at
> org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
> at
> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:75)
> at
> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:563)
> at
> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:558)
> at
> org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
> at
> org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:91)
> at
> org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:373)
> at
> org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:247)
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)
> at
> org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:102)
> at
> org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.IndexOutOfBoundsException: Readable byte limit
> exceeded: 110
> at
> org.jboss.netty.buffer.AbstractChannelBuffer.readByte(AbstractChannelBuffer.java:236)
> at
> org.elasticsearch.transport.netty.ChannelBufferStreamInput.readByte(ChannelBufferStreamInput.java:126)
> at
> org.elasticsearch.common.io.stream.StreamInput.readString(StreamInput.java:178)
> at
> org.elasticsearch.common.io.stream.StreamInput.readUTF(StreamInput.java:207)
> at
> org.elasticsearch.common.io.stream.HandlesStreamInput.readUTF(HandlesStreamInput.java:50)
> at
> org.elasticsearch.cluster.routing.ImmutableShardRouting.readFromThin(ImmutableShardRouting.java:200)
> at
> org.elasticsearch.cluster.routing.ImmutableShardRouting.readFrom(ImmutableShardRouting.java:189)
> at
> org.elasticsearch.cluster.routing.ImmutableShardRouting.readShardRoutingEntry(ImmutableShardRouting.java:182)
> at
> org.elasticsearch.cluster.routing.IndexShardRoutingTable$Builder.readFromThin(IndexShardRoutingTable.java:463)
> at
> org.elasticsearch.cluster.routing.IndexRoutingTable$Builder.readFrom(IndexRoutingTable.java:256)
> at
> org.elasticsearch.cluster.routing.RoutingTable$Builder.readFrom(RoutingTable.java:387)
> at
> org.elasticsearch.cluster.ClusterState$Builder.readFrom(ClusterState.java:252)
> at
> org.elasticsearch.action.admin.cluster.state.ClusterStateResponse.readFrom(ClusterStateResponse.java:66)
> at
> org.elasticsearch.transport.netty.MessageChannelHandler.handleResponse(MessageChannelHandler.java:148)
> ... 22 more
>
> -Paul
>
> --
--
---
### Author:  [@phill](https://discuss.elastic.co/u/phill)
#### Post date: [August 16, 2012, 12:19am UTC](https://discuss.elastic.co/t/can-connect-with-http-but-not-through-java-api/8754/3 "2012-08-16T00:19:51Z")
On 8/15/2012 4:35 PM, Ivan Brusic wrote:
> Is port 9300 open? Can you do a simple telnet to it?
Good idea, but that looks good to me.
Looks good to me...
$ telnet 172.16.0.164 9200
Trying 172.16.0.164...
Connected to 172.16.0.164.
Escape character is '^]'.
telnet\> quit
Connection closed.
$ telnet 172.16.0.164 9300
Trying 172.16.0.164...
Connected to 172.16.0.164.
Escape character is '^]'.
telnet\> quit
Connection closed.
$ telnet 172.16.0.164 9400
Trying 172.16.0.164...
telnet: Unable to connect to remote host: Connection refused
--
---
### Author:  [@Ivan](https://discuss.elastic.co/u/Ivan)
#### Post date: [August 16, 2012, 12:37am UTC](https://discuss.elastic.co/t/can-connect-with-http-but-not-through-java-api/8754/4 "2012-08-16T00:37:46Z")
It was worth a shot since it is the usual culprit.
Deserialization errors can occur when using a different version of the
client and server. Which version are you using? Are they the same
between client and server? Do you have any Lucene libraries in your
classpath?
--
Ivan
On Wed, Aug 15, 2012 at 5:20 PM, P. Hill [parehill1@gmail.com](mailto:parehill1@gmail.com) wrote:
> On 8/15/2012 4:35 PM, Ivan Brusic wrote:
>
> > Is port 9300 open? Can you do a simple telnet to it?
>
> Good idea, but that looks good to me.
> Looks good to me...
>
> $ telnet 172.16.0.164 9200
> Trying 172.16.0.164...
> Connected to 172.16.0.164.
> Escape character is '^]'.
>
> telnet\> quit
> Connection closed.
> $ telnet 172.16.0.164 9300
> Trying 172.16.0.164...
> Connected to 172.16.0.164.
> Escape character is '^]'.
>
> telnet\> quit
> Connection closed.
>
> $ telnet 172.16.0.164 9400
> Trying 172.16.0.164...
> telnet: Unable to connect to remote host: Connection refused
>
> --
--
---
### Author:  [@phill](https://discuss.elastic.co/u/phill)
#### Post date: [August 16, 2012, 9:04pm UTC](https://discuss.elastic.co/t/can-connect-with-http-but-not-through-java-api/8754/5 "2012-08-16T21:04:43Z")
> Do you have any Lucene libraries in your classpath
I was thinking that was most likely the answer since I have a
combination of Eclipse projects and I was trying to get a Maven copy of
ES to combine with,
but after linking my Lucene project to ES libraries and it failing I
went back to a simplier setup.
I created a new project that depended on the Maven of ES (containing
Lucene 3.6) and compiled everything using JDK 1.60.\_25 and I still have
the problem 🙂
How do I know what version of ES I'm running on the server? Is there a
HTTP REST API for that?
How do I know what version of the code I'm running in my project?
Version.java says
public static final Version CURRENT = V\_0\_20\_0\_Beta1;
The following code also can't build a node to join the cluster as stated on
> **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)**
>
> Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today.
Could it be because either of the following (which I thought matched the
API failing
[http://172.16.0.164:9200/\_cluster/nodes/state?pretty=true](http://172.16.0.164:9200/_cluster/nodes/state?pretty=true)
OR
[http://172.16.0.164:9200/\_cluster/nodes/status?pretty=true](http://172.16.0.164:9200/_cluster/nodes/status?pretty=true)
Returns no nodes?
{
"ok" : true,
"cluster\_name" : "metajure",
"nodes" : {
}
}
But
[http://172.16.0.164:9200/\_cluster/state?pretty=true](http://172.16.0.164:9200/_cluster/state?pretty=true)
Does return lots of information.
* * *
public class Foo {
```
/**
* @return
*/
public static Settings buildSettings() {
Settings settings;
// once we find one node in the cluster ask about the others
Builder settingsBuilder =
```
ImmutableSettings.settingsBuilder().put("client.transport.sniff", true);
settingsBuilder.put("cluster.name", "metajure");
settingsBuilder.put("client.transport.ping\_timeout", "10s");
settings = settingsBuilder.build();
return settings;
}
```
public static void main(String[] args) throws InterruptedException {
new TransportClient(buildSettings()).addTransportAddress(new
```
InetSocketTransportAddress("172.16.0.164", 9300));
```
Node node = nodeBuilder().settings(buildSettings()).node();
Client client = node.client();
Thread.currentThread().sleep(5000);
}
```
}
* * *
-Paul
--
---
### Author:  [@dadoonet](https://discuss.elastic.co/u/dadoonet)
#### Post date: [August 16, 2012, 9:49pm UTC](https://discuss.elastic.co/t/can-connect-with-http-but-not-through-java-api/8754/6 "2012-08-16T21:49:05Z")
Just answering to : How do I know what version of ES I'm running on the server? Is there a HTTP REST API for that?
Yes! curl [http://localhost:9200](http://localhost:9200)
Easy, isn't it?
😉
--
Le 16 août 2012 à 23:05, "P. Hill" [parehill1@gmail.com](mailto:parehill1@gmail.com) a écrit :
> > Do you have any Lucene libraries in your classpath
>
> I was thinking that was most likely the answer since I have a combination of Eclipse projects and I was trying to get a Maven copy of ES to combine with,
> but after linking my Lucene project to ES libraries and it failing I went back to a simplier setup.
>
> I created a new project that depended on the Maven of ES (containing Lucene 3.6) and compiled everything using JDK 1.60.\_25 and I still have the problem 🙂
>
> How do I know what version of ES I'm running on the server? Is there a HTTP REST API for that?
> How do I know what version of the code I'm running in my project?
>
> Version.java says
> public static final Version CURRENT = V\_0\_20\_0\_Beta1;
>
> The following code also can't build a node to join the cluster as stated on
> [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/java-api/client.html)
>
> Could it be because either of the following (which I thought matched the API failing
> [http://172.16.0.164:9200/\_cluster/nodes/state?pretty=true](http://172.16.0.164:9200/_cluster/nodes/state?pretty=true)
> OR
> [http://172.16.0.164:9200/\_cluster/nodes/status?pretty=true](http://172.16.0.164:9200/_cluster/nodes/status?pretty=true)
> Returns no nodes?
>
> {
> "ok" : true,
> "cluster\_name" : "metajure",
> "nodes" : {
> }
> }
>
> But
> [http://172.16.0.164:9200/\_cluster/state?pretty=true](http://172.16.0.164:9200/_cluster/state?pretty=true)
> Does return lots of information.
>
> * * *
>
> public class Foo {
>
> /\*\*
> \* @return
> \*/
> public static Settings buildSettings() {
> Settings settings;
> // once we find one node in the cluster ask about the others
> Builder settingsBuilder = ImmutableSettings.settingsBuilder().put("client.transport.sniff", true);
> settingsBuilder.put("cluster.name", "metajure");
> settingsBuilder.put("client.transport.ping\_timeout", "10s");
> settings = settingsBuilder.build();
> return settings;
> }
>
> public static void main(String args) throws InterruptedException {
> new TransportClient(buildSettings()).addTransportAddress(new InetSocketTransportAddress("172.16.0.164", 9300));
>
> ```
> Node node = nodeBuilder().settings(buildSettings()).node();
> Client client = node.client();
>
> Thread.currentThread().sleep(5000);
>
> ```
>
> }
> }
>
> * * *
>
> -Paul
>
> --
--
---
### Author:  [@phill](https://discuss.elastic.co/u/phill)
#### Post date: [August 16, 2012, 10:43pm UTC](https://discuss.elastic.co/t/can-connect-with-http-but-not-through-java-api/8754/7 "2012-08-16T22:43:40Z")
On 8/16/2012 2:49 PM, David Pilato wrote:
> Just answering to : How do I know what version of ES I'm running on the server? Is there a HTTP REST API for that?
>
> Yes! curl [http://localhost:9200](http://localhost:9200)
>
> Easy, isn't it?
> Too easy! Thanks.
> So I think I'm running
"number" : "0.19.8" on the server
and
0.20.0\_beta1 on the client machine.
But I think any difference is a red herring, because it WAS working at some point.
Could it be a character encoding problem? I'm running the following JDKs
++Server++
java version "1.7.0\_03"
OpenJDK Runtime Environment (IcedTea7 2.1.1pre) (7~u3-2.1.1~pre1-1ubuntu3)
OpenJDK Client VM (build 22.0-b10, mixed mode, sharing)
On Ubuntu
++Client++
JDK 1.6.0\_25
on Windows 7 SP 1
In the past I had replicated some indexices from Lucene through the JAVA Api to
So to recap, something has gotten fouled up.
1. telnet to both ports works.
2. I can't even get a good connection to the cluster.
3. Something about deserialization on the client side of the JAVA API doesn't work.
4. The client code does start looking at the results from the server request and finds things like the right cluster name ( I stepped through the code), but it dies
-- it dies in readShardRoutingEntry when it runs off the end of 110 bytes worth of data.
I downloaded the maven repository and have that code.
I add a very simple class to try to connect to the server view NodeBuilder.node() or a TransportClient and get errors:
The full stack trace after restarting the ES server is actually slightly different; see second caused by below
"Expected handle header, got [22]"
Has someone messed up the index or is the client doing it wrong.
Any ideas?
-Paul
Caused by: org.elasticsearch.transport.TransportSerializationException: Failed to deserialize response of type [org.elasticsearch.action.admin.cluster.state.ClusterStateResponse]
at org.elasticsearch.transport.netty.MessageChannelHandler.handleResponse(MessageChannelHandler.java:150)
at org.elasticsearch.transport.netty.MessageChannelHandler.messageReceived(MessageChannelHandler.java:127)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:75)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:563)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:458)
at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:439)
at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:75)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:563)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:558)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:91)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:373)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:247)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)
at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:102)
at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
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:662)
Caused by: java.io.IOException: Expected handle header, got [22]
at org.elasticsearch.common.io.stream.HandlesStreamInput.readUTF(HandlesStreamInput.java:64)
at org.elasticsearch.cluster.routing.ImmutableShardRouting.readFromThin(ImmutableShardRouting.java:196)
at org.elasticsearch.cluster.routing.ImmutableShardRouting.readFrom(ImmutableShardRouting.java:189)
at org.elasticsearch.cluster.routing.ImmutableShardRouting.readShardRoutingEntry(ImmutableShardRouting.java:182)
at org.elasticsearch.cluster.routing.IndexShardRoutingTable$Builder.readFromThin(IndexShardRoutingTable.java:463)
at org.elasticsearch.cluster.routing.IndexRoutingTable$Builder.readFrom(IndexRoutingTable.java:256)
at org.elasticsearch.cluster.routing.RoutingTable$Builder.readFrom(RoutingTable.java:387)
at org.elasticsearch.cluster.ClusterState$Builder.readFrom(ClusterState.java:252)
at org.elasticsearch.action.admin.cluster.state.ClusterStateResponse.readFrom(ClusterStateResponse.java:66)
at org.elasticsearch.transport.netty.MessageChannelHandler.handleResponse(MessageChannelHandler.java:148)
... 22 more
-Paul
--
---
### Author:  [@dadoonet](https://discuss.elastic.co/u/dadoonet)
#### Post date: [August 17, 2012, 1:43am UTC](https://discuss.elastic.co/t/can-connect-with-http-but-not-through-java-api/8754/8 "2012-08-17T01:43:59Z")
IMHO, you can't use a different version (major version) for nodes and clients.
It works for minor versions: 0.19.5 node with 0.19.6 client for example.
My 2 cents.
David 😉
Twitter : @dadoonet / @elasticsearchfr
Le 17 août 2012 à 00:44, "P. Hill" [parehill1@gmail.com](mailto:parehill1@gmail.com) a écrit :
> On 8/16/2012 2:49 PM, David Pilato wrote:
>
> > Just answering to : How do I know what version of ES I'm running on the server? Is there a HTTP REST API for that?
> >
> > Yes! curl [http://localhost:9200](http://localhost:9200)
> >
> > Easy, isn't it?
> > Too easy! Thanks.
> > So I think I'm running
>
> "number" : "0.19.8" on the server
> and
> 0.20.0\_beta1 on the client machine.
> But I think any difference is a red herring, because it WAS working at some point.
>
> Could it be a character encoding problem? I'm running the following JDKs
>
> ++Server++
> java version "1.7.0\_03"
> OpenJDK Runtime Environment (IcedTea7 2.1.1pre) (7~u3-2.1.1~pre1-1ubuntu3)
> OpenJDK Client VM (build 22.0-b10, mixed mode, sharing)
> On Ubuntu
>
> ++Client++
> JDK 1.6.0\_25
> on Windows 7 SP 1
>
> In the past I had replicated some indexices from Lucene through the JAVA Api to
> So to recap, something has gotten fouled up.
>
> 1. telnet to both ports works.
> 2. I can't even get a good connection to the cluster.
> 3. Something about deserialization on the client side of the JAVA API doesn't work.
> 4. The client code does start looking at the results from the server request and finds things like the right cluster name ( I stepped through the code), but it dies
> -- it dies in readShardRoutingEntry when it runs off the end of 110 bytes worth of data.
>
> I downloaded the maven repository and have that code.
> I add a very simple class to try to connect to the server view NodeBuilder.node() or a TransportClient and get errors:
>
> The full stack trace after restarting the ES server is actually slightly different; see second caused by below
> "Expected handle header, got [22]"
> Has someone messed up the index or is the client doing it wrong.
> Any ideas?
> -Paul
>
> Caused by: org.elasticsearch.transport.TransportSerializationException: Failed to deserialize response of type [org.elasticsearch.action.admin.cluster.state.ClusterStateResponse]
> at org.elasticsearch.transport.netty.MessageChannelHandler.handleResponse(MessageChannelHandler.java:150)
> at org.elasticsearch.transport.netty.MessageChannelHandler.messageReceived(MessageChannelHandler.java:127)
> at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:75)
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:563)
> at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
> at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:458)
> at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:439)
> at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
> at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:75)
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:563)
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:558)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:91)
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:373)
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:247)
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)
> at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:102)
> at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
> 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:662)
> Caused by: java.io.IOException: Expected handle header, got [22]
> at org.elasticsearch.common.io.stream.HandlesStreamInput.readUTF(HandlesStreamInput.java:64)
> at org.elasticsearch.cluster.routing.ImmutableShardRouting.readFromThin(ImmutableShardRouting.java:196)
> at org.elasticsearch.cluster.routing.ImmutableShardRouting.readFrom(ImmutableShardRouting.java:189)
> at org.elasticsearch.cluster.routing.ImmutableShardRouting.readShardRoutingEntry(ImmutableShardRouting.java:182)
> at org.elasticsearch.cluster.routing.IndexShardRoutingTable$Builder.readFromThin(IndexShardRoutingTable.java:463)
> at org.elasticsearch.cluster.routing.IndexRoutingTable$Builder.readFrom(IndexRoutingTable.java:256)
> at org.elasticsearch.cluster.routing.RoutingTable$Builder.readFrom(RoutingTable.java:387)
> at org.elasticsearch.cluster.ClusterState$Builder.readFrom(ClusterState.java:252)
> at org.elasticsearch.action.admin.cluster.state.ClusterStateResponse.readFrom(ClusterStateResponse.java:66)
> at org.elasticsearch.transport.netty.MessageChannelHandler.handleResponse(MessageChannelHandler.java:148)
> ... 22 more
> -Paul
>
> --
--
---
### Author:  [@phill](https://discuss.elastic.co/u/phill)
#### Post date: [August 20, 2012, 9:24pm UTC](https://discuss.elastic.co/t/can-connect-with-http-but-not-through-java-api/8754/9 "2012-08-20T21:24:45Z")
OK after going away for the weekend, I put it all back together.
I had two problems at the same time which are always a pain to track down.
(1) The node I was connecting to had run out of disk space.
and
(2) and I made sure my Eclipse project was using 19.8.0 code by creating
an empty Eclipse Maven project that lists ONLY Elasticsearch as its
dependency.
I cleaned up the node that was having trouble responding by giving it
more disk space and deleting various experimental indices.
After that only after making sure I was using the same libraries as the
server did the connection work.
Another possibility is that I had messed up the Eclipse dependencies and
a mix-and-match set of libraries.
I'm thinking the cluster was trying to tell my code something (or
mis-behaving) and this error scenerio of the older code on the server
caused trouble for the code on the client.
Things were broken AND I had the code mis-matched server to client (or
worse on the client), thus not a scenerio I'm going to go back and try
to track down.
thanks everyone for the help,
-Paul
On 8/16/2012 6:43 PM, David Pilato wrote:
> IMHO, you can't use a different version (major version) for nodes and clients.
>
> It works for minor versions: 0.19.5 node with 0.19.6 client for example.
--
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 6, 2017, 3:15am UTC](https://discuss.elastic.co/t/can-connect-with-http-but-not-through-java-api/8754/10 "2017-07-06T03:15:43Z")