On 2/6/12 1:38 PM, Ryan Lubke wrote:
> On 2/6/12 1:22 PM, Matthew Swift wrote:
>> Thanks Ryan.
>>
>> I've put my response inline...
> See inline...
It would help if I included the link...
[1]
http://www.notshabby.net/2011/12/grizzly-2-2-now-available/
>>
>>
>> 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
>>
>