Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-985

Service Bus does not honor message.persistence property in certain situations

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.9.0.3, KSB - 0.9.0.3
    • Fix Version/s: 0.9.0.3, KSB - 0.9.0.3
    • Component/s: Development
    • Labels:
      None
    • Similar issues:
      KULRICE-4193Local/Standalone Rice cannot customize the exportation of certain SOAP services
      KULRICE-3706Expose IdentityManagementNotificationService as a SOAP Service on the Bus
      KULRICE-5007WorkflowDocument.placeInExceptionRouting only works if message.persistence=false
      KULRICE-3721The "remote" run mode for KIM (and other Rice modules?) does not allow proper consumption of services from the bus
      KULRICE-8126Collection control does not honor disable if disable is disabled by an expression for collection refresh
      KULRICE-4451Re-examine how RiceApplicationConfigurationService is being used to resolve doc handler urls (and other variables) from across the service bus
      KULRICE-9497Convert Administration > Service Bus screens to KRAD
      KULRICE-10930Create Automated Functional (Smoke) Tests for Service Bus (old sample app)
      KULRICE-137Develop bus bridge components
    • Rice Module:
      KSB

      Description

      In Onestart 2, they have their message.persistence property set to false. However, whenever there's an error invoking a message the code is attempting to persist the message (see the attached stack trace). I wonder if this is somehow causing the CLOB error message? Regardless, I think we need a test in the KSB code which tests a message with a potentially very large payload (> 4000 characters) to ensure there isn't a legitimate bug here.

      There another potential issue with the bus that we noticed in the load tests from Onestart 2:

      As seen in the attached stack trace, they are getting a NullPointerException from the service being invoked across the bus. They think this would only happen if the code in the called service which attempted to load the object couldn't find it. Not sure if there is an issue here or not but could it be that the asynchronous message is getting sent and invoked before the original transaction is committed even though this shouldn't be happening? Just curious because I know this was originally depending on JTA synchronizations. Not sure how this was addressed when the JTA requirement was dropped.

        Issue Links

          Activity

          Hide
          Eric Westfall added a comment -

          Added Jeremy as a watcher. Jeremy, if there's anything else you want to add to this issue please do.

          Show
          Eric Westfall added a comment - Added Jeremy as a watcher. Jeremy, if there's anything else you want to add to this issue please do.
          Hide
          Aaron Godert (Inactive) added a comment -

          Any idea how much this one would take to fix? I really want to get 0.9.0.3 out the door both for a public release, but also to get KRA settled for a good chunk of the 0.9.1 development phase.

          Show
          Aaron Godert (Inactive) added a comment - Any idea how much this one would take to fix? I really want to get 0.9.0.3 out the door both for a public release, but also to get KRA settled for a good chunk of the 0.9.1 development phase.
          Hide
          Ryan Kirkendall (Inactive) added a comment -

          When there's no JTA transaction there is no synchronization the message is just sent as soon as it arrives so that may be problematic. That's just how Nate and I implemented and I assumed it wasn't a problem. Easy fix: find a way to register for synchronizations on the PlatformTransactionManager. That may require a subclass, which is too bad.

          The bus may be attempting to persist the messages in exception routing. Surely, we can save messages greater the 4000 characters. We're doing that in KFS right?

          Show
          Ryan Kirkendall (Inactive) added a comment - When there's no JTA transaction there is no synchronization the message is just sent as soon as it arrives so that may be problematic. That's just how Nate and I implemented and I assumed it wasn't a problem. Easy fix: find a way to register for synchronizations on the PlatformTransactionManager. That may require a subclass, which is too bad. The bus may be attempting to persist the messages in exception routing. Surely, we can save messages greater the 4000 characters. We're doing that in KFS right?
          Hide
          Eric Westfall added a comment -

          Yes, that is a problem for the way Onestart2 is using the bus although they may be able to work around it. As for the 4000 character issue, I was going to look into that when I have some time.

          Show
          Eric Westfall added a comment - Yes, that is a problem for the way Onestart2 is using the bus although they may be able to work around it. As for the 4000 character issue, I was going to look into that when I have some time.
          Hide
          Ryan Kirkendall (Inactive) added a comment -

          This is happening because the message is going into exception routing. The default exception routing is trying to save the message so that is the lack of honoring the contract - seems like it should persist in this case but maybe not. According to the stacktrace we're still having the OJB clob save issue. Make it so OJB isn't saying use Oracle 9i or whatever and your problem probably going to be solved. Have you tried putting a normal 1.0.4 OJB in Onestart2 and not the modded one for JOTM?

          Show
          Ryan Kirkendall (Inactive) added a comment - This is happening because the message is going into exception routing. The default exception routing is trying to save the message so that is the lack of honoring the contract - seems like it should persist in this case but maybe not. According to the stacktrace we're still having the OJB clob save issue. Make it so OJB isn't saying use Oracle 9i or whatever and your problem probably going to be solved. Have you tried putting a normal 1.0.4 OJB in Onestart2 and not the modded one for JOTM?
          Hide
          Eric Westfall added a comment -

          Not yet, will look into that when I get a chance (probably next week). I think it probably shouldn't persist the message in this case and rather rely on the person implementing the server to have an appropriate message exception handler implementation. If they ask for no persistence, let's give 'em no persistence In theory they should be able to run without a messageDataSource in that case (although I think there's some validation which is currently preventing that).

          Show
          Eric Westfall added a comment - Not yet, will look into that when I get a chance (probably next week). I think it probably shouldn't persist the message in this case and rather rely on the person implementing the server to have an appropriate message exception handler implementation. If they ask for no persistence, let's give 'em no persistence In theory they should be able to run without a messageDataSource in that case (although I think there's some validation which is currently preventing that).
          Hide
          Ryan Kirkendall (Inactive) added a comment -

          fixed in 0.9.0.3. Depending on how quartz is configured there may still be a save to the db. i think we should see if switching the OJB version resolves the exception because obviously, we need to know bug is behind that.

          Show
          Ryan Kirkendall (Inactive) added a comment - fixed in 0.9.0.3. Depending on how quartz is configured there may still be a save to the db. i think we should see if switching the OJB version resolves the exception because obviously, we need to know bug is behind that.
          Hide
          Aaron Godert (Inactive) added a comment -

          Did this one get pushed into 0.9.0.2 as well?

          Show
          Aaron Godert (Inactive) added a comment - Did this one get pushed into 0.9.0.2 as well?

            People

            • Assignee:
              Ryan Kirkendall (Inactive)
              Reporter:
              Eric Westfall
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel