Exceptions


(thinusp) #1

I seem to be unable to get exceptions from the Transport Client, which of
course is making development really difficult. Yes, I suppose it makes
sense to develop on a local-machine-based node first, but due to technical
reasons (data presiding on clusters, etc.) it's not that practical.

Whenever something seems to go wrong, I simply get the following standard
exception:

"Exception in thread "main"
org.elasticsearch.transport.TransportSerializationException: Failed to
deserialize exception response from stream"

If I read it correctly it implies something along the lines not being able
to get the actual exception from the server? This message is always
preceded by the following warning:

"WARN transport.netty: [Elathan] Message not fully read (response) for [16]
handler
(...).client.transport.action.support.BaseClientTransportAction$1@d92404,
error [true], resetting"

Any advice/help? The full exception message follows...

Exception in thread "main"
org.elasticsearch.transport.TransportSerializationException: Failed to
deserialize exception response from stream
at
org.elasticsearch.transport.netty.MessageChannelHandler.handlerResponseError(MessageChannelHandler.java:267)
at
org.elasticsearch.transport.netty.MessageChannelHandler.process(MessageChannelHandler.java:221)
at
org.elasticsearch.transport.netty.MessageChannelHandler.callDecode(MessageChannelHandler.java:147)
at
org.elasticsearch.transport.netty.MessageChannelHandler.messageReceived(MessageChannelHandler.java:101)
at
org.elasticsearch.common.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:80)
at
org.elasticsearch.common.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
org.elasticsearch.common.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
at
org.elasticsearch.common.netty.channel.Channels.fireMessageReceived(Channels.java:274)
at
org.elasticsearch.common.netty.channel.Channels.fireMessageReceived(Channels.java:261)
at
org.elasticsearch.common.netty.channel.socket.nio.NioWorker.read(NioWorker.java:351)
at
org.elasticsearch.common.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:282)
at
org.elasticsearch.common.netty.channel.socket.nio.NioWorker.run(NioWorker.java:202)
at
org.elasticsearch.common.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
at
org.elasticsearch.common.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:44)
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)

etc.


(Clinton Gormley) #2

"Exception in thread "main"
org.elasticsearch.transport.TransportSerializationException: Failed to
deserialize exception response from stream"

This sounds like you may be using different versions of ElasticSearch.
The client and node versions must be the same

clint


(thinusp) #3

Thanks Clint,

The version reported by using 'elasticsearch -v' is: "ElasticSearch
Version: 0.18.7, JVM: 20.0-b11", and the dependency I have is from the
maven repository: "elasticsearch-0.18.7.jar". I get a transport client to
do the heavy-lifting, which I construct with a callable function like this:

public TransportClient getTransportClient() {
if (_transportClient == null) {
Settings s =
ImmutableSettings.settingsBuilder().put("cluster.name",
_config.getClusterName()).build();
_transportClient = new TransportClient(s);

     for (String ipAddress : _config.getIpAddress()) {
        _transportClient.addTransportAddress(new 

InetSocketTransportAddress(ipAddress, _config.getIpPort()));
}
}

  return _transportClient;

}

I might be wrong, but I don't think version-incompatibility is the issue
here - unless there's something funny about the Maven repository that I
don't know of. Is there some other version number I'll need to check up on?

On Wednesday, 14 March 2012 16:18:49 UTC+2, Clinton Gormley wrote:

"Exception in thread "main"
org.elasticsearch.transport.TransportSerializationException: Failed to
deserialize exception response from stream"

This sounds like you may be using different versions of ElasticSearch.
The client and node versions must be the same

clint


(Lukáš Vlček) #4

Hi,

are you using any pluggins on the server side? They typically include jars
that you may not have available with the TransportClient part so exceptions
from pluggins can not be deserialized. Try to check server side logs and
eventually make sure you have missing jars on the client.

Regards,
Lukas

Dne 14.3.2012 15:33 "Thinus Prinsloo" thinus.prinsloo@gmail.com napsal(a):

Thanks Clint,

The version reported by using 'elasticsearch -v' is: "ElasticSearch
Version: 0.18.7, JVM: 20.0-b11", and the dependency I have is from the
maven repository: "elasticsearch-0.18.7.jar". I get a transport client to
do the heavy-lifting, which I construct with a callable function like this:

public TransportClient getTransportClient() {
if (_transportClient == null) {
Settings s = ImmutableSettings.settingsBuilder().put("
cluster.name", _config.getClusterName()).build();
_transportClient = new TransportClient(s);

     for (String ipAddress : _config.getIpAddress()) {
        _transportClient.addTransportAddress(new

InetSocketTransportAddress(ipAddress, _config.getIpPort()));
}
}

  return _transportClient;

}

I might be wrong, but I don't think version-incompatibility is the issue
here - unless there's something funny about the Maven repository that I
don't know of. Is there some other version number I'll need to check up on?

On Wednesday, 14 March 2012 16:18:49 UTC+2, Clinton Gormley wrote:

"Exception in thread "main"
org.elasticsearch.transport.TransportSerializationException:
Failed to
deserialize exception response from stream"

This sounds like you may be using different versions of ElasticSearch.
The client and node versions must be the same

clint


(adrem) #5

do the client, by any chance run on a different jvm version than the cluster ?

from a 32Bit Win workstation to a 64Bit Linux cluster while trying to create an index.


(system) #6