http://www.couchbase.com/issues This file is an XML representation of an issue en-us 5.2.4 845 26-12-2012 http://www.couchbase.com/issues/browse/SPY-89 Spymemcached Java Client When investigating an issue, I found that the server would unexpectedly respond with a 0x0a command for optimized get requests. This seems to be in violation of the protocol, and it causes all kinds of havoc for a client library. <br/> <br/> The scenario is spymemcached&#39;s internals doing an optimized get. It&#39;s reading the response for an operation during a rebalance. It has been observed with both the node being rebalanced into the cluster and with a node leaving the cluster. <br/> <br/> Reading the minimum header, the client library is checking the magic, and then the response command. It&#39;s expecting a 0x00, but receiving a 0x0a. <br/> <br/> I poked through the server side code, and 0x0a corresponds to TAP_NOOP. I poked around a little further, and I don&#39;t see any situation where we would respond with this 0x0a to a non-TAP client. <br/> <br/> The assertion this is raising is right here: <br/> <a href="https://github.com/dustin/java-memcached-client/blob/master/src/main/java/net/spy/memcached/protocol/binary/OperationImpl.java#L136">https://github.com/dustin/java-memcached-client/blob/master/src/main/java/net/spy/memcached/protocol/binary/OperationImpl.java#L136</a> <br/> <br/> If I force spymemcached to not optimize, the problem goes away. <br/> <br/> I will attach a packet capture. SPY-89

invalid binary protocol server response during rebalance

Bug Major Open Unresolved Public Matt Ingenthron Matt Ingenthron Thu, 31 May 2012 00:47:42 -0500 Fri, 1 Jun 2012 02:56:54 -0500 2.8.1 library 0 1 Added packet capture and notes (which are effectively the same as above) 0x0a == NOOP, not TAP_NOOP... I moved this bug back to the client for investigation if we did send a noop request or not (this is typically sent after a series of quiet commands in order to ensure that we get a response). Could it be that we don&#39;t correctly handle reshuffling of the packets (adding a noop to all of the new queues, and ensure that we don&#39;t send multiple of them since we most likely expect only once). Moved this, as I found the protocol was correct, but the assertion was incorrect. The assertion did not account for any setq responses with errors, so this would have been an issue in any environment with optimized sets and responses on setqs. Rank 9516