|
Lenny Primak here I come again ![]() Did the testing with domain mode in WFLY, here is a breakdown of how WFLY works:
-
Domain has a master node (no surprise here) and then slaves
-
Slaves are organized in groups of servers, so you control a group and not a specific slave
-
Group can have one or more servers and this way you deploy/undeploy to all
-
You cannot have two WAR files with same name in domain
-
So yea, you need test.war and test1.war
-
But WFLY supports so called runtime deployment names which can and should be the same in this same
-
So as a result, both WARs (test.war and test1.war) will have their runtime name for instance rolling.war
-
I used no load balancer in this scenario as it wasn't necessary
Note: WARs were created with beanIdentifierIndexOptimization=false straight away
And as for the process and results:
-
Firstly I deployed the version 1.0 to all groups (had two)
-
Tested that it works in between these
-
Stopped one group of servers and replaced the war with new one having the app with version 1.1
-
Kept the session alive in the meantime
-
Bring the server group back up and access the app
-
Works like a charm, session got replicated and Weld had no problems here
-
Rinse and repeat with the other server group to have all server up to date...
I tried this with different runtime names just to make the testing complete. Obviously this scenario failed and it is probably what you are running into. So all in all this issue seems to be limited to application server which fail to provide support for runtime deployment names. So far we learned that this is a case of paraya/glassfish but I don't know about other servers.
|