Details

    • Type: Sub Task Sub Task
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.1-JPA
    • Component/s: JPA, Unit Testing
    • Labels:
      None
    • Similar issues:
      KULRICE-3861Make KNS unit tests work with JPA
      KULRICE-3859Make rice unit tests work with JPA
      KULRICE-3862Make KEW unit tests work with JPA
      KULRICE-3863Make KIM unit tests work with JPA
      KULRICE-3864Make KEN unit tests work with JPA
      KULRICE-3896KNS Unit Test BOs need to be JPA annotated
      KULRICE-13860Implement a more extensive suite of integration and unit tests against the KSB module
      KULRICE-3853JPA - Proof of concept with sequence / identity/ prePersist
      KULRICE-3813JPA - JPA 2.0 testing
      KULRICE-4161JPA: make KEN JPA works
    • Rice Module:
      KSB

      Description

      Make KSB unit tests work with our JPA implementation

        Activity

        Hide
        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
        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
        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
        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
        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
        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:
            Peter Giles (Inactive)
            Reporter:
            Jeremy Hanson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel