[jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-957) Provide a configuration(installation) that will work in the All configuration.

[Brian Stansberry (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-957?page=comments#action_12362060 ] 
            
Brian Stansberry commented on JBMESSAGING-957:
----------------------------------------------

AS clustering does something in this area with a hack.  You can see it in cluster module, o.j.ha.framework.server.ClusterPartition.startService() and o.j.ha.framework.server.HAPartitionImpl.startPartition(). JGroups API let's you pass a CONFIG event down the channel; if the event argument is a map with key 'additional_data' the value under that key gets stored in the IpAddress object identifying the channel.

The clustering code generates the additional data by combining the address and port JNDI is running on.  That should be unique, since if it wasn't you'd have a port conflict for JNDI.

HAPartitionImpl.startPartition() calls a verifyNodeIsUnique() method to confirm that there's no other member with the same additional_data.  This is a guard against a member restarting or rejoining the group before the rest of the group realizes the old incarnation has left.

JGRP-129 will be a much better solution to this problem. I know Bela wants to get rid of the additional_data 'feature' once JGRP-129 is done.

Note the above isn't persistent; i.e. if you restart a node but change the bind address, you get a different id.

Web clustering with mod_jk also gives nodes an id in the Tomcat server.xml file.  For that I recommend in training that people use a system property in the XML and set the property from an environment variable in the script that launches JBoss.

> Provide a configuration(installation) that will work in the All configuration.
> ------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-957
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-957
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>            Reporter: Jay Howell
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.SP2
>
>
> When using the installation process for messaging, you install and it creates a new container based on the Default container.  We need to also be able to have one for the All container also.  Many customers want to run Messaging in clustered mode as well as everything else.  The all configuration is the current way to do this. 
> Note: Here's some background and some problems you may run into with the install of messaging 1.2.0 sp2 on 4.0.5 using an all configuration.  Had an instance yesterday, where the customer moved thier clusterd post office configuration to all.  This works as long as messaging is deployed in a scoped classloader.  I know that sp2 will copy the remoting and aop libs into the main lib directory for the container in order to avoid the scoped classloader.  So I had the customer do what sp 2 will do, copy over the old remoting and aop jars.  Becasue messaging is using an updated version of jgroups also, and jgroups is in the lib directory of the container, it picks that one up first before the one in messaging.  We copied over the jgroups jar just as we did for remoting and aop. I found that the container comes up with no problem, but I can no longer get to jconsole and things don't work correctly(no errors, but it won't work either).  I don't know what the problem is, but running the all configuration with the clustered post office without a scoped classloader seems to have problems.
> Jay:)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira