This was caused by the fact the the SipContainerThreadPool is not initialized
when the Servlet.init() method is executed for all deployed servlets at startup.
Specifically, the timer queues has not been created yet. Now, if the application
creates a timer, i.e., if it creates a SipApplicationSession, there will be a
null pointer exception due to that the field SipContainerThreadPool.timerQueues
is null in the execution of SipContainerThreadPool.nextTimerQueue() method.
However, due to the way the java byte code is laid out in a expression like this:
TimerQueue q = timerQueues[curTimerQueue++];
The updated value of the field 'curTimerQueue' is stored before doing the actual
array access, thus causing the 'curTimerQueue' to be updated although an NPE is
thrown, which might not be what one expect.
This causes the subsequent comparison of 'curTimerQueue' with timerQueues, to
not be executed.
As a consequence of this the 'curTimerQueue' will point past the length of the
array at the next call to, which results in an ArrayOutOfBoundsException. Now
the same problem occurs, i.e., the 'curTimerQueue' is updated before the the
exception is thrown and the subseqent check for wrap-around is not executed,
thus causing the 'curTimerQueue' to grow infinitely.
This is corrected by the following two things:
1. The timer queues are now created directly when the SipContainerThreadPool is
2. The construct of the array access is changed so that incrementation is
performed in a separate statement after the array access.