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).
I manage to do something that slows stuff down in my full test plan which leads to spurious failures. This may be hinting at a bug of some type, or perhaps some bad defaults, but this code isn't attempting to test timeouts so they should never get in the way.
I think there may be a bigger bug around this, but it only occurs when trying to shut down a connection that shouldn't've started due to someone writing a broken connection factory, so I think we can live with it.
Turns out the ``not found'' error for prepend and append is different from that of other commands so I needed to make a case for it.
This is primarily because I don't know for sure the Whalin client would know what to do if it saw a 0 byte long.
This helps me ensure the contract of certain methods, and (shockingly) found some minor bugs in edge cases.