DMQ/BMQ question

[Willem Grooters]

Perhaps not the best place to ask, but someone may give a quick answer:

Suppose 2 nodes, same DMQ bus.

Node 1: Application X starts up, binds to group Y (not yet existing and so creates connection)
Node 2: Application X starts up, binds to group Y.

If node1 and node2 run in as a cluster, Node2::X would now be unable to do anyting since group Y is now onwed by Node1::X and so node2::X will get into a wait state, to become active only if, for whatever reason, Node1::X gives up.

But what happens if node1 and node2 are stand-alone systems:
1: Node2::X waits until Node1::X stops and group Y is released.
2: Node2::X will startup and access group Y

(You may assume that the DMQ configuration is correct)

WG

[Wim Van den Wyngaert]

I know nothing but found this
http://edocs.bea.com/tuxedo/msgq/vmsconf/chap13.htm

Wim

[Sheldon Smith]

Wow! It's been years since I looked at DMQ. It sounds like you are trying to solve a "deadly-embrace" problem.
I don't remember all of the terminology, but why wouldn't you have both nodes 1 and 2 start up and attach to a pre-existing, permanent shared queue? As I recall, each also has its own temporary queue to send directly to the desired node. Otherwise, either node can get the next message from the shared queue, or wait....

[Willem Grooters]

Wim,
Thanks for this link - I couldn't work my way through the BEA site. It/s very useful.

Sheldon,
The idea is that if the proces on Node1 has started, the one on Node2 should not continue and be 'stand-by' to take over if the proces on node1 stops. WOuld that be possible using permanent shared queues?

[Willem Grooters]

For a good understanding of the problem: The proces X connects to a number of other processes, some passing information to the process, others for sending out (broadcasting to particuler other processes). These other processes can reside anywhere - same, or other nodes.
This is the proces X that will start on node1 first and be active, and second on node2, becoming standby - to implement a kind of automatic failover. I know it works in a cluster environment, the program however cannot run in a cluster (technical reasons beyong the scope of this question) so it would be nice to know whether it would work in a non-clustered environment.

[Sheldon Smith · Accepted solution]

With a permanent shared queue, the idea is that any server process can receive a(n initial) message and process it. If the message is the first of a transaction series, the receiving server process replies to the client letting the client know what the process' personal mailbox is. The client would send subsequent messages for the transaction series to the process' personal mailbox. In the meantime, if another transaction was initiated, it would be picked up by any free server process, or wait until a server process became free.

I also vaguely recall something about having a permanent non-shared queue, and possibly some way to indicate "interest", and get notified when it becomes free.

Like I said, it's been several years since I looked at DECmessageQ.

[Willem Grooters]

Both have given me sufficient information to answer the question: it's 2.