My guess is that in practice you have three situations with queue size:

 1. super short queue
 2. fairly large queue which isn't a bug just some weird high-load situation such as a lengthy task
 3. super ginormous queue because something is broken/buggy

So you want to basically give up and let it crash in case 3, rather than going nuts and running out of RAM or something. But I doubt we really want to break in case 2. There's nothing the client is going to be able to do about a "queue full" error, other than crash or give up or just keep its own queue or other things that are not helpful. I can't think of how the client would handle it, anyway. Nobody's going to write complicated error recovery code (what would that code even do?). We'll just have "// TODO handle queue full" in the client I bet.

Bottom line is that my intuition would be to make the max size of these queues something so large you'd only hit it if someone basically wrote an infinite message-send loop or otherwise went nuts. (But with ArrayBlockingQueue that might create a giant array allocation up front, I don't know.)

I think it would also be reasonable to just make these unbounded. It isn't really a network service with untrusted clients kind of situation. If the queue gets stuffed with requests it's going to be a bug we have to fix, rather than a situation the software can dynamically recover from.

That's my intuition at least. When I've written localhost servers before with queue limits, we always ended up setting them to "never encountered in practice" values.