6 Replies Latest reply on May 3, 2013 3:32 AM by objectiser

    Transaction behavior with faults/errors

    kcbabo
    kcbabo Apr 30, 2013 4:49 PM

      Tomo and I have been discussing SWITCHYARD-1431 and I wanted to open the discussion up to a wider audience based on the scope of changes.  Here is a summary of the proposed changes:

       

      • TransactionHandler will set active transactions to rollbackOnly when an unexpected fault/error occurs.
      • Expected exceptions are documented in the service contract.
      • Unexpected exceptions include:
        • RuntimeException
        • SwitchYardException
        • HandlerException wrapping an exception not documented in the service contract.
      • Since components are in the best position to determine whether the exception is expected or not, each component is expected to do the following:
        • Unexpected exceptions are thrown as HandlerException
        • Expected exceptions are communicated via sendFault().
      • A component involved in a message exchange can "opt out" of this automatic rollback behavior via a context property at Scope.EXCHANGE.

       

      The following changes will be required at a minimum:

      • Define a constant for the "opt out" rollback property.  A place in core/api is preferable and Exchange seems like a good spot.
      • TransactionHandler needs to be updated to check fault status and the message content to determine if it's RuntimeException, SwitchYardException, or HandlerException.  If it's one of these cases and a transaction is in progress, set it to rollback.
      • Components need to be updated to *not* report expected faults using HandlerException.  The bean component is doing the wrong thing for sure.  I think SOAP gateway is doing the right thing based on a cursory review.

       

      Feedback and corrections are welcome.

      • 657 Views
      • Tags:
        • 1. Re: Transaction behavior with faults/errors
          objectiser
          objectiser May 1, 2013 4:23 AM (in response to kcbabo)

          Sounds good to me.

           

          Just so that I understand, currently the BPEL component will need to use the "opt out" mechanism, as it returns an expected fault as a BPELFault (derived from HandlerException)? This is the fix that Tomo previously applied.

           

          Originally the BPELFault (and accompanying transformer) was introduced because there was an issue returning a SOAPFault via the sendFault method - do we know if this is still the case, as it would be good if the BPEL component could simply return the SOAPFault using the sendFault call?

           

          Regards

          Gary

            • Actions
          • 2. Re: Transaction behavior with faults/errors
            igarashitm
            igarashitm May 1, 2013 7:48 AM (in response to objectiser)

            So, we just happened to get back here - https://issues.jboss.org/browse/SWITCHYARD-437

             

            Actually Tom said throwing HandlerException is the right thing rather than sendFault() for the decleared fault at that time. I'll take a look what happen if BPEL exchange handler use sendFault() to send SOAPFault again.

             

            Thanks for letting me remind it

              • Actions
            • 3. Re: Transaction behavior with faults/errors
              kcbabo
              kcbabo May 1, 2013 8:09 AM (in response to objectiser)

              Just so that I understand, currently the BPEL component will need to use the "opt out" mechanism, as it returns an expected fault as a BPELFault (derived from HandlerException)? This is the fix that Tomo previously applied.

               

              I think we should change this behavior based on the guidelines presented above.  That said, your understanding is correct that returning BPELFault with the opt out header would not cause a rollback.

               

              Originally the BPELFault (and accompanying transformer) was introduced because there was an issue returning a SOAPFault via the sendFault method - do we know if this is still the case, as it would be good if the BPEL component could simply return the SOAPFault using the sendFault call?

              Retuning a SOAPFault via the sendFault() method should work.  If it doesn't work, I would consider it a bug.

                • Actions
              • 4. Re: Transaction behavior with faults/errors
                kcbabo
                kcbabo May 1, 2013 8:11 AM (in response to igarashitm)

                I'm sure that what Tom said accurately reflected the state of things at the time.  I think we need to take another look at this now that the components and runtime have matured - sendFault() is designed to accept faults, so it should be perfectly legit.  If you could have a look and identify if/where the problem lies, that would be great.

                So, we just happened to get back here - https://issues.jboss.org/browse/SWITCHYARD-437

                 

                Actually Tom said throwing HandlerException is the right thing rather than sendFault() for the decleared fault at that time. I'll take a look what happen if BPEL exchange handler use sendFault() to send SOAPFault again.

                 

                  • Actions
                • 5. Re: Transaction behavior with faults/errors
                  igarashitm
                  igarashitm May 2, 2013 10:07 PM (in response to kcbabo)

                  OK, fixed as described in above guideline Keith suggested. Whole build (parent~release) was fine on my hand.

                   

                  https://github.com/igarashitm/core/tree/SWITCHYARD-1431

                  https://github.com/igarashitm/components/tree/SWITCHYARD-1431

                   

                  Here is the list of what I changed and some questions for implementation.camel, implementation.bpel, binding.rest:

                  • implementation
                    • bean
                      • added sendFault() logic on declared exceptions
                      • added throw HandlerException() on undeclared exception for IN_ONLY as well (it used to just log for IN_ONLY and was not throwing any exception)
                    • camel
                      • added sendFault() logic on declared fault for IN_OUT
                        • ? Is there any possibility to get false from camelExchange.isFault() in spite of getException() returning null? currently it's treated as succeeded
                    • bpel
                    • clojure
                      • added sendFault() logic on declared fault
                    • rules/jbpm
                      • nothing to do (throws unexpected RuntimeException only)


                  • gateway
                    • camel
                      • added sendFault() logic on declared fault for IN_OUT
                    • hornetq
                      • nothing to do (oneway)
                    • soap
                      • nothing to do (already doing right)
                    • http
                      • nothing to do (already doing sendFault() for 4xx and 5xx HTTP status code)
                    • jca
                      • nothing to do (throws unexpected HandlerException only)
                    • resteasy
                      • ? nothing to do? (throws unexpected HandlerException only?)

                   

                  Any comment would be appreciated!

                   

                  Thanks,

                  Tomo

                    • Actions
                  • 6. Re: Transaction behavior with faults/errors
                    objectiser
                    objectiser May 3, 2013 3:32 AM (in response to igarashitm)

                    Tomohisa igarashi wrote:

                     

                     

                    Thanks for doing this work Tomo. Once we are sure there are no issues, then I'll remove the BPELFault + transformer.

                     

                    Regards

                    Gary

                      • Actions