On the subject of a "write queue", no GlassFish ORB does not have one or
use one. The WorkerThread which formulates an outbound message also
writes the outbound message bytes. If the underlying channel cannot
accept all the bytes to be written, that same WorkerThread will block
using a temporary Selector until all bytes are written.
I personally always wanted to integrate a write queue in GlassFish ORB.
But, never got enough time to experiment with it.
There was a fella on the mailing who had a notion of write queue with a
messaging type system. Perhaps he has some comments /
recommendations? We could also talk to the folks on our own MQ
product. I would think MQ would have a write queue.
Lastly, I agree. We need a "write queue". IMO, a messaging system
using Grizzly transport could be a very fast messaging system. But,
it's likely gonna need a "write queue".
charlie ...
Jeanfrancois Arcand wrote:
> Hi
>
> Oleksiy Stashok wrote:
>> Hello,
>>
>> Jeanfrancois, what I think we miss in Grizzly - it's some easy way
>> how response could be sent on server side in non-blocking manner.
>
> Agree. That was an early discussion we had on that list about a write
> queue. We just need to start the discussion :-) Unfortunalty Nabble
> wasn't enabled at that time so we can't see it.
>
> Because
>> what OutputWriter/SSLOutputWriter do - they really flush whole the
>> buffer... But this could be the bottleneck in some edge-cases like
>> slow network or similar. So I'm basically talking about similar
>> functionality non-blocking ConnectorHandler.write() proposes, but for
>> server side without using temporary selectors, timeouts and attempts.
>> I fill WriteFilter could be used in this case somehow, but I don't
>> see good example on how to use it.
>
> For Comet, I will need that filter :-) In GlassFish v2/Grizzly 1.0.17,
> I'm allowing Comet user to read/write non blocking. So a write filter
> is certainly welcome.
>
> But I also suspect we still have to think about a Write queue people
> can subscribe/publish to it. They publish a byte buffer and gets
> updated once the bb has been completely written. Maybe the Orb team
> has a solution (Sailfin has one I suspect as well).
>
>>
>> What do you think?
>
> I think we need to have one...just need to design it :-)
>
> Thanks!
>
> -- Jeanfrancois
>
>
>
>>
>> WBR,
>> Alexey.
>>
>> Jeanfrancois Arcand wrote:
>>> Hi,
>>>
>>> and the NIO writes are done in class:
>>>
>>> https://sailfin.dev.java.net/source/browse/sailfin/sip-stack/src/java/com/ericsson/ssa/container/StreamResponseDispatcher.java?rev=1.2&view=markup
>>>
>>>
>>> via OutputWriter and SSLoutputWriter.
>>>
>>> -- Jeanfrancois
>>>
>>> Jeanfrancois Arcand wrote:
>>>> Hi,
>>>>
>>>> the Grizzly's implementation of the SIP protocol:
>>>>
>>>> https://sailfin.dev.java.net/source/browse/sailfin/sip-stack/src/java/com/ericsson/ssa/container/#dirlist
>>>>
>>>>
>>>> The main classes to look at are:
>>>>
>>>> Controller, SelectorHandler and ConnectorHandler defined in:
>>>> -------------------------------------------------------------
>>>> https://sailfin.dev.java.net/source/browse/sailfin/sip-stack/src/java/com/ericsson/ssa/container/GrizzlyNetworkManager.java?rev=1.3&view=markup
>>>>
>>>>
>>>> ProtocolFilter implementation
>>>> -----------------------------
>>>> https://sailfin.dev.java.net/source/browse/sailfin/sip-stack/src/java/com/ericsson/ssa/container/MessageProcessorFilter.java?rev=1.1&view=markup
>>>>
>>>>
>>>> The code is still based on 1.5.2 and will soon be updated to 1.6.x.
>>>> It support TLS, UDP and TCP.
>>>>
>>>> Have fun!
>>>>
>>>> -- Jeanfrancois
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
--
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>