roc230 / spymemcached

Automatically exported from code.google.com/p/spymemcached
0 stars 0 forks source link

Spymemcached is "Closing, and reopening" a connection that was just opened #62

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I see this in the logs

2009-04-30 06:47:12.539 INFO net.spy.memcached.MemcachedConnection: Added
{QA sa=/10.18.68.74:8282, #Rops=0, #Wops=0, #iq=0, topRop=null,
topWop=null, toWrite=0, interested=0} to connect queue
2009-04-30 06:47:12.644 WARN net.spy.memcached.MemcachedConnection:
Closing, and reopening {QA sa=/10.18.68.74:8282, #Rops=0, #Wops=0, #iq=0,
topRop=null, topWop=null, toWrite=0, interested=8}, attempt 1.
2009-04-30 06:47:12.854 INFO net.spy.memcached.MemcachedConnection:
Reconnecting {QA sa=/10.18.68.74:8282, #Rops=0, #Wops=0, #iq=0,
topRop=null, topWop=null, toWrite=0, interested=0} 

From what I can see in the code, spymemcached opens an NIO channel for
OP_CONNECT and then adds the node (MemcachedConnection constructor). If I
then issue a request that would end up on that memcached server before the
channel is opened, SelectorKey.readyOps will return 0 (in
MemcachedConnection.handleIO) and thus spymemcached will queue a reconnect.

Instead, spymemcached should probably only use the node once the channel is
open ?

Original issue reported on code.google.com by tom...@gmail.com on 4 May 2009 at 11:13

GoogleCodeExporter commented 9 years ago
Ya see a lot of reconnection warnings in 2.4.2  version
in previous version 2.3.1 there was no such issue.

Original comment by alexkhim...@gmail.com on 30 Oct 2009 at 9:23

GoogleCodeExporter commented 9 years ago
It's not clear to me how this can happen, but there *was* a bug that would've 
covered
up an issue shown here.  As described, I don't see it, though.

If this is happening, I'd love a test case.  It's not happening for me.  :/

Original comment by dsalli...@gmail.com on 11 Nov 2009 at 6:53