Unique Post Office Id

[dimitris]

If you try to start 2 AS5's, either with service binding manager or by binding to different ports, you now get on the 2nd node the problem of:

 ...
12:50:06,453 ERROR [ExceptionUtil] org.jboss.messaging.core.jmx.MessagingPostOff
iceService@7ce5bf startService
java.lang.IllegalArgumentException: Cannot start post office since there is already a post office in the cluster with the same node id (0).
Are you sure you have given each node a unique node id during installation?
 at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.start
 ...

Shouldn't that work out-of-the-box and then let you override it, if necessary?

[timfox]

Each node in the cluster must have a unique server id.

[timfox]

There have been several threads about this (weren't you involved?) ;)

[dimitris]

Can't find the discussion thread, sorry.

Again, my point is why not printing a warning and choosing a temporary id?

Sure, it may not make perfect sense (as with other services in jboss) that need proper configuration, but it'll let the server gracefully complete the booting sequence.

At this point the Post Office is the only service that complains when trying to create an instant cluster by forking the all configuration, either for demo or testing purposes:

13:11:33,796 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of
incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

*** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual Stat
e}

jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory
 -> jboss.messaging:service=PostOffice{Start:**ERROR**}
 -> jboss.messaging:service=PostOffice{Create:**ERROR**}

jboss.messaging.connectionfactory:service=ClusteredConnectionFactory
 -> jboss.messaging:service=PostOffice{Start:**ERROR**}
 -> jboss.messaging:service=PostOffice{Create:**ERROR**}

jboss.messaging.connectionfactory:service=ConnectionFactory
 -> jboss.messaging:service=PostOffice{Start:**ERROR**}
 -> jboss.messaging:service=PostOffice{Create:**ERROR**}

jboss.messaging.destination:name=DLQ,service=Queue
 -> jboss.messaging:service=PostOffice{Create:**ERROR**}
 -> jboss.messaging:service=PostOffice{Start:**ERROR**}

jboss.messaging.destination:name=ExpiryQueue,service=Queue
 -> jboss.messaging:service=PostOffice{Create:**ERROR**}
 -> jboss.messaging:service=PostOffice{Start:**ERROR**}


*** CONTEXTS IN ERROR: Name -> Error

jboss.messaging:service=PostOffice -> java.lang.IllegalArgumentException: Cannot
 start post office since there is already a post office in the cluster with the
same node id (0). Are you sure you have given each node a unique node id during
installation?

[apwalker]

In all my deployments of JBM I add a System Property to allowing simple AS node configuration. I keep mean to commit this :)

See below

 <mbean code="org.jboss.jms.server.ServerPeer"
 name="jboss.messaging:service=ServerPeer"
 xmbean-dd="xmdesc/ServerPeer-xmbean.xml">

 <!-- The unique id of the server peer - in a cluster each node MUST have a unique value - must be an integer -->

 <attribute name="ServerPeerID">${jboss.messaging.ServerPeerID:0}</attribute>

 <!-- The default JNDI context to use for queues when they are deployed without specifying one -->

 <attribute name="DefaultQueueJNDIContext">/queue</attribute>


......

[timfox]

Can't find the discussion thread, sorry.

Again, my point is why not printing a warning and choosing a temporary id?

Well if it was that simple, we'd have probably done it already?

The problem is that the id is used to identify the nodes permanent storage - so it cannot be transient, it has to persist between restarts.

Also it's an integer, and we'd have to make sure it's unique across all nodes in the cluster.

Doing that automatically is non trivial - you need some kind of HA singleton counter that dishes out IDs (yuck).

Alternatives would be to make it a GUID, but it's used as a key in the message data tables so this would have performance implications.

Also making it a GUID would probably p*off some sys admins since an integer id makes it easy to identify a particular server (server 1, server 2, server 3 etc), whereas a GUID does not.

As Aaron pointed out, passing in a sys prop is a good idea.

Brian Stansberry also suggested we should have some kind of concept of server id at the AS level - then we could just use that.

[dimitris]

The sys property is the easy way out, for now, so I think I'll add it anyway.

In the long term, we need to have a server facility for picking up those unique/persistent ids, so let's start a thread for that.

[dimitris]

Property added: http://jira.jboss.org/jira/browse/JBAS-5196

[dimitris]

New discussion http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4125774

[brian.stansberry]

The existing discussion is here: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=108609