Milyn
  1. Milyn
  2. MILYN-608

NullpointerException: Intermittent Exception in Smooks 1.4

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Blocker Blocker
    • Resolution: Unresolved
    • Affects Version/s: Smooks v1.4
    • Fix Version/s: None
    • Component/s: Smooks Javabean
    • Labels:
      None
    • Environment:
      Linux
    • Number of attachments :
      1

      Description

      In Smooks 1.4: We are seeing the NullPointer Exception intermittently.

      Please find the attached doc for more error stack. It would be great if you could help us to resolve this issue.

        Activity

        Hide
        Tom Fennelly added a comment -

        Looks like you're calling close on the Smooks instance and then reusing it. Or you may just have a race condition with one thread closing the Smooks instance while another is still using it. Basically... check your code for where you're calling Smooks.close().

        Show
        Tom Fennelly added a comment - Looks like you're calling close on the Smooks instance and then reusing it. Or you may just have a race condition with one thread closing the Smooks instance while another is still using it. Basically... check your code for where you're calling Smooks.close().
        Hide
        Shankaran Krishnaswamy added a comment -

        The reason we faced this issue is , smooks.close() does not do a full cleanup and for a long time smooks is able to continue functioning without erroring out post a call to close(). The thing that exposed this bug is a bad first record immeditaly after server startup, that we sent in for a negative test case that failed during a timestamp decoding. That leaves smooks not fully initialized in certain respects as regards the static configuration itself - like the objects in AbstractDeliveryConfig.objectsTable. It seems that the Null checks around BeanInstancePopulator.getDecoder() leading upto AbstractDeliveryConfig.getObjects() ensure that configuration artifacts continue to be alive and kicking even after smooks.close().

        smooks.close() should be a hard close() with all configuration wiped out to ensure smooks does not function past that method call.

        Show
        Shankaran Krishnaswamy added a comment - The reason we faced this issue is , smooks.close() does not do a full cleanup and for a long time smooks is able to continue functioning without erroring out post a call to close(). The thing that exposed this bug is a bad first record immeditaly after server startup, that we sent in for a negative test case that failed during a timestamp decoding. That leaves smooks not fully initialized in certain respects as regards the static configuration itself - like the objects in AbstractDeliveryConfig.objectsTable. It seems that the Null checks around BeanInstancePopulator.getDecoder() leading upto AbstractDeliveryConfig.getObjects() ensure that configuration artifacts continue to be alive and kicking even after smooks.close(). smooks.close() should be a hard close() with all configuration wiped out to ensure smooks does not function past that method call.
        Hide
        Tom Fennelly added a comment -

        So guys, can you clarify... is your code calling Smooks.close() and then making subsequent calls to Smooks.filterSource (Yes/No)?

        We should certainly add a check in the Smooks.filterSource() method to check that the instance has not already been closed. This however would not solve the situation where multiple threads are concurrently executing filtering ops on a single Smooks instance and one of those threads closes the smooks instance while the others are still processing. This needs to be managed by your containing app.

        Show
        Tom Fennelly added a comment - So guys, can you clarify... is your code calling Smooks.close() and then making subsequent calls to Smooks.filterSource (Yes/No)? We should certainly add a check in the Smooks.filterSource() method to check that the instance has not already been closed. This however would not solve the situation where multiple threads are concurrently executing filtering ops on a single Smooks instance and one of those threads closes the smooks instance while the others are still processing. This needs to be managed by your containing app.
        Hide
        subbaraj jeganathan added a comment -

        Yes.The case where we got the exception.

        Show
        subbaraj jeganathan added a comment - Yes.The case where we got the exception.

          People

          • Assignee:
            Unassigned
            Reporter:
            subbaraj jeganathan
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: