SPY-125: Significant performance issue large number of sets

We now add an operation to the read queue when we transistion it
into a WRITING state. This guarentees that the operation is added
to the read queue once. As a result we no longer have to check to
see if the operation has already been added to the read queue

Change-Id: I0b21d3e1ac7ff7792afabc57c1a8a26c6b757c12
Reviewed-on: http://review.couchbase.org/9425
Reviewed-by: Michael Wiederhold <[email protected]>
Tested-by: Michael Wiederhold <[email protected]>

Author: Mike Wiederhold

src/main/java/net/spy/memcached/protocol/TCPMemcachedNodeImpl.java

@@ -171,18 +171,13 @@ public final void fillWriteBuffer(boolean shouldOptimize) {
 					return;
 				} else {
 					o.writing();
+					if (!(o instanceof TapAckOperationImpl)) {
+						readQ.add(o);
+					}
 				}
 			}
 			while(o != null && toWrite < getWbuf().capacity()) {
 				assert o.getState() == OperationState.WRITING;
-				// This isn't the most optimal way to do this, but it hints
-				// at a larger design problem that may need to be taken care
-				// if in the bowels of the client.
-				// In practice, readQ should be small, however.
-				// Also don't add Tap Acks to the readQ since there won't be a response
-				if(!readQ.contains(o) && !(o instanceof TapAckOperationImpl)) {
-					readQ.add(o);
-				}
 
 				ByteBuffer obuf=o.getBuffer();
 				assert obuf != null : "Didn't get a write buffer from " + o;
@@ -205,6 +200,9 @@ public final void fillWriteBuffer(boolean shouldOptimize) {
 					o=getCurrentWriteOp();
 					if (o != null) {
 						o.writing();
+						if (!(o instanceof TapAckOperationImpl)) {
+							readQ.add(o);
+						}
 					}
 				}
 				toWrite += bytesToCopy;