Theoretically, this can work with default values as well, but only in the binary protocol. Getting this to work with the text protocol would likely be quite painful. http://code.google.com/p/spymemcached/issues/detail?id=12
This functionality was removed after we all agreed it was confusing as 1157f3c5ce25918558781bd2207b6b6de702dd17 in memcached by Trond Norbye (merged in by Toru). Mon Jul 28 17:55:41 2008 +0900 That ID will probably be killed off by a rebase.
This seems to happen in some strange server-error cases where the server short-circuits the connection. This situation has shown itself when we've sent something too large into the server. Precautions have been taken to prevent that exact thing from happening again, but this is a better way to handle an unexpected state. I'm not sure how we end up still having data to receive when we've already thrown away the ops, but tearing down the connection is a clean way to recover from a bad state.
This will avoid a few problems people have encountered. I implemented it with a somewhat early IllegalArgumentException because it was the surest way to cover every case given compression and several paths in to sets.
…ions. Whenever a read returned in the binary protocol without having read enough bytes to fill a header packet, an NPE would be fired that would cause us to disconnect from the server and cancel all in-flight operations. This happened occasionally in one of my tests and was rather a pain to track down. It likely never affected anyone since I doubt anyone is actually using the binary protocol anywhere today.
…fied. By default, the read queue is 10% larger than the input queue. With a sufficiently large op read queue, it's possible to never internally overflow, but correct values are likely application-specific.
These are two measures that are helping with the queue overflow problems. Firstly, the IllegalStateException is thrown whenever you attempted to add to a queue that's full. If that happens internally, I don't want the IO thread to crash, so I add it to the normal ``expected exceptions'' list. Secondly, reading before writing helps keep the read buffer ready for new data. When writing first, the write will have to transition to a read and may cause the read buffer to overflow. It still may happen, but by servicing the reads first I can at least get the complete ones popped out before piling new ones in (since writes are almost always smaller and likely to transition).