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? StandardManager & > > WebappLoader? > > Yes, they add 2 threads per webapp. Which may limit the scalability with > the number of deployed webapps ( 100 contexts -> 200 threads ). > > >> should all go away and > >> be replaced by a single mechanism. Maybe the JMX timer ? > > > > I'd hate to think what would happen if someone stopped the timer > > service. Also, using the event-driven approach to trigger maintenance > > activities in foreground threads would be quirky coding, and may not > > even be appropriate in classes that don't always have executing code. > > 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 related with DOS > and security ), but it may be worth it. > A single thread checking for modified files is probably ok (although it will slow down the effective reload rate for individual apps), but I'd be particularly careful about trying to combine the session timeout processing of multiple webapps into one thread. The problem is that application-level event handlers are called from this thread, and you really don't want an accidentally or maliciously coded webapp to start sleeping in one of these event handlers and thereby disable session timeout service for the entire Tomcat JVM. It's possible that some way to time out the timeout event hander :-) could deal with this, but it will require some care. > 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-demand (via the manager webapp) is a much more effective strategy IMHO. And "reloadable" shouldn't be used on a production server anyway. Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
