Speaking from experience with JXTA, the biggest problems we faced with
queues is bounding resources, initially we imposed fixed client queues
and sizes, then moved on to a dynamic fairness quota system based on
message destinations and resources available, which meant in some cases
messages are dropped (even the dropping policy became an issue in
itself, do you drop the oldest or newest, either case will break an
app). Queues also add to latency, which varies by how saturated the
queues are and how constrained the resources which service them.
In the recent release of JXTA (2.5), we have decided to remove the
fairness quota queues, in favor of a self throttling platform,
read/process based on available resources. For SIP, I am sure the
policies are different from those imposed on a transport, however, I
wanted to share our experience to avoid some of the pitfalls we have
been through.
Cheers,
Mohamed
charlie hunt wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>