Incoming SIP message handling

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