When using `mod_jk` with a load balancer and the sticky session flag to create a farming architecture, distributed applications would fail to deploy because clustering was not enabled. This was because without clustering configuration the `LOCAL_ADDRESS` of the `RegistryService` was initialised to a default value which was not serializable. This non-serializable `LOCAL_ADDRESS` prevented successful deployment in this scenario. Now `LOCAL_ADDRESS` is initialised to a serializable value and deployment of distributable applications works as expected in this scenario.
Description of problem:
Adding a "jvmRoute" in standalone.xml profile produces errors in <distributable /> applications.
Version-Release number of selected component (if applicable):
JBoss EAP 6.1.0.GA (AS 7.2.0.Final-redhat-8)
How reproducible:
Add a "jvmRoute" property in standalone.xml and deploy a <distributable /> application.
Steps to Reproduce:
1. Unzip EAP 6.1.
2. Add a "jvmRoute" system property with value "test".
3. Deploy attachment application.
Actual results:
10:48:27,861 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (ServerService Thread Pool -- 52) ISPN000136: Execution error: org.infinispan.marshall.NotSerializableException: org.jboss.as.clustering.registry.RegistryService$1
Caused by: an exception which occurred:
Expected results:
Application deployed without errors.
Additional info:
This scenario can be valid:
- Customer wants a farming architecture, where a mod_jk is used to load balance request but not clustering needed.
- Customer can have a third party application with <distributable /> in their web.xml.
- A possible workaround can be to remove <distributable /> but ideal fix should be that if jvmRoute is present EAP 6.1 should detect if infinispan is configure in distributable/clustering instead of local.
Comment 10Emmanuel Hugonnet (ehsavoie)
2013-12-02 07:22:15 UTC
There should be no change in behaviour (except the missing exception).
The fix was :
The LOCAL_ADDRESS of the RegistryService which is serialized to be shared in the cluster was initialized to its default value because of the missing clustering configuration. This default initialisation was not serializable which provoked this exception.
Thus initialising the LOCAL_ADDRESS with a default value serializable fixed the issue.