Thanks Ryan.
I've put my response inline...
On 6 February 2012 18:35, Ryan Lubke <ryan.lubke_at_oracle.com> wrote:
This behavior is currently expected. However since both the non-blocking
> and blocking writers share the same base interface and having to care about
> synchronization depending on mode would be a pain, we should fix this.
>
I see. What's a bit sad is that until today I thought that we were doing
non-blocking writes! Duh :-(
Presumably the trick to enable non-blocking writes is to call
set org.glassfish.grizzly.Connection.configureBlocking(false) or the
equivalent method on the Transport? Looking back over our change log I can
see why we explicitly enable blocking writes: we were not sure how to
throttle the writer threads (be it client or server) when the receiving
peer is slow. In particular, we were worried that we would run the risk of
running out of memory.
We wrote this code very early on in the 2.0 development cycle so perhaps
there was no support for non-blocking write throttling at the time. If
write throttling is supported now, how does one configure it? Presumably
there's some sort of bounded write queue.
Back to the original subject regarding synchronization: I agree that the
user should not have to synchronize access to a connection based on whether
or not it is blocking. IMHO synchronization and blocking are not the same
thing, even if one may in some implementations imply/require the other. If
blocking connections require synchronization then this should be managed
internally as an implementation detail. Moreover I should be able to switch
my application from blocking to non-blocking and back again by flicking a
switch and without the need to rewrite lots of code.
> - If this is a bug, why hasn't anyone else hit it? Are we using
> unusual or deprecated APIs? I can understand why HTTP client
> implementations would not run into this issue since the protocol is
> synchronous, but I'd imagine other protocol implementations could hit this.
>
> The connection you're using is blocking. That's the main difference
> here I believe (I believe most are using non-blocking connections).
>
Thanks for the heads up - we obviously need to try using non-blocking
writes again, once we've figured out how to configure write throttling (see
my comments above).
>
> - I tried using Grizzly 2.1.8 with the same results. I also ran into a
> separate minor issue as well with 2.1.8 in that it always creates a worker
> thread pool even if you're using the SameThreadIOStrategy - the builder is
> initialized with a WorkerThreadIOStrategy and setting the IOStrategy does
> not clear the ThreadPoolConfig. In addition, forcefully setting the thread
> pool size to 0 causes an exception later on when the FixedThreadPool is
> created.
>
> Ugh.
>
> I've logged two issues to track this:
>
> http://java.net/jira/browse/GRIZZLY-1190
> http://java.net/jira/browse/GRIZZLY-1191
>
>
Great, thanks Ryan.
Matt