7 Replies Latest reply on Jun 23, 2006 4:44 PM by scottdawson

    TreeCache and portal clustering conflict

    lizmstanley

      This is not so much a question as pointing out something - perhaps others have noticed this as well. I am using JBoss 4.0.4.CR2 and Portal 2.4.0-BETA1.

      I built the portal from source with the clustering option set to true. However, when deploying jboss-portal.sar, I kept getting the "discarded message from different group" warning. I used a socket monitor and saw that the problem was caused by udp group 224.0.0.36 and port 55566, but I couldn't figure out where it was coming from since I had nothing configured with that address/port.

      Finally I found in the source that these are in the default properties for TreeCache (org.jboss.cache.TreeCache.getDefaultProperties()). When the cluster attributes are not set through configuration, these hardcoded values are returned by default. There were two cases in the portal where nothing was specified, so the default was used, resulting the conflict I saw.

      I was able to configure one of them - the TreeCache service for hibernate in jboss-portal.sar/META-INF/jboss-service.xml. I simply added a ClusterConfig attribute to the mbean and set a different mcast_addr and mcast_port.

      The other case isn't so straightforward. It's the mbean for CMSTreeCache defined in jboss-portal.sar/portal-cms.sar/META-INF/jboss-service.xml. Unfortunately, the code for this mbean, org.jboss.portal.cms.impl.cache.CMSTreeCacheServiceImpl, encapsulates an instance of TreeCache. In the startService() method of CMSTreeCacheServiceImpl, a TreeCache object is simply instantiated using the default constructor. Because of that, the cluster_props of the TreeCache object remain null, and those hardcoded defaults will always be used for this service - there is no way to configure it in the xml.

      Now that I'm aware of this, I can work around it. However, it seems that we should not have to use the defaults as there is always the potential for this type of conflict. There is another constructor for TreeCache that takes cluster properties as a parameter. Perhaps this constructor could be used when starting the service so the user can pass in an alternate cluster configuration.