Allistair Crossley wrote:
we used to just schedule updates and let all our staff know there would be a 
small amount of downtime (for our intranet) but you can't do this on external 
production servers, so you need to go with either load balancing/clustering 
that allows you to close a node down *while also* letting sessions complete 
(e.g BigIP I think may do this). we have a semi-solution using mod_jk's load 
balancing/sticky sessions. Although closing a node does not wait until sessions 
are complete, mod_jk still detects the failed node and passes over to the next 
node gracefully. it's a 1/2 way house to a full solution that you can implement 
right away. for graceful close down (i.e sessions completing) you need 
something like BigIP or a commercial application server like BEA which does 
this for you. I really wish support for hot deployment got sorted out in 
Tomcat/J2EE servers in general. Although I am a J2EE die-hard I used C# .NET 
recently for a project and it beats the hell out of J2EE deployment
, if we're not careful this will be a big win for .NET.


The hot deployment issues isn't a Tomcat issue, or a J2EE issue. It's a fundamental flaw in the JVM. There is just no way to explicitly destroy a classloader (the main cause of OOM exceptions when constantly redeploying apps). Until either we're able to just destroy a classloader, or have isolates/MVM available, we're stuck in this deployment mess.

I agree, .NET is way better for developing and deploying apps. And deployment couldn't get more simple that PHP (just copy them over). Why does it have to be so hard for Java?

Until Sun wakes up and realizes the JVM wasn't made to host multiple applications, and then fixes it, we're going to be stuck with the current state of things. For instance, having to run each webapp in a separate Tomcat just to minimize downtime for all apps is pretty crazy.

The clustering solution seems possible, except I'm worried about two different versions of a class ending up in the session (and this causing serialVersionUID issues).

Seth

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to