Accessing exception thrown by handler

[moores]

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.

thanks,
--Michael

[Mark Fisher]

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?

-Mark

[moores]

.... 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?
-Mark

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?

--Michael

[moores]

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?

[Mark Fisher]

Please do add a JIRA request for that.

Thank you,
Mark

[moores]

Thanks, Mark.

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