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

[Bill O'Neil]

There is something similar here.
https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/server/handlers/ExceptionHandler.java#L17

Should they use the same Key or be kept separate?

On Thu, Jun 16, 2016 at 8:45 PM, Stuart Douglas <sdouglas at redhat.com> wrote:

> I have added support for this, which will be available in Undertow
> 1.4.0 which should come out very shortly. The exception is will be
> stored under the io.undertow.server.DefaultResponseListener#EXCEPTION
> attachment key).
>
> Stuart
>
> On Fri, Jun 17, 2016 at 12:17 AM, Wolinsky, Jared
> <jared.wolinsky at mlb.com> wrote:
> > For me, adding the exception onto the exchange would be fine, along with
> a mention in the error handling section of the docs.  I think it's ok if
> the DefaultResponseListener isn't called if the exchange is ended because
> that is some handler explicitly taking care of the response and overriding
> the default case.  That said, I don't think an explicit error handling
> interface would be a bad way to go either.
> >
> > I was actually able to work around this using Bill O'Neil's advice and
> dispatching the request every time in my ErrorHandler, which is the outer
> handler in my chain.  Then I try-catch the next.handleRequest call, and do
> my exception handling there.
> >
> > Thanks,
> > Jared
> > ________________________________________
> > From: Stuart Douglas [sdouglas at redhat.com]
> > Sent: Wednesday, June 15, 2016 10:37 PM
> > To: Wolinsky, Jared
> > Cc: undertow-dev at lists.jboss.org
> > Subject: Re: [undertow-dev] How to handle exceptions thrown from worker
> threads
> >
> > 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 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:
> >>
> >> 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> >
> >
> > **********************************************************
> >
> > 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/20160616/81e86781/attachment.html