I have noticed that each Jboss AS 7 manage it self its mod_cluster configuration (avalable context). In the case the app server crash its coresponding JVM route is still present on mod_cluster side.
As the target environment is the cloud I can't assume that the replacing server will use the same ip.
How to clean up the mod_cluter config to prevent it to time to time to go the missing app server adding some extra dealy. In presious Jboss as there was a HASingelton managing all AS mod_cluster comunication, it is avalable in Jboss AS 7? It is a way to get some custom monitoring service clearing the dead instance?
what is the actual problem? The crashed node and its contexts will be removed in about a minute after the crash. Your new node will register with new route thus will not interfere with already crashed node.
Is REMOVE_APP callable from the mod_cluster-manager handler?
AFAIR yes, try the CLI interface.
In presious Jboss as there was a HASingelton managing all AS mod_cluster comunication, it is avalable in Jboss AS 7?
There is not much real-life benefit in mod_cluster usage of HASingleton service, thus it was removed.
Rado thanks for the reply.
I run Jboss in state less instances, when an instance crash or is removed it is removed form the vlan before the termination signal is send to JBoss process, so it can't interact with mod_cluster.
In my experience, the crashed or removed jvmroute stays on the mod_cluster-manager page is faild status. Time to time it is back to ok status (until it detect it is down). So I fear that some request try to get to the not any more existing jvmroute adding a small delay.
Over time the config on mod_cluster side will be full of not avalable jvmroute.
We already have environment change even processing, so using mod_cluster-management to update the state when the even occure will look cleaner.
When I have some time, I will retest it and provide you the mod_cluster-management details.