IllegalStateException: Queue full

[GoogleCodeExporter]

spymemcache 2.1 on WinXP 
memcached 1.2.6 on Ubuntu 8.0.4, 1 instance

When I test executing mc.set(x,y) or mc.get(x) for a large times, e.g 
30000+, an exception would be thrown sometimes:

java.lang.IllegalStateException: Queue full
         at java.util.AbstractQueue.add(AbstractQueue.java:64) 

Original issue reported on code.google.com by raymond2...@gmail.com on 5 Nov 2008 at 6:41

[GoogleCodeExporter]

i've seen this too with spymemcached 2.1/memcached 1.2.6 on rhel3, single 
instance.

i looked into this a little and spymemcached uses the add method on the blocking
queue when adding an operation.  would it be possible to use offer and throw 
some
sort of checked exception when the queue is full?  

since the runtime exception was hidden in the implementation of spymemcached 
its not
obvious that this is something that should be handled by the caller.

thanks.

Original comment by ajc...@gmail.com on 5 Nov 2008 at 7:08

[GoogleCodeExporter]

While I breakdown the 30000 request into e.g. three spymemcache client 
instances, 
i.e 3 IO threads. It exception could be avoided. And the performace of set() 
get() 
is almost the same as ONE IO thead.

I think that it would not occur in small scale system. But it should be taken 
into 
account for visit heavy application
Though the non blocking theory just need one IO thread, but I propose that 
provided 
a thead pool machanism just to avoid this problem. 

Original comment by raymond2...@gmail.com on 5 Nov 2008 at 7:13

[GoogleCodeExporter]

The exception can be documented, but I'm strongly against making this a checked
exception.  It's very unlikely to show up in any real production environment, so
having everyone pay a coding penalty for it seems like it'd just make for a lot 
of
bad code.

It does show up a lot in tests because people have no problems writing tests to
trigger it.  If your test did a bunch of set() calls and get() calls 
interleaved, you
wouldn't see it.  If it did all get() calls, you wouldn't see it.

The only time you're likely to see it is if you either do a large number of 
set()
calls in a fast loop without ever checking their results or synchronizing on any
other operation.

Pooling connections is certainly a good idea for some reasons.  It should be 
done
intelligently, though.  Gets in particular need to try to hash an affinity to a
connection for performance reasons.  It's a little complicated, and *really* 
hard
without a proper interface over the client.  :(

I'm going to declare this a documentation bug to be fixed in the next minor 
release
of 2.2.

Original comment by dsalli...@gmail.com on 5 Nov 2008 at 7:18

• Changed state: Accepted
• Added labels: Component-Docs, Milestone-Release2.2

[GoogleCodeExporter]

pushed

Original comment by dsalli...@gmail.com on 7 Nov 2008 at 4:35

• Changed state: Fixed