[undertow-dev] How to handle exceptions thrown from worker threads

[Bill O'Neil]

I'm not sure if this is the recommended approach but I went with your
option 2 and it works well for me. Take a look at this PR for how I handled
it. https://github.com/undertow-io/undertow/pull/407

As Stuart mentioned you can used the WrappedHandler instead of my
implementation or create something similar to mine.

The caveat here is that I can only do this for handlers that I have control
> over, not built-in handlers that dispatch to worker threads such as the
> AuthenticationCallHandler.

As for this as long as you dispatch before AuthenticationCallHandler it
should not dispatch again. Any Handler that dispatches should first check
to see if the exchange has already been dispatched and short circuit if it
has. So this case should be covered.

see
https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/security/handlers/AuthenticationCallHandler.java#L45

On Tue, Jun 14, 2016 at 12:01 PM, Wolinsky, Jared <jared.wolinsky at mlb.com>
wrote:

> Good morning,
>
> We're using Undertow in a new web service at MLB, and I haven't been able
> to find a solution for handling errors that occur in requests that have
> been dispatched to worker threads.  Here is a link to my SO question:
> http://stackoverflow.com/questions/37753726/how-to-handle-exceptions-thrown-from-undertow-worker-threads.
> Ignoring worker threads, my model for error handling is to have an outer
> handler that maintains a map of exception type -> {log level, http status
> code}.  Then I allow exceptions to propagate out from the actual API
> handlers, hitting the error handler which logs the error and responds to
> the client with the correct status code based on the exception type.  When
> exceptions are thrown from worker threads, however, they break out of the
> normal handler chain and never hit the error handler, resulting in a 500
> response every time.  Here are options I've considered for handling this
> problem:
>
>
>    1. Inside my error handler, set a DefaultResponseListener (
>    https://http2.undertow.io/documentation/core/error-handling.html) on
>    the exchange that contains my error handling logic.  I hit a wall here
>    after realizing the listener only has access to the Exchange, not to the
>    exception that will be thrown.
>    2. Set an UncaughtExceptionHandler on each handler that's on a worker
>    thread.  This code would be added to my base handler class, do a
>    *!exchange.isInIoThread()* check, set the error handler, then call the
>    handleRequest method.  The caveat here is that I can only do this for
>    handlers that I have control over, not built-in handlers that dispatch to
>    worker threads such as the AuthenticationCallHandler.
>    3. Use an AspectJ-based approach where I create an @Around advice that
>    executes for all of my handlers that will wrap the execution in a
>    try-catch, and take care of the error handling.
>
>
> Are there best practices for handling this?
>
>
> Thanks,
>
> Jared Wolinsky
>
> Senior Software Engineer, MLB Advanced Media
>
>
> **********************************************************
>
> MLB.com <http://mlb.com> - Where Baseball is Always On.
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160614/17a2085c/attachment.html