Announcement Announcement Module
Collapse
No announcement yet.
Stuck on how to handle my exceptions Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Yes, you are right, this is JMS issue and we need handle of calling thread and or Exception handling mechanish at the begining of the flow. This way we can handle exceptions and account for the messages.
    I believe we now have this handled with the new error-channel attribute on the JMS inbound gateway and channel adapter (INT-1623, INT-1624, INT-1626).

    If a downstream synchronous exception is thrown and an error channel is specified, we will put a Message on the error-channel, where the payload is a MessageHandlingException (containing the cause as well as the failed message).

    If the endpoint is a gateway, the result of the error flow will be sent as a response. If the error flow itself fails, the JMS transaction will be rolled back.

    We are also adding this functionality to other inbound endpoints, where it makes sense - ip endpoints, event:inbound-channel-adapter, etc.

    Comment


    • #32
      Thank you. I am actually following this thread and waiting for this functionality.
      --sri
      Originally posted by Gary Russell View Post
      I believe we now have this handled with the new error-channel attribute on the JMS inbound gateway and channel adapter (INT-1623, INT-1624, INT-1626).

      If a downstream synchronous exception is thrown and an error channel is specified, we will put a Message on the error-channel, where the payload is a MessageHandlingException (containing the cause as well as the failed message).

      If the endpoint is a gateway, the result of the error flow will be sent as a response. If the error flow itself fails, the JMS transaction will be rolled back.

      We are also adding this functionality to other inbound endpoints, where it makes sense - ip endpoints, event:inbound-channel-adapter, etc.

      Comment


      • #33
        If you are comfortable with using nightly builds; the JMS changes made it into last night's build.

        Change your poms to 2.0.0.BUILD-SNAPSHOT for spring-integration-* dependencies.

        Comment


        • #34
          I can do this before end of this week.
          Thanks again
          --sri
          Originally posted by Gary Russell View Post
          If you are comfortable with using nightly builds; the JMS changes made it into last night's build.

          Change your poms to 2.0.0.BUILD-SNAPSHOT for spring-integration-* dependencies.

          Comment


          • #35
            is this possible using int-jms:channel

            I know I've come to the party late but I'm trying to do the same thing as plecesne but using <int-jms:channel /> as the starting point of my transaction instead of an inbound-channel-adapter or gateway. As far as I can see this isn't available yet for a jms:channel which has an option for an error-handler but not error-channel? Gary is it possible this could be added in a future version? Or have I missed something?

            Thanks for the excellent work here!

            Originally posted by Gary Russell View Post
            I believe we now have this handled with the new error-channel attribute on the JMS inbound gateway and channel adapter (INT-1623, INT-1624, INT-1626).

            If a downstream synchronous exception is thrown and an error channel is specified, we will put a Message on the error-channel, where the payload is a MessageHandlingException (containing the cause as well as the failed message).

            If the endpoint is a gateway, the result of the error flow will be sent as a response. If the error flow itself fails, the JMS transaction will be rolled back.

            We are also adding this functionality to other inbound endpoints, where it makes sense - ip endpoints, event:inbound-channel-adapter, etc.

            Comment


            • #36
              In the future, it's probably best to start a new thread (and perhaps reference the old one) rather than reviving one that's so old.

              To your question -

              It just doesn't seem "right", to us, to have an error-channel on a channel. Even though the JMS-backed channel is a little more complex than most, we still like to think of all channels as being lightweight glue that simply binds more complex components together.

              We do, however, provide a MessagePublishingErrorHandler that can be configured with an errorChannel and provided to the jms-backed channel in the error-handler attribute.

              It might seem like semantics, but maybe not so much if you consider that the namespace is simply a convenience to avoid you having to configure an external listener container (which is where the errorHandler is applied).


              I don't want to speculate on your application but I would like to point out to other readers that jms-backed channels are intended for persistence in the event of a server failure; it is an anti-pattern to use them for distributing work across JVMs; it's better to use adapters for that. (Not that your description implies you are doing that).

              Comment


              • #37
                Actually, before my next real question, I want must if your comment I made about Exceptions being "thrown back" makes sense? I'm sure you're just seeing the rollback behavior, correct? Otherwise, I want to know very well what you meant by "thrown back".

                Comment

                Working...
                X