Announcement Announcement Module
Collapse
No announcement yet.
error-channel on JMS adaptor Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    What you are describing is correct and is the intended behavior. If a RuntimeException propagates, then the transaction will not commit. That is exactly how rollbacks work. If you want to have a transaction commit, then you must ensure that no Exception propagates. In the case of the JMS gateway, if you have an error handling messaging flow that does not itself throw an Exception, then the transaction will commit.

    Comment


    • #17
      Originally posted by Mark Fisher View Post
      What you are describing is correct and is the intended behavior. If a RuntimeException propagates, then the transaction will not commit. That is exactly how rollbacks work. If you want to have a transaction commit, then you must ensure that no Exception propagates. In the case of the JMS gateway, if you have an error handling messaging flow that does not itself throw an Exception, then the transaction will commit.

      Agreed, but ERROR handling in my case do not throw any kind of Throwable/Error/Exception but still the message is not committed/removed from the input queue.

      And, after looking at the code above- how will transaction commit when there is no call to commit. I am confused.

      As per my earlier message, Tib message will not get moved/removed from queue unless there is commit. And, I do not see any commit when message is handled by Errorhandler.
      Last edited by rock_star; Feb 17th, 2011, 01:11 PM.

      Comment


      • #18
        In the code excerpt you pasted above, commitIfNecessary() is called as long as no exception has been thrown. If your transactions are not committing, that means an exception is triggering a rollback.

        Comment


        • #19
          Mark,

          I understand that but unfortuntaley----

          The exception is being thrown only in the exceution path/flow where a request comes and Unmarshaller tries to unmarshall the XML. This results in exception message which gets routed to error-channel.

          And, ErrorHandler listening on error-channel there, creates a custom response and puts on the responseTopic. The message is delivered to response topic( verified by listening to topic ).

          ISSUE: The input request message still stays on the input request queue. To me this is because, there was no explicit commit during the whole chain. And as per my message number 14 in this post( with sample)- TIB EMS expects the explicit commit.

          What I am pointing is that, there is no place in the ErrorHandler chain which will issue commit call to remove the message from request queue.

          Please respond if this is not clear and apologies for bad English.

          Expectations:

          Is there a way that I can call commit in ErrorHandler? Because unless commit is called in ErrorHandler the message in Tib queue will not be removed/deleted.

          Flow Diagram, which works in excellent manner when no exception.
          Code:
          Tibco EMS Queue---> Message Driven Adaptor( with Error-Channel atrribute)---->Unmarshaller--> Service Activator---> ResponseChannel---> JMS outbound message adaptor---> Tib Topic.
          Last edited by rock_star; Feb 17th, 2011, 04:14 PM.

          Comment


          • #20
            Guys,

            any response would be helpful for me.

            I had used similar framework in past and this is how it worked there.

            When there is a exception anywhere in the flow, the exception flows back to starting point( in this case Message Driven Adaptor) and then the error terminal( error-channel in SIntegartion ) had access to that partofucalr flowcontext, giving handle to context which was used to commit or rollback in ErrorHandler.

            I think similar stuff should be provided in Spring Integration, otherwise error-channel is not that useful in this scenario as there is no way to commot the original transaction( intotiating transaction) in the ErrorHandler.

            Example case:

            JMS Adaptor--SA1---> SA2-->SA3-->JMS Outbound

            Suppose all SA(s) do some DB operations then in case of exceptions I would really like rollback all DB transactions except the JMS start-transaction( which started at begining of flow) to get rid of message after I have tried maximum number of tries.

            Mark/Oleg,

            To me ErrorHandler feature is bug if it does not provide something to commit.

            Thanks for patience and I look forward to hear from you. Please read my previous message in this post as well.

            Comment


            • #21
              Hi Mark/Oleg,

              Can you please reply with your comments or suggest some alternate approach for this?

              I really need to use the transact mode of ack.

              Thanks

              Comment


              • #22
                Hi rock_star,

                Indeed, using the error-handler will rollback the transaction anyway, but using the error-channel attribute will not (unless the channel is synchronous and the subscriber to this channel throws an exception).
                We encountered your exact same case of looping indefinitely, and the error-channel feature solved it.

                I also believe that the error-handler has a strange behaviour, as it does not "handle" the error, it's just a plain listener but it does not "catch" the error as its name makes it sound like.
                However, the "error-channel" allows you to handle it just as you need (since SI 2.0 GA)

                Hope this helps,

                Pierre

                Comment


                • #23
                  Hi Pierre,

                  Thanks for response. I am using error-channel as well and as you have pointed, the channel in my case is direct( synchronous).

                  I had pollable( asynch) channel but I removed that earlier as I did not want to use for reasons like:

                  1) Suppose someone pushed 1000 trades and by mistake the trade message format got in bad shape and that will result in error and that will make all these messages bad formatted messages end-up in error-channel attribute based channel.

                  And, if my system crashes at this point then I would loose all these messages as they were on pollable channel. Had this transacted thin handled in sync channel based on error-channel attribute, then this would have been avoided.

                  I know there is solution to back up the messages played by using message store, which somehow is not liked by team at the moment

                  -------------------------------------

                  As of now, I have switched to pollable channel error-channel attribute for testing but will try out some alternative.

                  Thanks a lot, Pierre.

                  Comment


                  • #24
                    how to code an attach an error queue to a messagelistnercontainer!!!

                    hi all,

                    I have a problem i want to send all the message that result in an exception to a preconfigured queue , is there anything in the messagelistnercontainer to directly send such messages to an error queue.............as is the case in MDB , where after a configured number of retry mentoined in the ejb-jar.xml the message is sent to the system-error queue or any other configured error queue..!!!

                    regards and thanx

                    Comment

                    Working...
                    X