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

[Bill O'Neil]

To be honest I don't remember why I added that there. It doesn't make sense
to only add the attachment when the exception is handled and ignore it when
it is not.

On Thu, Jun 16, 2016 at 8:48 PM, Bill O'Neil <bill at dartalley.com> wrote:

> 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/2f22d23f/attachment-0001.html