On 2/6/12 1:22 PM, Matthew Swift wrote:
> Thanks Ryan.
>
> I've put my response inline...
See inline...
>
>
> On 6 February 2012 18:35, Ryan Lubke <ryan.lubke_at_oracle.com
> <mailto: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?
Yes, Transport.configureBlocking(boolean).
> 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.
A recent blog entry [1] touched on this subject. Take a look at the
section on Write I/O Throttling. We can answer more specific questions
after your doing so.
>
> 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.
Agreed, hence our willing to make the change on our end.
>
>
>> * 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
>