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 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. I know - executing the even handlers can't be done on the expiration thread. The problem I'm trying to solve is scaling tomcat with the number of webapps. ( well, I'm not actually coding anything right now - there are more important issues :-) A hosting site with 100s of apps ( some very infrequently used !) would benefit a lot from having a single thread doing the checks for expiration. A thread pool can be used to process the event handlers - with some safeguards to prevent DOS ( event handlers hunging the expiration thread). It's not very difficult - let the thread pool grow to the max number of apps, and make sure a each context gets at most one thread for events. If all apps behave, you'll have few threads doing the expiration and one doing the check. Regarding the delay - yes, it may be faster to have 100 threads doing nothing but expiration ( or modification ) check, one per context. However it may be better to have 100 threads doing request processing and keep a single thread doing session maintainance. Java GC is done in a single thread too. Anyway - I don't think this is a very urgent problem to solve. >> 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. I agree. Is 'reloadabl' disabled by default ? Should we deprecate it ? BTW - another way to do reload-on-demand is using JMX ( the html interface provided by either jmx-ri or mx4j - or any other jmx adaptor ). It may be a good idea to make the manager webapp more powerfull - i.e. support generic ( simple ) get/set operations via JMX. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
