Re: [5.0] JARs handling, and other 5.0.3 changes
Shapira, Yoav wrote: Hi, All that as part of an effort to reduce Tomcat memory footprint (to make it more suitable for large scale deployments), I'm just curious how the two go together? Wouldn't large-scale deployments care less if tomcat's memory footprint was larger? It's typically the small (micro, on chips, PDAs, etc.) scale deployments that care more about memory footprint, no? I support both goals (memory footprint reduction and making tomcat better for large scale deployments), just curious about the above. > BTW -- I've emailed [EMAIL PROTECTED] with the results of my committer vote for commons-modeler. Hopefully that'll get put through soon and I can push a commons-modeler-1.1 release. I should have defined "large scale" a little bit more precisely. I was talking about web hosting here. For example, let's say you want to deploy 1000 webapps on a server. Right now, the caching policy for classes (and other memory wasting stuff) caused a lot of useless allocation. It could be as much as 1MB / webapp. So, in that example, we're looking at 1 gig of ram wasted. Of course, the stuff may be swapped out and never reused, but we need to optimize it IMO. With TC 4.1.x, in addition to the RAM, it was also 1000 background threads. To detail what I'd like to improve for who: - developer: make app reloading better and more efficient (I'll do all I can to get rid of JAR locking) - "normal" production user: IMO TC 4.1.x is good enough - high end production user: scalability improvements (less GC = better SMP scaling) and optimizations - web hosting: lots of webapps and hosts, so some additional improvements are required to make Tomcat really good at that Thanks a lot for your efforts on the modeler :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] JARs handling, and other 5.0.3 changes
Hi, >All that as part of an effort to reduce Tomcat memory footprint (to make >it more suitable for large scale deployments), I'm just curious how the two go together? Wouldn't large-scale deployments care less if tomcat's memory footprint was larger? It's typically the small (micro, on chips, PDAs, etc.) scale deployments that care more about memory footprint, no? I support both goals (memory footprint reduction and making tomcat better for large scale deployments), just curious about the above. BTW -- I've emailed [EMAIL PROTECTED] with the results of my committer vote for commons-modeler. Hopefully that'll get put through soon and I can push a commons-modeler-1.1 release. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] JARs handling, and other 5.0.3 changes
Hi, I plan to try to get rid (as much as I can) of JAR URLs inside the Catalina (and Jasper) processing, because of the issues which (still, unfortunately :-( ) plague them in the JDK. I will use the fact that all the JAR URLs returned by the classloader are actually file based. I hope that way I'll be able to get rid of the file locking issues on Windows. Similarly: - the servlet context will be modified to return file URLs for JARs (but only for JARs) inside /WEB-INF/lib in response to getResource. - /WEB-INF/classes/** and /WEB-INF/lib/** will be made non cacheable (as caching classes is useless by definition). All that as part of an effort to reduce Tomcat memory footprint (to make it more suitable for large scale deployments), and reduce the amount of heavyweight objects used (such as file descriptors and threads, the latter having been taken care of). For all those who are at J1, have a good J1 :) Remy Note: My deployer tweaks are almost done (without much testing), with the exception of moving the context descriptors to conf (thanks to Glenn for that idea, which will make the feature safer to use in TC 5). Note 2: I intend to try to resurrect the "tester" suite when that is done. Note 3: I plan to fix bug 4690 (finally). I have the algorithm on a piece of paper (as I didn't like the provided patch behavior). Note 4: When all that is done, it'll be time for 5.0.3 IMO. As far as I am concerned, it will be mostly feature complete. Given the amount of stuff I still have to do, I'd give it a two weeks ETA. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
