JBossDeveloper

"bela@jboss.com" wrote:
I think JMS defines FIFO as the default: only messages from a given sender S need to be delivered in the order in which S sent them, so
A B C D
and
C A B D

*are* in FIFO order, because A --> B and C --> D.

I don't think (as Adrian mentioned) JMS has a notion of causal or total order delivery.

E.g. active node has messages A, B, C, D

but backup has messages C, A, B, D

This means when I multicast a receive(), the active node is going to remove the first message - message A and put it in delivering state.

But the backup node is going to remove the first message - message C and put it in the delivering state.

Then I multicast an ack(message A). The active node will receive it and remove message A.

But the backup node will receive it and say "but message A is not in the delivering state" and barf

We would also have to make the replicated operations not dependent on position in the queue.

E.g. instead of replicating "remove first message", we replicate "remove message 765".

This shouuld work.

The plot thickens...

Just thought of another possible complication.

So that we can cope with very large queues, the current queue implementation is "pageable", i.e. if there are a large number of messages in the queue, it only keeps a certain number in memory at once and pages them to and from persistent storage in chunks as necessary as messages are added/removed.

We assume the backup and master are sharing the same persistent store (this may not be true in the future, but for now it is).

For HA we are only interested in the replicating the in-memory state of the queue.

Imagine master has the following message in memory:

A B C D

The backup has the following:

C A D B

the queue is configure to only allow 4 messages in memory at once.

also both nodes have message E in the delivering state

message E gets cancelled - which causes it to get put back at the front of the queue, this means the master ends up with

E A B C, and message D drops off into persistent storage

we replicate the cancellation to the backup resulting in

E C A D, with B dropping off (on the backup we don't actually insert it into persitent storage).

Now message E is consumed and acknowledged. This results (on the master) on message D being pulled back from persistent storage, resulting in the master with:

A B C D

But the backup has

C A D D

I.e now we have duplicate messages in the queue

We could instead drop off message D from the backup too, giving:

E C A B

which would give

C A B D after E is consumed and the message is pulled back. (i.e. the B and D are reversed)

Which would prevent the duplicate but we lose the guarantee of order of messages from same jms session.

I wouldn't be suprised if there are other similar pathological conditions when paging is introduced.

Actually I don't think this means we lose the jms ordering guarantee, but we certainly have more state changes to replicate from master -> backup.

I.e. remove(bunch of messages), add (bunch of messages) when paging occurs.

Eventually, being able to configure the "passivation store" separately from the persistence store would be nice, right now they use the same store.