Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-1110

Locks not cleared when listener throws exception

This issue belongs to an archived project. You can view it, but you can't modify it. Learn more

XMLWordPrintable

    • Workaround Exists
    • Hide

      The issue can easily be avoided if the exception happens after the operation, in other words, when isPre=false

      Show
      The issue can easily be avoided if the exception happens after the operation, in other words, when isPre=false
    • Medium

      If a listener implementation throws an exception (at least when isPre()) when a new entry is created, acquired locks are unreleased.

      So, concurrent invocations on same key will fail with a timeout exception

        1. ListenerThrowsExceptionTest.java
          3 kB

            [ISPN-1110] Locks not cleared when listener throws exception

            Galder Zamarreño added a comment -

            This is only limited to exceptions when the entry is first created. When the entry is modified it works fine.

            The problem when entry is created and the exception is thrown on isPre=true is that the context is empty and so the release finds nothing to unlock. Checking what the options are to fix this.

            Galder Zamarreño added a comment - This is only limited to exceptions when the entry is first created. When the entry is modified it works fine. The problem when entry is created and the exception is thrown on isPre=true is that the context is empty and so the release finds nothing to unlock. Checking what the options are to fix this.

            Galder Zamarreño added a comment -

            Not in a single class. The UT attached is just a quick version that I used to verify the issue. The test that I ended up using for ISPN-1091 where all this started had to use isPre=false in the end and so I know that works fine. Clearly though when I fix this the listener test will be enhanced to cover both cases.

            Galder Zamarreño added a comment - Not in a single class. The UT attached is just a quick version that I used to verify the issue. The test that I ended up using for ISPN-1091 where all this started had to use isPre=false in the end and so I know that works fine. Clearly though when I fix this the listener test will be enhanced to cover both cases.

            Manik Surtani (Inactive) added a comment -

            Do you have a unit test for this, both with isPre() == true as well as false?

            Manik Surtani (Inactive) added a comment - Do you have a unit test for this, both with isPre() == true as well as false?

            Galder Zamarreño added a comment -

            I discovered this while trying to induce a failure for ISPN-1091.

            Galder Zamarreño added a comment - I discovered this while trying to induce a failure for ISPN-1091 .

              rh-ee-galder Galder Zamarreño
              rh-ee-galder Galder Zamarreño
              Archiver:
              rhn-support-adongare Amol Dongare

                Created:
                Updated:
                Resolved:
                Archived: