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
Comments
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). |
fwiw, just received this with a stand alone server (no cluster) using text mode memcached client. |
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:
|
good catch, will push a fix. |
Memcach: StreamCorruptedException when loading a cluster, closed by 02b74df. |
relates elastic#300 (cherry picked from commit 34cb5560be300f404458bb79c0570bc87b8bf08e)
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
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)
The text was updated successfully, but these errors were encountered: