The way to handle bulk gets in the event of a failing node is unclear, so the failing node test currently fails.
QueueAttachment was a nested class in MemcachedConnection that was used to hold per-connection information. It was called QueueAttachment because it was attached to the select queue or something like that. MemcachedNode seems like a better name, and it's going to need to be exposed some as we get into more pluggable node selection algorithms.
I just upgraded to eclipse 3.3 and it's finding warnings and errors that should've been found before, but weren't.
There were a couple of stupidities in how the client was set up, and some issues keeping large numbers of async sets down. It still doesn't model a real application very well, but may be good enough at showing what would happen in a peak situation.
Apparently, the common thing to do is check the status of a server when performing a command against it, and trying the next server in the list when the server is unavailable. My previous behavior was to queue a command against a server regardless of its status such that when a server was available the command would be processed as close to immediately as contention would allow, but when a server was unavailable, the command would wait around for the server to come back up. The new behavior is something near the middle of this. When a server is unavailable, I'll try the next server in the list. I repeat until I've exhausted every known server and then just queue it for the one to which it belonged in the first place.
I had some conditions where these assertions were firing due to cancellation when a server went bad.