Gregory W Bond - 2012-06-05

here is the email history between tom and me discussing the issue and proposing a fix

On Jun 4, 2012, at 9:02 PM, Tom Smith wrote:

I think the SipApplicationSession.isValid() check is safer - otherwise the SipApplicationSession.getAttribute() call might throw an Exception. Or maybe combine the two:

SipApplicationSession sas = timer.getApplicationSession();
if( sas.isValid() && sas.getAttribute(FEATURE_BOX) != null ) {
...
}

On Jun 4, 2012, at 6:08 PM, Gregory Bond wrote:

at what point in the dispatched timer thread's execution does it attempt to lock the app session? if it attempts to do so before TransitionTimerManager.timeout() is invoked (thinking about it, i can't think of another logical point in the thread's execution that this might occur) then we could simply check for the existence of the EChartsSipServlet.FEATURE_BOX attribute in the timeout() method (since this attribute will be removed when the feature box is destroyed) -

On Jun 4, 2012, at 9:46 AM, Tom Smith wrote:

Sounds completely plausible. Note that the way the TransitionTimerManager locates the box is:

final TransitionTimerPort port = (TransitionTimerPort) timer.getInfo();
final BoxMachine boxMachine = (BoxMachine) port.getMachine().getRootMachine();

This does not involves any operations on the SipApplicationSession, so it could try to advance the machine without encountering any Exceptions beforehand due to invalid SAS. We could put a check in TransitionTimerManager.timeout(t) to check that the SAS is valid before advancing the machine. If your hypothesis is right, this check should prevent the Exception. In any case, it should not prevent any valid transitions from firing.

On Jun 4, 2012, at 8:57 AM, Gregory Bond wrote:

there are a couple of possibilities i came up with on the train yesterday but the one i'm focusing on is the following: the log indicates that a SIP thread is dispatched to handle the final 200 BYE response - this results in moving the machine to its terminal state and calling the FeatureBox.destroy() method which, in turn, cancels all outstanding timers - i am thinking about the case that, while the SIP thread has the application session lock, the timer expires and a timer SIP thread is dispatched - because the application is locked by the message SIP thread, the timer SIP thread is blocked - while the timer SIP thread is blocked, the message SIP thread cancels outstanding timers - the question i have is: what happens to the blocked timer SIP thread when outstanding SIP timers are canceled? i expect that it won't be canceled, because its timer has already expired - therefore it will run once the message SIP thread relinquishes the application session lock - what do you think?

greg