…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.
I knew pushing at that point was a dumb idea.
It shouldn't change at runtime in a client, as the current model was not thread safe. In order for this to be dynamically reconfigurable, the field either needs to be volatile or access to the value must be synchronized. By having the value be declared final and removing the mutators and accessors, we can guarantee correctness.