Re: Incoming SIP message handling

Lebing, Ranga,
   Thanks for your replies, we are examining this issue further.
Regards,
Becky

Lebing Xie wrote:

>I think you are building a Sip Servlet Container. As my experience,
>well, after thread from Stack hands off the message instance to the
>thread from ur pool, it is free again and can be used by stack for other
>incoming messages, the request states are only some instances which
>saved in stack. 
>I have checked out the HTTP server as Tomcat, it does the same, do not
>know how the java.net and system TCP/IP stack and thread pool work.
>
>Interesting question, correct me if I am wrong. urs Lebing
>
>
>On Fri, 2006-03-10 at 08:31 -0500, Becky McElroy wrote:
>  
>
>>Hi,
>>
>>We have a situation with handling of incoming SIP requests to our 
>>server. We use a thread pool in our server to take the incoming SIP 
>>messages from the nist sip stack and hand them off to applications, and 
>>the applications work on the messages off of the threads in the thread 
>>pool. The reason we did this was to prevent an application processing a 
>>message from taking a long time, thus blocking any more SIP messages 
>>being received/processed until that application returned from processing 
>>the message. So when a SIP message comes in, a thread in the pool is 
>>selected to 'receive' the message from the stack and it returns back to 
>>nist stack immediately. The application can then take as long as it 
>>needs and other SIP messages can continue to be received and processed 
>>by other applications. The problem comes in because when the thread pool 
>>thread returns from receiving the message, the stack thinks the message 
>>processing is overwith (response sent, etc.).
>>
>>Any suggestions here on what can be done to make this strategy work with 
>>the nist stack, for any scenario? The details of the problem reported to 
>>us are below. Thanks for any advice or help-
>>Becky
>>
>>_______________________
>>
>>I have been sending in a Subscribe method from a test program using 
>>sipunit. The initial subscribe by the nist sip stack calls the 
>>SipConnector.processRequest which sends the request to my jiplet in a 
>>separate thread.  The problem appears to be related to dialogs and this 
>>processing described above.  My jiplet code that processes the Subscribe 
>>method uses the dialog to create a response but the processRequest in 
>>SipConnector has already returned to deliverEvent in 
>>gov.nist.javax.sip.EventScanner.java.  This Nist sip stack should call 
>>dialog.requestConsumed() but my jiplet processing isn't finished yet and 
>>the next seq nbr in the dialog object doesn't get updated.  This 
>>behavior is only discovered when I send in another Subscribe method with 
>>the same Callid, toTag, FromTag and a call seq nbr of 2.  The Nist sip 
>>stack then looks to see what the next seq no is for that dialog, which 
>>should be 2 but the stack sees a one and discards the message.  To see 
>>if my theory was correct, I added a sleep(2000) after the for loop in 
>>SipConnector.processRequest() and the problem is fixed.  I realize this 
>>isn't a good solution but I was just trying to prove my theory.  The 
>>problem is related to a new thread being started by the jiplet for 
>>processing the Subscribe request.  The new thread hasn't finished 
>>updating the dialog reference that the deliverEvent() method is going to 
>>use.  I turned off all logging/tracing
>> 
>>
>>
>>_______________________________________________
>>nist-sip mailing list
>>[email protected]
>>http://www-x.antd.nist.gov/mailman/listinfo/nist-sip
>>    
>>
>
>
>  
>