Details

    • Type: Sub Task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.1-JPA
    • Component/s: JPA, Unit Testing
    • Labels:
      None
    • Rice Module:
      KSB

      Description

      Make KSB unit tests work with our JPA implementation

        Attachments

          Activity

          Hide
          gilesp Peter Giles (Inactive) added a comment -

          I had a sticks and bubblegum fix for MEssageQueueDAOJpaImpl at the f2f that had all of the tests passing, but I'm having a heck of a time making this work without resorting to using JPQL for deletes. Right now with my local code there is a timing issue where two removes of the same entity are happening at the same time in different threads, and an OptimisticLockException almost always occurs that breaks the test. The only remedy I've been able to come up with is equally horrible, putting the remove in a synchronized block which locks on a VM-global object. Lots of head banging going on here.

          Show
          gilesp Peter Giles (Inactive) added a comment - I had a sticks and bubblegum fix for MEssageQueueDAOJpaImpl at the f2f that had all of the tests passing, but I'm having a heck of a time making this work without resorting to using JPQL for deletes. Right now with my local code there is a timing issue where two removes of the same entity are happening at the same time in different threads, and an OptimisticLockException almost always occurs that breaks the test. The only remedy I've been able to come up with is equally horrible, putting the remove in a synchronized block which locks on a VM-global object. Lots of head banging going on here.
          Hide
          gilesp Peter Giles (Inactive) added a comment -

          Still working on StoreAndForwardTest. I put a sequence diagram together to help reason about what I'm seeing and attached it here: https://test.kuali.org/confluence/display/KULRICE/Store+and+Forward+implementation

          It appears to be a timing issue: after the service method is invoked on the destination service from the KSB-Pool thread, it goes to delete the PersistedMessage. At about the same time, the main thread's MessageServiceInvoker is trying to delete it's copy of the PersistedMessage. Almost all of the time this is resulting in an OptimisticLockException when I'm testing. It didn't happen with OJB, but I'm guessing it was just due to fortunate timing – I may be wrong though.

          So here are a few questions:

          1. Why is the PersistedMessage being persisted at all? It doesn't seem to ever be retrieved during its lifetime.
          2. Any idea why the ForwardedCallHandler makes a copy of the PersistedMessage and then does nothing with it?
          3. I have one hypothesis, which is that the ForwardedCallHandler is actually supposed to pass on the copy it made of the PersistedMessage, which would then be saved / deleted in a separate row and no OptimisticLockException would occur. Does that sound plausible?

          In the truly asynchronous case (without the SynchronousServiceCallProxy involved), it seems like the persisted message would be stored and deleted rather quickly, then stored and deleted again. I'm not sure what the point is.

          Show
          gilesp Peter Giles (Inactive) added a comment - Still working on StoreAndForwardTest. I put a sequence diagram together to help reason about what I'm seeing and attached it here: https://test.kuali.org/confluence/display/KULRICE/Store+and+Forward+implementation It appears to be a timing issue: after the service method is invoked on the destination service from the KSB-Pool thread, it goes to delete the PersistedMessage. At about the same time, the main thread's MessageServiceInvoker is trying to delete it's copy of the PersistedMessage. Almost all of the time this is resulting in an OptimisticLockException when I'm testing. It didn't happen with OJB, but I'm guessing it was just due to fortunate timing – I may be wrong though. So here are a few questions: 1. Why is the PersistedMessage being persisted at all? It doesn't seem to ever be retrieved during its lifetime. 2. Any idea why the ForwardedCallHandler makes a copy of the PersistedMessage and then does nothing with it? 3. I have one hypothesis, which is that the ForwardedCallHandler is actually supposed to pass on the copy it made of the PersistedMessage, which would then be saved / deleted in a separate row and no OptimisticLockException would occur. Does that sound plausible? In the truly asynchronous case (without the SynchronousServiceCallProxy involved), it seems like the persisted message would be stored and deleted rather quickly, then stored and deleted again. I'm not sure what the point is.
          Hide
          gilesp Peter Giles (Inactive) added a comment -

          Determined that the problems with getting the MessageQueueDAOJpaImpl working well enough for the unit tests to pass stemmed from a bug in the ForwardedCallHandlerImpl. See KULRICE-3887

          Show
          gilesp Peter Giles (Inactive) added a comment - Determined that the problems with getting the MessageQueueDAOJpaImpl working well enough for the unit tests to pass stemmed from a bug in the ForwardedCallHandlerImpl. See KULRICE-3887

            People

            • Assignee:
              gilesp Peter Giles (Inactive)
              Reporter:
              jjhanso Jeremy Hanson
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: