On 22/10/2010 14:15, Leon Rosenberg wrote: > Well the primary resource I see as a problem is heap. I have one > customer who runs his tomcats with 12gb heap and another with 8. Both > do that on 16 gb machines. They couldn't increase without resizing the > machines. > The heap is really used and not for session related content but for > global caching etc.
Yep, that would be an issue if most of an app's heap usage was for cache. In that case multiple machines is probably a better option and one that gets better as you have more machines since you could roll the new version out across the machines one at a time. You'd need to be careful to time the upgrades so they roughly tracked the pace of users migrating between versions. You'd also need to be careful with clustering / load-balancing config but it is all do-able. > Ok, I have experience with some very heavy start applications - > basically they produce 100% cpu load for 1-2 minutes, this can > decrease the performance of other requests, > but this is surely not a common rule for all applications. Agreed, not a common case but one that can be handled with either approach. > I found many operations-manager to be extremely resistant against > "fancy-java-features" and having a > "we-can-do-it-better-with-vi"-attitude :-) I certainly see a preference for being able to script as much as possible, rather than use GUI tools. This feature would be optional - no-one is going to be forced to use it. I was speaking at a conference this week and mentioned this at the end of my Tomcat 7 intro presentation when I was talking about future plans. General consensus in the room was that they liked the feature and would use it. That was a mix of developers and ops folks so I think there is a demand In the same way users aren't forced to do hot re-deployment but can do it if they want, parallel deployment will add another choice. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
