Re: A simple flow control scheme.

This also means that flow control for UDP won't do much good. UDP simply 
runs out of memory faster. The only way to make it perform better, is to add 
more physical memory (or set the memory allocated to the JVM higher if 
possible). If you haven't already done so, you can also try to run the 
concurrency test on 2 machines (so each will have full memory)

Regards,
Jeroen

Jeroen van Bemmel wrote:
> Ranga,
>
> I have seen other cases where TCP outperformed UDP. This probably has
> to do with the fact that transactions live much shorter when using
> TCP, hence much less memory is used (because it is released sooner),
> hence less GC and better overall performance. Especially when running
> everything on only 1 machine, the TCP overhead disappears and regular
> TCP flow control mechanisms don't kick in. Create a graph of memory
> usage (eg using jconsole) for both UDP and TCP and you will see
>
> I also noticed the queue limiting code for UDP (with hardcoded low/hi
> watermark) , IMHO that's not a good idea. Suggestion to at least make
> it optional (off by default), and the low/high levels configurable.
>
> Regards,
> Jeroen
>
> M. Rangnathan wrote:
>> Hi folks,
>>
>> Noting that TCP outperforms UDP by a factor of 2 for
>> test.load.concurrency, I added a mechansm to limit the size of  the
>> client tranasaction table. Basically, if the mechanism is enabled (
>> using the gov.nist.javax.sip.MAX_CLIENT_TRANSACTIONS property -- see
>> SipStackImpl javadoc ), the caller blocks until the value falls below
>> a threshold when you go to create a new client transaction. The
>> danger is of course that if the caller blocks, that could lead to
>> deadlock if the caller is not re-entrant. Thus this feature is "off"
>> by default.
>> I am still not able to match TCP performance or even imporove the
>> performance using UDP no matter what I do with flow control  but
>> perhaps somebody can look at that code ( see SIPTransactionStack.java
>> ) and comment about better means of doing flow control for UDP.  In
>> any case, this is a safety mechanism for servers to limit what the
>> application can do ( i.e. if an application overwhelms the poor SIP
>> Stack in a SLEE environment). If you are writing server applications
>> of this kind (i.e. containers and whatnot where you expect third
>> party code to run), it could be of interest to you.
>>
>> Regards,
>>
>> Ranga