The problem here is how to report back to the caller that an error has occured, right?
Here's an idea I've been kicking around and am likely to implement (I'm a little familiar with the inner workings of the thread pool, but not very familiar, so take this with a grain of salt): 1. First, and most importantly, no Throwable should ever kill a thread pool. It may kill the Command that is running, but not the pool. If the pool gets some exception, it should simply log it. 2. In order to communicate between Command and calling process, I'm proposing new Task, TaskStatus, and TaskManager sets of code. 3. Task is a subinterface of Command with an additional method: public TasksStatus getStatus(). 4. TaskStatus is an interface that returns the current status of a Task, including returned value, perhaps some progress numbers, and any exception that was thrown. 5. TaskManager is a Component that adds Tasks to a CommandManager, returning the TaskStatus for that Task to its caller. Some implementations of TaskManager will throw away "duplicate" Tasks, returning the TaskStatus from the original. Whatcha think? James -----Original Message----- From: Peter Royal [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 30, 2002 7:55 AM To: Avalon Developers List Subject: Re: TPCThreadManager exceptions On Tuesday 28 May 2002 09:51 pm, Gregory Steuck wrote: > >>>>> "Peter" == Peter Royal <[EMAIL PROTECTED]> writes: > > Peter> On Tuesday 28 May 2002 07:34 pm, Gregory Steuck wrote: > >> toast. Thus, we should not continue banging on it and the only > >> thing TPCThreadManager.run can do is exit (possibly logging the > >> exception, this is not in the patch below). > > Peter> I think that should be the responsibility of the object > Peter> that is managing the TPCThreadManager. > > If understand you correctly, you suggest that the caller of > TPCThreadManager.run should log the exception? This may not be really > feasible: run() is called by that same thread pool that just aborted, > so it is presumably badly broken. Thoughts? (note to self, don't think hard about programming after beer + mexican food) May we just have to log a FATAL_ERROR and hope for the best? I haven't done a ton of thread-intentive programming, and thus I'm unsure of other possible alternatives. -pete -- peter royal -> [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
