1 of 1 people found this helpful
There is always a short moment where the requests are stopped.
A common way to solve that is to have a loadbalancer in front of the server(s). If you need to restart it you can stop routing requests to this one and redeploy it if there re no sessions left on this server.
This is a common problem. Even though you could somehow fix this in place for one container (maybe using some sort of forwarding and request blocking in Undertow while redeploying) this won't solve the problem if you want to keep the active sessions and your application changed what the session objects look like and can result in runtime problems after the upgrade. And same would apply to container upgrades.
The solution we propose, is to start up a new container with the new application deployed and drain sessions from the previous container and let new sessions use the new container. When no sessions are left using the previous container, shut it down and keep using the new instance. Project mod_cluster accommodates this use case.
Thanks guys. If fear that running a load balancer + the 3-4 JVMs required for Wildfly to do this, is going to be too memory heavy for most of my apps. I need to measure it to make sure, but last I checked JVM processes were not too good at sharing memory among themselves. I'm experimenting with Undertow (without Wildfly) ... maybe I can build something that handles the common case you mention (compatible sessions), within a single JVM.
is going to be too memory heavy for most of my apps.
Looks like that's the tradeoff app performance vs. stopping all sessions.
last I checked JVM processes were not too good at sharing memory among themselves
Still true, not going to change any time soon but I am not sure if saving few classes in memory would save the situation here anyway.
I'm experimenting with Undertow
Cool, go ahead. Check the git repository for some samples and the dev list.