Stability problems in async I/O about spymemcached HOT 4 CLOSED

Sets are asynchronous, so what's happening is you're overwhelming the JVM with 
object futures, and then they're timing out before they can actually get to the 
server.  

For instance if you changed line 28 from:
client.set("key_" + i, 600, value.getBytes());
to:
client.set("key_" + i, 600, value.getBytes()).get();

It'd be slower, but all of the items would get there since you'd be waiting for 
each one to complete before sending another.  I think this is what you thought 
your code was doing.

There are a few variations on this too, like filling a blocking queue and 
grabbing items from the other side to send to the server, rather than creating 
requests super fast, that the network IO has to take time to deal with.

In fact, your test looks a bit like the built in LoaderTest:
https://github.com/dustin/java-memcached-client/blob/master/src/test/manual/net/
spy/memcached/test/LoaderTest.java

I don't really understand, why this bug marked as "Invalid".
Currently the objects net.spy.memcached.protocol.ascii.StoreOperationImpl, 
net.spy.memcached.protocol.ascii.StoreOperationImpl, and others keep growing in 
the heap without any limit. As a result - the heap is exhausted, and we have 
big Full GC stop-the-world pauses.

The right behavior shall be the following: these objects shall be put to the 
queue with configurable size and configurable RejectedExecutionHandler 
(CallerRunsPolicy or AbortPolicy).

I don't understand why the client should be responsible for either throtteling 
requests or querying in a stop-and-wait fashion (which performs poorly, 
obviously). That's the library's job, IMHO.

it is invalid because you're using the default queue with the default 
constructor.  you can specify a queue for the client to use, allowing you to 
control resources as you request