Handling Exceptions in ThreadPoolExecutor
|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
 |
Handling Exceptions in ThreadPoolExecutor
by Norman Elton
::
Rate this Message:
I've got a ThreadPoolExecutor that overrides beforeExecute &
afterExecute. After a job is run, my executor checks to see if an exception was raised. If so, the database transaction is rolled back and the job is re-queued to run again. If it fails three times, it is discarded. Problem is... if an exception reaches afterExecute, the thread dies! This incurs some overhead and "thread churn" that I'd like to avoid. Is it possible setup a ThreadPoolExecutor to allow the thread to continue to live after an exception has been caught? Or some other way to re-queue failed jobs? Thanks, Norman _______________________________________________ Concurrency-interest mailing list Concurrency-interest@... http://cs.oswego.edu/mailman/listinfo/concurrency-interest |
|
|
Re: Handling Exceptions in ThreadPoolExecutor
by Martin Buchholz-3
::
Rate this Message:
TPE threads are not designed to recover from failing tasks.
But the TPE pool itself is (by spawning new threads). afterExecute can be used for logging/monitoring, but should probably not be used for execution control. Another way is to wrap all tasks so that they simply do not throw, perhaps on tasks submission, as ScheduledThreadPoolExecutor does. Martin On Wed, Aug 19, 2009 at 14:38, Norman Elton <normelton@...> wrote: I've got a ThreadPoolExecutor that overrides beforeExecute & _______________________________________________ Concurrency-interest mailing list Concurrency-interest@... http://cs.oswego.edu/mailman/listinfo/concurrency-interest |
|
|
Re: Handling Exceptions in ThreadPoolExecutor
by alarmnummer
::
Rate this Message:
I would also go for the wrapping solution.
When you are using some sort of transaction management aspect, it is normal that the transaction is aborted when an exception is thrown: So something like this: Transaction t = connection.startTransaction(); boolean success = false; try{ ..do logic success = true; }finally{ if(success){ t.commit(); }else{ t.abort(); } } On Thu, Aug 20, 2009 at 12:09 AM, Martin Buchholz<martinrb@...> wrote: > TPE threads are not designed to recover from failing tasks. > But the TPE pool itself is (by spawning new threads). > afterExecute can be used for logging/monitoring, > but should probably not be used for execution control. > > Another way is to wrap all tasks so that they simply > do not throw, perhaps on tasks submission, > as ScheduledThreadPoolExecutor does. > > Martin > > On Wed, Aug 19, 2009 at 14:38, Norman Elton <normelton@...> wrote: >> >> I've got a ThreadPoolExecutor that overrides beforeExecute & >> afterExecute. After a job is run, my executor checks to see if an >> exception was raised. If so, the database transaction is rolled back >> and the job is re-queued to run again. If it fails three times, it is >> discarded. >> >> Problem is... if an exception reaches afterExecute, the thread dies! >> This incurs some overhead and "thread churn" that I'd like to avoid. >> >> Is it possible setup a ThreadPoolExecutor to allow the thread to >> continue to live after an exception has been caught? Or some other way >> to re-queue failed jobs? >> >> Thanks, >> >> Norman >> _______________________________________________ >> Concurrency-interest mailing list >> Concurrency-interest@... >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest@... > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > Concurrency-interest mailing list Concurrency-interest@... http://cs.oswego.edu/mailman/listinfo/concurrency-interest |
|
|
Re: Handling Exceptions in ThreadPoolExecutor
by alarmnummer
::
Rate this Message:
Another big advantage of doing the commit/abort directly, is they you
are less dependant on the Executor implementation. On Thu, Aug 20, 2009 at 9:57 AM, Peter Veentjer<alarmnummer@...> wrote: > I would also go for the wrapping solution. > > When you are using some sort of transaction management aspect, it is > normal that the transaction is aborted when an exception is thrown: > > So something like this: > > Transaction t = connection.startTransaction(); > boolean success = false; > try{ > ..do logic > success = true; > }finally{ > if(success){ > t.commit(); > }else{ > t.abort(); > } > } > > On Thu, Aug 20, 2009 at 12:09 AM, Martin Buchholz<martinrb@...> wrote: >> TPE threads are not designed to recover from failing tasks. >> But the TPE pool itself is (by spawning new threads). >> afterExecute can be used for logging/monitoring, >> but should probably not be used for execution control. >> >> Another way is to wrap all tasks so that they simply >> do not throw, perhaps on tasks submission, >> as ScheduledThreadPoolExecutor does. >> >> Martin >> >> On Wed, Aug 19, 2009 at 14:38, Norman Elton <normelton@...> wrote: >>> >>> I've got a ThreadPoolExecutor that overrides beforeExecute & >>> afterExecute. After a job is run, my executor checks to see if an >>> exception was raised. If so, the database transaction is rolled back >>> and the job is re-queued to run again. If it fails three times, it is >>> discarded. >>> >>> Problem is... if an exception reaches afterExecute, the thread dies! >>> This incurs some overhead and "thread churn" that I'd like to avoid. >>> >>> Is it possible setup a ThreadPoolExecutor to allow the thread to >>> continue to live after an exception has been caught? Or some other way >>> to re-queue failed jobs? >>> >>> Thanks, >>> >>> Norman >>> _______________________________________________ >>> Concurrency-interest mailing list >>> Concurrency-interest@... >>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest >> >> >> _______________________________________________ >> Concurrency-interest mailing list >> Concurrency-interest@... >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest >> >> > _______________________________________________ Concurrency-interest mailing list Concurrency-interest@... http://cs.oswego.edu/mailman/listinfo/concurrency-interest |
| Free embeddable forum powered by Nabble | Forum Help |
