[
http://jira.jboss.com/jira/browse/JBMESSAGING-957?page=comments#action_12... ]
Tim Fox commented on JBMESSAGING-957:
-------------------------------------
A logical JMS quueue in JBoss Messaging is actually composed of a set of individual
queues, one for each node in the cluster that the logical queue is deployed on.
Each queue fragment is owned by that node and will contain a different set of messages
than other queue fragments.
This is why we need a persistent node id, so the node knows which queue fragments in the
database it owns so it can load the queue state on startup and add/remove messages.
I'm beginning to think the tomcat approach of specifying the node id in a system
property is the best. This allows the actual JBM config to remain the same across each
node.
Do you see any problems with this approach. In particular I'm thinking cluster
installation will become more complex since the user will have to manually specify the
unique node id on each run.sh - which they currently don't have to do with AS cluster
install.
Another possibilty would be for JBM to generate a unique id on startup if it can't
find one in some config file. Once it's generated it, it would save it locally. This
has the difficulty of guarantee uniqueness of the id across the cluster (the id is
currently an int, not a string for performance reasons).
Any comments?
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