Closed GoogleCodeExporter closed 8 years ago
I added an Thread.UncaughtExceptionHandler to log what error was leaking out.
Note, this is happening somewhat regularly for us.
java.lang.AssertionError: No read operation
at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:299)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:262)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:182)
at net.spy.memcached.MemcachedClient.run(MemcachedClient.java:1259)
Original comment by kevinoliver
on 25 Sep 2008 at 7:55
Thanks for the update. That's quite a strange error. Apparently I read data
from
memcached, but nobody wanted it. Might be a good time to shut down the
connection
and reinitialize it.
Do you have a test case that can reproduce this? I'd kind of like to see what's
happening on the wire.
Original comment by dsalli...@gmail.com
on 25 Sep 2008 at 8:43
Well... It seems to happen somewhat regularly when I try to set a value that is
larger than 1MB. We try to catch the "OperationException: SERVER: SERVER_ERROR
object
too large for cache" error and put the value into the cache as smaller chunks.
I don't know if this helps: this client is talking to a memcached server running
locally on the same host. We are using the DefaultConnectionFactory and we
using the
ascii protocol.
As for a test case. It looks a bit like this (I've edited out a bunch of our
code
that sits above your client, but it basically boils down to this). I haven't
yet run
into this error locally on my machine, but our test harness hits this fairly
regularly.
// insert a value greater than 1 MB in size...
// let's put "random" data in that will not compress down...
byte[] data = new byte[(1024*1024 * 15) + 111];
Random random = new Random(1001);
random.nextBytes(data);
// verify that the compressed size is greater than 1MB.
int compressedSize = getCompressedSize(data);
assertTrue("compressed size should be larger than 1MB: " + compressedSize,
compressedSize > 1024*1024);
// this line is what seems to trigger the error
memcachedClient.set("testChunkedPutAndGet", 0, data);
Please let me know if you need any additional info.
My 2 cents is that it feels like the MemcachedClient.run() loop should never
allow
any Throwable to make it exit it's run loop. Eg, run() would just look like
this:
@Override public void run() {
while(running) {
try {
conn.handleIO();
} catch (Throwable t) {
logRunException(t);
}
}
getLogger().info("Shut down memcached client");
}
Original comment by kevinoliver
on 25 Sep 2008 at 10:21
I think this is another report of this problem:
Original comment by dsalli...@gmail.com
on 1 Oct 2008 at 10:51
Attachments:
Yep, looks like the same issue to me. We have net.spy.memcached logging set to
warning only, so I don't see a bunch of those log messages.
You said you think this is another report of this problem... Does that mean
there is
already another issue open with similar issues? Or have you been able to
reproduce?
Original comment by kevinoliver
on 1 Oct 2008 at 11:07
Original comment by dsalli...@gmail.com
on 2 Oct 2008 at 7:03
Original comment by dsalli...@gmail.com
on 2 Oct 2008 at 7:07
I've fixed this so that instead of being an assertion it'll more directly cause
a
reconnect.
Original comment by dsalli...@gmail.com
on 3 Oct 2008 at 4:27
Original issue reported on code.google.com by
kevinoliver
on 15 Sep 2008 at 4:46