On Thursday 23 May 2002 06:06 pm, Berin Loritsch wrote:
> Ok. If you, could, can you send in the patch for the error
> trapping code?
I'll check out the patch that Gregory put in bugzilla in the morning. My
error trap is a very simple
catch( Exception e)
{
e.printStackTrace();
}
:)
>From a quick glance at Gregory's patch, his fix is very similar to mine
(albiet with a bit more thought :) ... the only downside I see is that if the
first pipeline in the list takes more time to run that the pool blocking time
+ the execution frequency, it can effectively block other pipelines from
running.
> The issues are surrounding the use of the ThreadManager. We
> need the ThreadPool to block, and unfortunately it doesn't.
> It thows an exception instead.
The ThreadPool has a configurable timeout, setting that to something larger
might be the answer
> BTW, There are two thread managers: TPC and TPSP. The TPSP
> is not implemented (it mirrors an old TPC). I just never
> got around to implementing it.
I noticed, and thus went with the TPC because it worked :)
> A while back I noticed an issue with the ThreadPool that caused
> it to disregard the limits and just create more threads. I
> think that part was fixed, but the blocking part is not....
I think so, since it tried to block.
> That's a good question. Too many parameters on the constructor,
> and too many constructors make it hard to use.
>
> My initial thoughts on it were that I wanted to make the whole
> of the Event package to be able to be used independantly of
> Framework. I then relented on the Command portion, but I wanted
> a really simple "instantiate and go" type of setup.
>
> What are your feelings on this. What is easiest for you?
I also see no specific need for a Framework dependency. How about something
like:
TPCThreadManager tpc = new TPCThreadManager();
tpc.enableLogger( getLogger() );
tpc.setNumProcessors( 1 );
tpc.setThreadsPerProcessor( 1 );
tpc.setSleepTime( 1000 );
tpc.setPoolTimeout( 1000 * 2 );
tpc.start(); //or execute/init/whatever
Basically taking each constructor arg and turning it into a specific property
that can be set. If a property is not set before starting the manager, the
default is used. Sleep time could then be easily changed on the fly, if
needed.
You still get the "instantiate and go" that you desire --- there's only one
extra method call involved from using the arg-less constructor that is has
now.
-pete
--
peter royal -> [EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
