Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memcach: StreamCorruptedException when loading a cluster #300

Closed
cwensel opened this issue Aug 6, 2010 · 5 comments
Closed

Memcach: StreamCorruptedException when loading a cluster #300

cwensel opened this issue Aug 6, 2010 · 5 comments

Comments

@cwensel
Copy link

cwensel commented Aug 6, 2010

Am getting the following exception to stderr when attempting to load a 3 node cluster.

This may be related to the NPE from XContentObjectMapper (see previous issue report).

I've never seen this failure during load of a stand-alone server.

Using the spy memcached library in Text protocol mode to load the cluster.

java.io.StreamCorruptedException: Expecting
after data block
at org.elasticsearch.memcached.netty.MemcachedDecoder.decode(MemcachedDecoder.java:177)
at org.elasticsearch.common.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:282)
at org.elasticsearch.common.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:214)
at org.elasticsearch.common.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:80)
at org.elasticsearch.common.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545)
at org.elasticsearch.common.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:754)
at org.elasticsearch.common.netty.OpenChannelsHandler.handleUpstream(OpenChannelsHandler.java:51)
at org.elasticsearch.common.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545)
at org.elasticsearch.common.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:540)
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:349)
at org.elasticsearch.common.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:281)
at org.elasticsearch.common.netty.channel.socket.nio.NioWorker.run(NioWorker.java:201)
at org.elasticsearch.common.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
at org.elasticsearch.common.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:46)
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:636)

@kimchy
Copy link
Member

kimchy commented Aug 9, 2010

seems like a problematic frame was sent (or something similar). Any chance for a recreation (no problem with a programs that creates this with load, I will run it locally).

@cwensel
Copy link
Author

cwensel commented Aug 9, 2010

fwiw, just received this with a stand alone server (no cluster) using text mode memcached client.
(was testing possible npe fix in XContentObjectMapper)

@cwensel
Copy link
Author

cwensel commented Aug 22, 2010

turns out this issue is caused by the StringBuffer in MemcachedDecoder is not being reset to length zero if the text mode header is not fully available.

this change seems to resolve the problem:

            if (!done) {
                sb.setLength(0); // proposed fix
                buffer.resetReaderIndex();
                return null;
            }

@kimchy
Copy link
Member

kimchy commented Aug 23, 2010

good catch, will push a fix.

@kimchy
Copy link
Member

kimchy commented Aug 23, 2010

Memcach: StreamCorruptedException when loading a cluster, closed by 02b74df.

ClaudioMFreitas pushed a commit to ClaudioMFreitas/elasticsearch-1 that referenced this issue Nov 12, 2019
williamrandolph pushed a commit to williamrandolph/elasticsearch that referenced this issue Jun 4, 2020
relates elastic#300

(cherry picked from commit 34cb5560be300f404458bb79c0570bc87b8bf08e)
mindw pushed a commit to mindw/elasticsearch that referenced this issue Sep 5, 2022
linode specific hack to prevent ems service stop/start loop

* cloudwatch service doesn't seem to be installed in case of linode so commenting it out here to prevent loop.
optional: also consider 'systemctl stop telegraf'

* hack? telegraf keeps restarting in case of linode


Approved-by: Gideon Avida
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants