Unable to use another partition name other than DefaultParti

[monocongo]

I am attempting to run a cluster using a non-default partition name. In every *.xml file which originally had "DefaultPartition" I replaced it with "DevPartition". The jboss-service.xml which is included in the SAR being deployed in the deploy-hasingleton directory is also using "DevPartition" as the partition name.


JBOSS_HOME/server/all/deploy/cluster-service.xml:

<?xml version="1.0" encoding="UTF-8"?>

<!-- ===================================================================== -->
<!-- -->
<!-- Sample Clustering Service Configuration -->
<!-- -->
<!-- ===================================================================== -->

<!-- NOTE - Using DevPartition instead of DefaultPartition -->

<server>

 <classpath codebase="lib" archives="jbossha.jar"/>

 <!-- ==================================================================== -->
 <!-- Cluster Partition: defines cluster -->
 <!-- ==================================================================== -->

 <mbean code="org.jboss.ha.framework.server.ClusterPartition"
 name="jboss:service=DevPartition">

 <!-- Name of the partition being built -->
 <attribute name="PartitionName">DevPartition</attribute>
 <!-- The address used to determine the node name -->
 <attribute name="NodeAddress">${jboss.bind.address}</attribute>
 <!-- Determine if deadlock detection is enabled -->
 <attribute name="DeadlockDetection">False</attribute>

 <!-- Time in milliseconds to wait for state to be transferred -->
 <attribute name="StateTransferTimeout">60000</attribute>

 <!-- The JGroups protocol configuration -->
 <attribute name="PartitionConfig">
 <Config>
 <!-- UDP: if you have a multihomed machine,
 set the bind_addr attribute to the appropriate NIC IP address -->
 <!-- like this: -->
 <!-- bind_addr="10.10.10.78" -->
 <!-- UDP: On Windows machines, because of the media sense feature
 being broken with multicast (even after disabling media sense)
 set the loopback attribute to true -->
 <UDP mcast_addr="228.1.2.3" mcast_port="45566"
 ip_ttl="32" ip_mcast="true"
 mcast_send_buf_size="800000" mcast_recv_buf_size="150000"
 ucast_send_buf_size="800000" ucast_recv_buf_size="150000"
 loopback="true" />
 <PING timeout="2000" num_initial_members="3"
 up_thread="true" down_thread="true" />
 <MERGE2 min_interval="10000" max_interval="20000" />
 <FD shun="true" up_thread="true" down_thread="true"
 timeout="2500" max_tries="5" />
 <VERIFY_SUSPECT timeout="3000" num_msgs="3"
 up_thread="true" down_thread="true" />
 <pbcast.NAKACK gc_lag="50" retransmit_timeout="300,600,1200,2400,4800"
 max_xmit_size="8192"
 up_thread="true" down_thread="true" />
 <UNICAST timeout="300,600,1200,2400,4800" window_size="100" min_threshold="10"
 down_thread="true" />
 <pbcast.STABLE desired_avg_gossip="20000"
 up_thread="true" down_thread="true" />
 <FRAG frag_size="8192"
 down_thread="true" up_thread="true" />
 <pbcast.GMS join_timeout="5000" join_retry_timeout="2000"
 shun="true" print_local_addr="true" />
 <pbcast.STATE_TRANSFER up_thread="true" down_thread="true" />
 </Config>
 </attribute>

 </mbean>

 <!-- ==================================================================== -->
 <!-- HA Session State Service for SFSB -->
 <!-- ==================================================================== -->

 <mbean code="org.jboss.ha.hasessionstate.server.HASessionStateService"
 name="jboss:service=HASessionState">
 <depends>jboss:service=DevPartition</depends>
 <!-- Name of the partition to which the service is linked -->
 <attribute name="PartitionName">DevPartition</attribute>
 <!-- JNDI name under which the service is bound -->
 <attribute name="JndiName">/HASessionState/Default</attribute>
 <!-- Max delay before cleaning unreclaimed state.
 Defaults to 30*60*1000 => 30 minutes -->
 <attribute name="BeanCleaningDelay">0</attribute>
 </mbean>

 <!-- ==================================================================== -->
 <!-- HA JNDI -->
 <!-- ==================================================================== -->

 <mbean code="org.jboss.ha.jndi.HANamingService"
 name="jboss:service=HAJNDI">
 <depends>jboss:service=DevPartition</depends>
 <!-- Name of the partition to which the service is linked -->
 <attribute name="PartitionName">DevPartition</attribute>
 <!-- bind address of HA JNDI RMI endpoint -->
 <attribute name="BindAddress">${jboss.bind.address}</attribute>
 <!-- RmiPort to be used by the HA-JNDI service
 once bound. 0 => auto. -->
 <attribute name="RmiPort">0</attribute>
 <!-- Port on which the HA-JNDI stub is made available -->
 <attribute name="Port">1100</attribute>
 <!-- Backlog to be used for client-server RMI
 invocations during JNDI queries -->
 <attribute name="Backlog">50</attribute>

 <!-- Multicast Address and Group used for auto-discovery -->
 <attribute name="AutoDiscoveryAddress">230.0.0.4</attribute>
 <attribute name="AutoDiscoveryGroup">1102</attribute>

 <!-- IP Address to which should be bound: the Port, the RmiPort and
 the AutoDiscovery multicast socket. -->
 <!-- Client socket factory to be used for client-server
 RMI invocations during JNDI queries -->
 <!--attribute name="ClientSocketFactory">custom</attribute-->
 <!-- Server socket factory to be used for client-server
 RMI invocations during JNDI queries -->
 <!--attribute name="ServerSocketFactory">custom</attribute-->
 </mbean>

 <mbean code="org.jboss.invocation.jrmp.server.JRMPInvokerHA"
 name="jboss:service=invoker,type=jrmpha">
 <attribute name="ServerAddress">${jboss.bind.address}</attribute>
 <!--
 <attribute name="RMIObjectPort">0</attribute>
 <attribute name="RMIClientSocketFactory">custom</attribute>
 <attribute name="RMIServerSocketFactory">custom</attribute>
 -->
 </mbean>

 <!-- ==================================================================== -->
 <!-- Distributed cache invalidation -->
 <!-- ==================================================================== -->

 <mbean code="org.jboss.cache.invalidation.bridges.JGCacheInvalidationBridge"
 name="jboss.cache:service=InvalidationBridge,type=JavaGroups">
 <depends>jboss:service=DevPartition</depends>
 <depends>jboss.cache:service=InvalidationManager</depends>
 <attribute name="InvalidationManager">jboss.cache:service=InvalidationManager</attribute>
 <attribute name="PartitionName">DevPartition</attribute>
 <attribute name="BridgeName">DefaultJGBridge</attribute>
 </mbean>

</server>

JBOSS_HOME/server/all/deploy/deploy-hasingleton-service.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id: deploy-hasingleton-service.xml,v 1.1.2.2 2004/03/16 15:39:30 ejort Exp $ -->

<!-- ===================================================================== -->
<!-- -->
<!-- This service ensures that exactly one node in the cluster -->
<!-- deploys the services under "deploy-hasingleton" -->
<!-- -->
<!-- ===================================================================== -->

<!-- NOTE - Using DevPartition instead of DefaultPartition -->

<server>

 <!--
 |
 | Use the deployer service on the singleton node.
 |
 -->

 <mbean code="org.jboss.ha.singleton.HASingletonController"
 name="jboss.ha:service=HASingletonDeployer">
 <depends>jboss:service=DevPartition</depends>
 <depends optional-attribute-name="TargetName">jboss.system:service=MainDeployer</depends>
 <attribute name="TargetStartMethod">deploy</attribute>
 <attribute name="TargetStartMethodArgument">${jboss.server.home.url}/deploy-hasingleton</attribute>
 <attribute name="TargetStopMethod">undeploy</attribute>
 <attribute name="TargetStopMethodArgument">${jboss.server.home.url}/deploy-hasingleton</attribute>

 <!-- added to enable handling of a non-default partition name -->
 <attribute name="PartitionName">DevPartition</attribute>

 </mbean>

</server>

JBOSS_HOME/server/all/deploy/jbossha-httpsession.sar/ClusteredHttpSessionEB.jar/META-INF/jboss.xml:

<?xml version='1.0' ?>
<!DOCTYPE jboss PUBLIC
 "-//JBoss//DTD JBOSS 3.2//EN"
 "http://www.jboss.org/j2ee/dtd/jboss_3_2.dtd">

<!-- Version: $Id: jboss.xml,v 1.6.2.5 2003/11/23 22:49:29 slaboure Exp $ -->
<jboss>

 <enterprise-beans>
 <entity>
 <ejb-name>ClusteredHTTPSession</ejb-name>
 <jndi-name>clustering/HTTPSession</jndi-name>
 <local-jndi-name>clustering/LocalHTTPSession</local-jndi-name>
 <configuration-name>Clustered in-memory CMP EntityBean</configuration-name>
 <invoker-bindings>
 <invoker>
 <invoker-proxy-binding-name>this-rmi-invoker</invoker-proxy-binding-name>
 </invoker>
 </invoker-bindings>
 </entity>
 </enterprise-beans>

 <invoker-proxy-bindings>
 <invoker-proxy-binding>
 <name>this-rmi-invoker</name>
 <invoker-mbean>jboss:service=invoker,type=jrmp</invoker-mbean>
 <proxy-factory>org.jboss.proxy.ejb.ProxyFactory</proxy-factory>
 <proxy-factory-config>
 <client-interceptors>
 <home>
 <interceptor>org.jboss.proxy.ejb.HomeInterceptor</interceptor>
 <interceptor>org.jboss.ha.httpsession.beanimpl.ejb.ClientTCLInterceptor</interceptor>
 <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>
 </home>
 <bean>
 <interceptor>org.jboss.proxy.ejb.EntityInterceptor</interceptor>
 <interceptor>org.jboss.ha.httpsession.beanimpl.ejb.ClientTCLInterceptor</interceptor>
 <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>
 </bean>
 <list-entity>
 <interceptor>org.jboss.proxy.ejb.ListEntityInterceptor</interceptor>
 <interceptor>org.jboss.ha.httpsession.beanimpl.ejb.ClientTCLInterceptor</interceptor>
 <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>
 </list-entity>
 </client-interceptors>
 </proxy-factory-config>
 </invoker-proxy-binding>
 </invoker-proxy-bindings>

 <container-configurations>
 <container-configuration>
 <container-name>Clustered in-memory CMP EntityBean</container-name>
 <call-logging>false</call-logging>
 <container-interceptors>
 <interceptor>org.jboss.ha.httpsession.beanimpl.ejb.ServerTCLInterceptor</interceptor>
 <interceptor>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor</interceptor>
 <interceptor>org.jboss.ejb.plugins.EntityLockInterceptor</interceptor>
 <interceptor>org.jboss.ejb.plugins.EntityInstanceInterceptor</interceptor>
 <interceptor>org.jboss.ejb.plugins.EntitySynchronizationInterceptor</interceptor>
 </container-interceptors>
 <instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool>
 <instance-cache>org.jboss.ejb.plugins.ClusterSyncEntityInstanceCache</instance-cache>
 <persistence-manager>org.jboss.ejb.plugins.CMPClusteredInMemoryPersistenceManager</persistence-manager>
 <locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy>

 <container-cache-conf>
 <cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy>
 <cache-policy-conf>
 <min-capacity>50</min-capacity>
 <max-capacity>1000000</max-capacity>
 <overager-period>300</overager-period>
 <max-bean-age>600</max-bean-age>
 <resizer-period>400</resizer-period>
 <max-cache-miss-period>60</max-cache-miss-period>
 <min-cache-miss-period>1</min-cache-miss-period>
 <cache-load-factor>0.75</cache-load-factor>
 </cache-policy-conf>
 </container-cache-conf>
 <container-pool-conf>
 <MinimumSize>10</MinimumSize>
 <MaximumSize>100</MaximumSize>
 </container-pool-conf>
 <commit-option>A</commit-option>
 <cluster-config>
 <!-- NOTE - using DevPartition instead of DefaultPartition -->
 <partition-name>DevPartition</partition-name>
 </cluster-config>
 <depends>jboss:service=DevPartition</depends>
 <depends>jboss:service=invoker,type=jrmp</depends>
 </container-configuration>
 </container-configurations>

</jboss>

jboss-service.xml of my SAR deployed in the deploy-hasingleton directory:

<?xml version="1.0" encoding="UTF-8"?>

<server>

 <!-- MBean to hold all user messages received from the queue -->
 <mbean code="com.harborsideplus.grover.mbean.AllUserMessages"
 name="grover.mbean:service=AllUserMessages">
 </mbean>

 <!-- HASingletonController to run the above MBean as a singleton -->
 <mbean code="org.jboss.ha.singleton.HASingletonController"
 name="jboss.hasingleton:service=AllUserMessagesSingletonController">
 <depends>jboss:service=DevPartition</depends>
 <depends>grover.mbean:service=AllUserMessages</depends>
 <attribute name="TargetName">grover.mbean:service=AllUserMessages</attribute>
 <attribute name="TargetStartMethod">startSingleton</attribute>
 <attribute name="TargetStopMethod">stopSingleton</attribute>
 </mbean>

 <!-- MBean to hold information for all users -->
 <mbean code="com.harborsideplus.grover.mbean.AllUserInfo"
 name="grover.mbean:service=AllUserInfo">
 </mbean>

 <!-- HASingletonController to run the above MBean as a singleton -->
 <mbean code="org.jboss.ha.singleton.HASingletonController"
 name="jboss.hasingleton:service=AllUserInfoSingletonController">
 <depends>jboss:service=DevPartition</depends>
 <depends>grover.mbean:service=AllUserInfo</depends>
 <attribute name="TargetName">grover.mbean:service=AllUserInfo</attribute>
 <attribute name="TargetStartMethod">startSingleton</attribute>
 <attribute name="TargetStopMethod">stopSingleton</attribute>
 </mbean>

 <!-- MBean to provide user manager services -->
 <mbean code="com.harborsideplus.grover.mbean.UserManager"
 name="grover.mbean:service=UserManager">
 </mbean>

 <!-- HASingletonController to run the above MBean as a singleton -->
 <mbean code="org.jboss.ha.singleton.HASingletonController"
 name="jboss.hasingleton:service=UserManagerSingletonController">
 <depends>jboss:service=DevPartition</depends>
 <depends>grover.mbean:service=UserManager</depends>
 <attribute name="TargetName">grover.mbean:service=UserManager</attribute>
 <attribute name="TargetStartMethod">startSingleton</attribute>
 <attribute name="TargetStopMethod">stopSingleton</attribute>
 </mbean>

</server>

I am getting an exception complaining that the HASingletonController being used to control one of my singleton MBeans (as declared in the jboss-service.xml above) cannot find an HAPartition instance named DefaultPartition. However the partition name it should be looking for is DevPartition, as declared in all of the above .xml files.

2004-09-30 16:29:45,955 ERROR [org.jboss.ha.singleton.HASingletonController] Starting failed jboss.hasingleton:service=AllUserMessagesSingletonController
javax.management.InstanceNotFoundException: Failed to find HAPartition with PartitionName=DefaultPartition
 at org.jboss.ha.jmx.HAServiceMBeanSupport.findHAPartitionWithName(HAServiceMBeanSupport.java:388)
 at org.jboss.ha.jmx.HAServiceMBeanSupport.setupPartition(HAServiceMBeanSupport.java:168)
 at org.jboss.ha.jmx.HAServiceMBeanSupport.startService(HAServiceMBeanSupport.java:140)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:271)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:221)
 at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)

and on and on and on...

Can anyone see that I've done something wrong in the above *.xml files ? Have I forgotten to do anything else which is necessary ?

Thanks in advance for any help with this issue.


--James

[starksm64]

Add a PartitionName attribute to the deploy-hasingleton-service.xml HASingletonController:

 <mbean code="org.jboss.ha.singleton.HASingletonController"
 name="jboss.ha:service=HASingletonDeployer">
 <depends>jboss:service=DefaultPartition</depends>
 <depends optional-attribute-name="TargetName">jboss.system:service=MainDep
loyer</depends>
 <attribute name="PartitionName">DefaultPartition</attribute>
 <attribute name="TargetStartMethod">deploy</attribute>
 <attribute name="TargetStartMethodArgument">${jboss.server.home.url}/deplo
y-hasingleton</attribute>
 <attribute name="TargetStopMethod">undeploy</attribute>
 <attribute name="TargetStopMethodArgument">${jboss.server.home.url}/deploy
-hasingleton</attribute>
 </mbean>

Its easier to isolate the cluster traffic by changing the mcast_addr or mcast_port of the ClusterPartition in the cluster-service:

 <!-- The JGroups protocol configuration -->
 <attribute name="PartitionConfig">
 <Config>
 <!-- UDP: if you have a multihomed machine,
 set the bind_addr attribute to the appropriate NIC IP address -->
 <!-- UDP: On Windows machines, because of the media sense feature
 being broken with multicast (even after disabling media sense)
 set the loopback attribute to true -->
 <UDP mcast_addr="228.1.2.4" mcast_port="45567"
 ip_ttl="32" ip_mcast="true"
 mcast_send_buf_size="800000" mcast_recv_buf_size="150000"
 ucast_send_buf_size="800000" ucast_recv_buf_size="150000"
 loopback="false" />

[monocongo]

Add a PartitionName attribute to the deploy-hasingleton-service.xml HASingletonController:

As you can see in my original post above I have done this already. Unfortunately it seems to have no effect.

Its easier to isolate the cluster traffic by changing the mcast_addr or mcast_port of the ClusterPartition in the cluster-service:

So it appears that it's impossible to run separate clusters on the same local network by using different partition names, only clusters with different mcast addresses. If this is so then why have PartitionName attribute entries peppered throughout the various config files, since these have no effect ? My impression is that the original approach I was taking is the way it was designed to work, based on the existence of the various PartitionName attrtibutes in the config files, but this is not working yet and hence we must modify the mcast_addr or mcast_port values as a workaround. Is this the case, or am I missing something here ? Will this feature be fully enabled in future releases (perhaps it's already working in version 4.0) ?


--James

[darranl]

What about adding the partition name to the three 'HASingletonController' definitions in the jboss-service.xml of your SAR deployed in the deploy-hasingleton. The error message you are getting is referring to the top one of these.

[monocongo]

I have done this, see my original post above. In fact in every *.xml file which contained DefaultPartition I have changed the name to DevPartition, including the jboss-service.xml which is included in my MBeans' SAR. I use the partition name "DevPartition" in the depends sections for the HASingletonControllers used for my singleton MBeans as suggested. It seems that whatever is supposed to get this dependency information is not picking it up, and then tries to look for DefaultPartition instead, which doesn't exist since the partition name in cluster-service.xml has been changed to DevPartition.


--James

[monocongo]

darrenl perhaps I initially misunderstood your suggestion. Are you suggesting that I add a PartitionName attribute to the HASingletonControllers, and not just change the name of the service dependency (depends jboss:service=DevPartition) ?

I will give this a try and see what happens.


--James

[monocongo]

This suggestion appears to have gotten me past my original problem, but not out of the woods. I now get an error with my EJBs not being able to be started in that JBoss is still looking for DefaultPartition:

11:39:19,403 ERROR [StatelessSessionContainer] Starting failed jboss.j2ee:jndiName=ejb/IOIManager,service=EJB
javax.naming.NameNotFoundException: DefaultPartition not bound
 at org.jnp.server.NamingServer.getBinding(NamingServer.java:495)
 at org.jnp.server.NamingServer.getBinding(NamingServer.java:503)
 at org.jnp.server.NamingServer.getObject(NamingServer.java:509)
 at org.jnp.server.NamingServer.lookup(NamingServer.java:282)
 at org.jnp.server.NamingServer.lookup(NamingServer.java:256)
 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:530)
 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:509)
 at javax.naming.InitialContext.lookup(InitialContext.java:347)

 ... etc.

So it really looks like DefaultPartition is hard-coded somewhere as the partition name to be used when clustering and no amount of PartitionName attributes in the configuration files can effect this.

Additionally it seems that the partition name can't be used in the jndi.properties file for Naming Discovery, as specified in http://www.jboss.org/wiki/Wiki.jsp?page=AccessEJBsRemotely, or at least it doesn't work for me using JBoss 3.2.5. When I use DefaultPartition as the value (jnp.partitionName=DefaultPartition) I get an error, but when I comment this out I have no problems. It appears that the NamingService is being started before the ClusterPartition, and since this partition doesn't yet exist the NamingService croaks when it can't find it.

Why are all of these PartitionName attributes provided if they don't work as they should ? Are the developers aware of these issues ? Should this be filed as a bug ? Is this working in version 4.0 ?


--James

[gozilla]

Hi monocongo,

You may want to try to 'JBossConfigurator'

http://damon.sicore.org/blojsom/blog/default/Development/?permalink=jBossConfigurator.txt

They did aextensive job at searching the places where to change partition names, etc ...

I based my deployments on their job, it's working

Cheers,
François