CODEWITHSUNDEEP
elasticsearch
pferrel
pferrel

Reputation: 5702

Upgrade Elasticsearch 1.4.1 to 2.0 same config fails

I upgraded and copied my old config dir to the new version. I don't care about the old indexes so started fresh. The only things I had changed from default config were the host ip and cluster name.

network.host: 127.0.0.1
cluster.name: elasticsearch_pat

I was running a single node on my dev machine with a custom cluster name so I'd have no conflict. Now when I launch ES I get continuous cluster/nodes/info error which throw a java.lang.IllegalStateException.

[2015-11-13 10:13:59,347][WARN ][transport.netty          ] [Entropic Man] exception caught on transport layer [[id: 0x6c3170dc, /127.0.0.1:61104 => /127.0.0.1:9300]], closing connection
java.lang.IllegalStateException: Message not fully read (request) for requestId [109], action [cluster/nodes/info], readerIndex [39] vs expected [57]; resetting
    at org.elasticsearch.transport.netty.MessageChannelHandler.messageReceived(MessageChannelHandler.java:120)
    at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
    at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
    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:462)
    at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443)
    at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
    at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
    at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
    at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
    at org.elasticsearch.common.netty.OpenChannelsHandler.handleUpstream(OpenChannelsHandler.java:75)
    at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
    at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
    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:88)
    at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108)
    at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
    at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)
    at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
    at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
    at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)

When I check _health with Sense, it is green with one node and one data node, which is correct since I'm running on a dev machine on localhost.

Does Elasticsearch now require authentication? Is this extremely simple config now somehow not sufficient?

Update: This error is coming because another process is trying to access Elasticsearch. When I stop the other process the error stops. The process may be using JDBC or some other driver that was provided before in 1.4.1 and is removed from the binary artifact in 2.0?????

Upvotes: 0

Views: 1705

Answers (1)

Evaldas Buinauskas
Evaldas Buinauskas

Reputation: 14097

@Val is correct. When I did a upgrade from 1.7.3 to 2.0, there were still other client nodes connecting to this cluster. That was exact error log produced.

For me it seems that you're running your application(looking at your port in localhost) , which still uses old elasticsearch API version and creates a 1.4.1 version client node and it conflicts with upgraded node, that's why you're getting error.

Upvotes: 2

Related Questions