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