[ataylor]

try changing the attribute to:

<attribute name="ServerPeerID">0</attribute>

[ebenezersamuel]

Thanks for the reply.

That was the first thing I had done when I saw the error; I changed in both the instances and still the error wouldn't go away.

For node 1:

<attribute name="ServerPeerID">0</attribute>

For Node 2:

<attribute name="ServerPeerID">1</attribute>

Thanks,
Ebe

[clebert.suconic]

Ebe, Sorry about that:


http://jira.jboss.com/jira/browse/JBMESSAGING-1376


You really need a shared DB between the nodes to store some shared configuration.

I will verify what could be done.

[clebert.suconic]

I will verify what's happening in a bit.

Having a shared DB is a workaround for now.

[clebert.suconic]

The problem is the ID generation on Clustering.

We store the next sequence on a Table, and that's used to synchronize the counting between the nodes. We will have to guarantee the IDs are unique on NullPersistence, and we can't do that now.


At the moment we can't support NullPersistence in clustered because of that. We will keep that JIRA opened and that will be implemented on a later release.


At the moment you could use a shared DB to store your data.

[ebenezersamuel]

Thanks for the reply Clebert. I am looking forward to your fix for this because we cannot go ahead with the shared database approach since the client which consumes the messages immediately puts the received messages in to the database and if we use a shared database, JBoss going to store those messages in the database and then our client when it receives it is again going to store it in the database.

I am wondering if shared database can be the only approach; is it a very bad idea to use a centralized cache or something [forgive me if my idea is very bad :) ]

I really appreciate Tim, Clebert and Andy for replying to the posts quickly and keeping the forum alive.
Thanks once again.

Regards,
Ebe