Thanks Kristoffer.
Unfortunately we haven't formalized it into a document. The JXTA
platform (think of it as a transport of sort) for the most part is
asynchronous, with synchronous api's exposed at the application layer,
therefore making it easy control the flow, which mainly done through use
of NIO selectors and thread pools. Thus allowing us to rid the use of
queues (at the endpoint), and rely on higher level API's to provide
reliability, which then rely on queues to deal with any needed
retransmits or flow control.
JXTA also offers relay transports which use fixed client queues and
imposed message expiry, which shares some similarities to what SIP would
require, we probably should measure the message drop/retransmit ratio
under various loads and look for creative ways of optimizing resources.
If there are JMS folks on this list, I would like to hear their
perspective on managing resource.
Mohamed
Kristoffer Gronowski (KI/EAB) wrote:
> Hi Mohamed!
>
> Thanks for given your experience on this matter!
> When it comes to SIP the problem lies in the asynchronous behavior.
> Could you give some more line on your throttling design or is it in a
> FSD somewhere?
>
> Let me see if it has similarities with what we done.
> We have been using the principal that first priority is to get rid of
> messages.
> Write has priority over read. Then we have a pluggable architecture when
> the default behavior would be to reject traffic that first initiates new
> sessions because that Leeds to many subsequent req/resp. Another big
> problem is an application that is a exploder. Ex chat server. One
> message in results in 100 out. In that case a queue is needed. SIP has
> also timers so that if someone was not quick enough to answer or broke
> down the timer will then generate a 408 response to the initial request
> so that all nodes on the path can clean up.
>
> This will most certainly be the same problem of flow control that
> asynchronous HTTP will be facing but there it is not as easy to
> understand what direction a application message is traveling. The not so
> easy parts in both cases is that there is an application on top in a
> Servlet and you as the container implementer have hard time to guard for
> all the possibilities.
>
> BR Kristoffer
>
> -----Original Message-----
> From: Mohamed.Abdelaziz_at_Sun.COM [mailto:Mohamed.Abdelaziz_at_Sun.COM]
> Sent: den 6 september 2007 19:35
> To: dev_at_grizzly.dev.java.net
> Subject: Re: [OT] Grizzly's SIP implementation code
>
> 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/ja
>>>>> va/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/j
>>>>>> ava/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/j
>>>>>> ava/com/ericsson/ssa/container/GrizzlyNetworkManager.java?rev=1.3&
>>>>>> view=markup
>>>>>>
>>>>>>
>>>>>> ProtocolFilter implementation
>>>>>> -----------------------------
>>>>>> https://sailfin.dev.java.net/source/browse/sailfin/sip-stack/src/j
>>>>>> ava/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
>>
>>
>
> ---------------------------------------------------------------------
> 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
>
>