sailfin
  1. sailfin
  2. SAILFIN-1782

SipContainerThreadPool: ArrayOutofBoundException

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.0
    • Fix Version/s: milestone 1
    • Component/s: sip_container
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Macintosh

    • Issuezilla Id:
      1,782

      Description

      Please see this thread for details.
      http://www.nabble.com/ArrayIndexOutOfBoundsException-in-2-node-cluster-
      tp23655295p23655295.html

        Activity

        Hide
        ehsroha added a comment -

        Reassign to Sankar

        Show
        ehsroha added a comment - Reassign to Sankar
        Hide
        joelbinn added a comment -

        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
        instantiated.
        2. The construct of the array access is changed so that incrementation is
        performed in a separate statement after the array access.

        Show
        joelbinn added a comment - 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 instantiated. 2. The construct of the array access is changed so that incrementation is performed in a separate statement after the array access.

          People

          • Assignee:
            sankara
            Reporter:
            binod
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: