11:01 a.m.
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:
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.
11:22 a.m.
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...
On Tue, Jun 14, 2016 at 12:01 PM, 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:
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
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
9:17 a.m.
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(a)redhat.com]
Sent: Wednesday, June 15, 2016 10:37 PM
To: Wolinsky, Jared
Cc: undertow-dev(a)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(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
**********************************************************
MLB.com <http://mlb.com> - Where Baseball is Always On.
7:45 p.m.
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(a)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(a)redhat.com]
Sent: Wednesday, June 15, 2016 10:37 PM
To: Wolinsky, Jared
Cc: undertow-dev(a)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(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
**********************************************************
MLB.com <http://mlb.com> - Where Baseball is Always On.
7:48 p.m.
There is something similar here.
https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io...
Should they use the same Key or be kept separate?
On Thu, Jun 16, 2016 at 8:45 PM, Stuart Douglas <sdouglas(a)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(a)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(a)redhat.com]
> Sent: Wednesday, June 15, 2016 10:37 PM
> To: Wolinsky, Jared
> Cc: undertow-dev(a)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(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
>
>
>
> **********************************************************
>
> MLB.com <http://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
7:50 p.m.
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(a)dartalley.com> wrote:
There is something similar here.
https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io...
Should they use the same Key or be kept separate?
On Thu, Jun 16, 2016 at 8:45 PM, Stuart Douglas <sdouglas(a)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(a)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(a)redhat.com]
> > Sent: Wednesday, June 15, 2016 10:37 PM
> > To: Wolinsky, Jared
> > Cc: undertow-dev(a)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(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
> >
> >
> >
> > **********************************************************
> >
> > MLB.com <http://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
>
3110
days inactive
3113
days old
6 comments
3 participants
participants (3)
-
Bill O'Neil -
Stuart Douglas -
Wolinsky, Jared