Re: [PATCH] Re: ThreadPool

Remy Maucherat wrote: > BTW, can't Linux 2.5/2.6 handle thousands of threads without any problem > ? I remember reading an iterview of Ingo who said JVM performance and > thread handling should be way better in 2.6. > The idea is that there's nothing wrong with designing with threads in > mind (I

Re: [PATCH] Re: ThreadPool

> BTW, can't Linux 2.5/2.6 handle thousands of threads without any problem > ? I remember reading an iterview of Ingo who said JVM performance and > thread handling should be way better in 2.6. You're right, and Java should be one to benefit well from it. But if the kernel period freeze lasts as

Re: [PATCH] Re: ThreadPool

On Mon, 30 Dec 2002, Costin Manolache wrote: > Date: Mon, 30 Dec 2002 13:02:09 -0800 > From: Costin Manolache <[EMAIL PROTECTED]> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [PATCH] Re: ThreadPool > > Craig R.

Re: [PATCH] Re: ThreadPool

Costin Manolache wrote: Craig R. McClanahan wrote: I like using the custom Ant tasks included with Tomcat 4.1 for manipulation via manager, so that I can create a "reload" target. If you don't use Ant, it's just as easy to leave a browser window open to: I don't know if you looked at the J

Re: [PATCH] Re: ThreadPool

Craig R. McClanahan wrote: On Mon, 30 Dec 2002, Costin Manolache wrote: I agree. Is 'reloadabl' disabled by default ? Yes ... at least in HEAD of 4.1 and 5.0. I'm pretty sure it's always been that way. Yes, it's disabled by default. BTW, can't Linux 2.5/2.6 handle thousands of threads w

Re: [PATCH] Re: ThreadPool

Craig R. McClanahan wrote: > I like using the custom Ant tasks included with Tomcat 4.1 for > manipulation via manager, so that I can create a "reload" target. If you > don't use Ant, it's just as easy to leave a browser window open to: I don't know if you looked at the JMX ant tasks in modeler

Re: [PATCH] Re: ThreadPool

On Mon, 30 Dec 2002, Costin Manolache wrote: > > >> As for someone stoping the check for class modification at run time using > >> an admin interface - what's wrong with that ? > > > > I don't see a problem with that, but I've stopped using "reloadable" at > > all for my development -- reload-on

Re: [PATCH] Re: ThreadPool

Craig R. McClanahan wrote: >> It would actually be a pretty good solution IMO. A single thread checking >> the files for modification in all contexts is better ( again IMO ) than >> one thread per context. Same for checking sessions. >> >> The coding is a bit trickier ( and there are some issues

Re: [PATCH] Re: ThreadPool

On Mon, 30 Dec 2002, Joseph Shraibman wrote: > Date: Mon, 30 Dec 2002 14:00:57 -0500 > From: Joseph Shraibman <[EMAIL PROTECTED]> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]> > To: Tomcat Developers List <[EMAIL PROTECTED]> > Subject: Re: [PATCH] Re: T

Re: [PATCH] Re: ThreadPool

Craig R. McClanahan wrote: I don't see a problem with that, but I've stopped using "reloadable" at all for my development -- reload-on-demand (via the manager webapp) is a much more effective strategy IMHO. And "reloadable" shouldn't be used on a production server anyway. Is there a way to

Re: [PATCH] Re: ThreadPool

On Sun, 29 Dec 2002, Costin Manolache wrote: > > Michael wrote: > > > Costin Manolache wrote: [snips] > >> IMO MonitorRunnable, the session expiration thread ( one per ctx ) > >> and the reloading thread ( one per ctx again ) > > > > What classes are you referring to specifically? StandardMa

Re: [PATCH] Re: ThreadPool

Michael wrote: > Costin Manolache wrote: > >> You're probably right that addThread() doesn't need to be public - but >> I don't think it hurts too much either. > > It does when you're trying to refactor a class. It forces you to ask > whether the interface really is used, or can you rearrange

Re: [PATCH] Re: ThreadPool

- Original Message - From: "Remy Maucherat" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Saturday, December 28, 2002 12:40 AM Subject: Re: [PATCH] Re: ThreadPool > Michael wrote: > > Costin Manolache wrote: >

Re: [PATCH] Re: ThreadPool

Remy Maucherat wrote: Although refactoring the monitor timer code is relatively safe, the thread pool as a whole is a critical piece of code in Tomcat 4.1.x (= you should test things extensively after making a change). Since your patch doesn't build, I'll have to assume you didn't try to *ru

Re: [PATCH] Re: ThreadPool

Remy Maucherat wrote: Also: MonitorRunnable, now that it has a start() method (for JMX, I presume) has no restriction on running more than one thread. This undercuts the meaning of "interval", and makes stop() poorly defined. I would like it if this was fixing any issue the above (which ha

Re: [PATCH] Re: ThreadPool

Michael wrote: Umm...that last patch won't compile, I forgot to remove a line. Knew I was forgetting to do something. :-[ Although refactoring the monitor timer code is relatively safe, the thread pool as a whole is a critical piece of code in Tomcat 4.1.x (= you should test things extensively

Re: [PATCH] Re: ThreadPool

Michael wrote: Costin Manolache wrote: You're probably right that addThread() doesn't need to be public - but I don't think it hurts too much either. It does when you're trying to refactor a class. It forces you to ask whether the interface really is used, or can you rearrange like you want

Re: [PATCH] Re: ThreadPool

Umm...that last patch won't compile, I forgot to remove a line. Knew I was forgetting to do something. :-[ -- To unsubscribe, e-mail: For additional commands, e-mail:

[PATCH] Re: ThreadPool

Costin Manolache wrote: You're probably right that addThread() doesn't need to be public - but I don't think it hurts too much either. It does when you're trying to refactor a class. It forces you to ask whether the interface really is used, or can you rearrange like you want to. Usually I g