9:37 p.m.
I think you are correct that we don't handle this case very well, the
basic error handing strategy has always been to just catch the error
in a handler, but when you don't have control over the dispatch site
this gets tricky.
We should definitely make the error available in
DefaultResponseListener, probably just as an attachment on the
exchange. Would this be enough to meet your requirements, or would
some kind of actual error handling interface be better?
DefaultResponseListener may not always be called if the exchange has
already been finished when the error occurs (i.e. the page has already
been sent to the user).
Stuart
On Wed, Jun 15, 2016 at 2:01 AM, Wolinsky, Jared <jared.wolinsky(a)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-thro....
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:
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.
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.
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 - Where Baseball is Always On.
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev