Announcement Announcement Module
No announcement yet.
Accessing exception thrown by handler Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Accessing exception thrown by handler

    I'm using the RequestReplyTemplate.request() method to a blocking request/reply mode to an @Concurrency endpoint.

    How do I get RequestReplyTemplate to return a ErrorMessage in the case
    where the handler throws an exception?

    It's fine if i use instanceof to test the type of Message, but maybe better to catch an exception that tells me it was thrown by my endpoint service code.


  • #2
    If you want to have a blocking call and to catch the exception, the simplest approach would be to configure the 'requestChannel' as a <direct-channel/> and to avoid @Concurrency. The direct-channel allows the sender thread to invoke the endpoint directly. However, even then, by enabling concurrency the actual invocation of the endpoint's handler will occur on a different thread, and any Exceptions thrown on that thread have to be handled by the task wrapper's errorHandler (which sends Messages to the errorChannel by default). The sender will only block until the task is submitted to the scheduler and then is no longer associated with the execution of the handler.

    On the other hand, we could consider adding a different error strategy such that the ErrorMessage is sent to the 'returnAddress' instead of being sent to the errorChannel. This would only apply in cases that the original sender is waiting for the final response (error or not) - as in this case (if i understand correctly). The challenge here is that the endpoint does not know the intentions of the original sender (and indeed there may be different intentions for different senders). For example, in a "pipeline" scenario such as: [in -> endpoint -> next-endpoint], the "next-endpoint" would end up with an ErrorMessage invocation. So, the information needs to be set on the original request message (essentially at least a "returnErrorMessage" boolean - or perhaps a separate "errorReturnAddress").

    Does this make any sense?



    • #3
      Originally posted by Mark Fisher View Post
      .... we could consider adding a different error strategy such that the ErrorMessage is sent to the 'returnAddress' instead of being sent to the errorChannel...
      Does this make any sense?
      Yes this makes sense. I want the handler to execute from within a pool of threads. I'm experimenting with some isolation of tasks that make external service calls, and I'd like to manage those threads separately.
      So this option would be helpful.

      With the current release, could I check the error channel and locate the
      exception object in the case the response is null? A null response would
      be caused by a timeout or an error, right?



      • #4
        Does ConcurrencyInterceptor.aroundSend() just swallow the exception
        if the errorHandler() is not specified? How does the error get sent to the
        global error channel if I wanted to deal with it at that level?

        It would be good to enable error handling strategy so that we can
        make response message the ErrorMessage itself. That would make
        the RequestReplyTemplate.request() method more complete.

        Should I add a JIRA request?


        • #5
          Please do add a JIRA request for that.

          Thank you,


          • #6
            Thanks, Mark.

            By the way, I have been reading the source code. I'm learning a lot about
            asynchronous programming.
            Nice work.