On-the-fly durable subscriptions?

[jmargaglione]

I am creating an architecture built around JMS, but with a slightly novel approach. Before I describe my problem, let me first give a couple restraints I have on the architecture:
1. This is an embedded piece of software, delivered as part of a hardware solution for Factory Automation.
2. The hardware is plug-n-play, so there must be no on-site JBoss configuration (unless it can be done by the software automatically, meaning without user input ). The machine should be able to simply boot up and be a part of the processing tasks.
3. Every piece of hardware runs an instance of a JMS provider that provides subscription services (topics) to other machine processes, exposing the data that it is creating. Some of these subscriptions will be durable, some will not. All subscriptions will be persistent.
4. JGroups is used to notify every machine on the network when a new machine enters or leaves.

OK, so now on to the problem. The idea behind the architecture is that when a new piece of hardware is powered on, it first looks around the network (using JGroups) to see if there are any topics to which it should subscribe. When a JGroup message indicates that a desired service has appeared, the receiving machine gets the IP address and topic name (embedded in the JGroups message), and tries to dynamically connect to the JMS server running at that IP address. This works like a charm for non-durable subscriptions. But when I try to do durable subscriptions I hit a wall, because in order for a new machine to get a durable subscription I need to have a unique client ID set up on every other JMS machine (or at least that's what I am thinking). This is obviously not a good thing for a plug and play system.

Part of the architecture is redundancy, created by having multiple identical services collecting data published through JMS. So for example there may be two database services storing data coming from the JMS topic A on machine 1. These two databases should end up with the same data on them, so that one of the databases can be taken offline for service, then when plugged back in it will catch up on all the messages it missed.

The JMS spec indicates that this may not even be possible, but it seems a little vague to me, and that there might be room for a vendor to make on-the-fly ClientID's possible. What I would ideally like to see happen is that in my code I set the ClientID of the connection to the IP address + programName and JBoss says "OK, you want a new ClientID created for this new machine/process on the network. But it looks as though all possible ClientID's must be set in the configuration files. Is there a way for me to programmatically add new ClientID's on the fly from remote machines? I am thinking that I can use the JMX interface for the JBossMQ MBean, but that doesn't exactly make my architecture portable to other message queues, which may become necessary for some customers for integration purposes.

Thanks for taking the time to parse this question.

John

[jmargaglione]

I wanted to point out that I read the post by shartvig, and though he has similar issues he is not in quite the same situation as I am. In his case there is only one JBoss instance to update, and there is likely a computer-literate person available to make adjustments to that one JBoss instance when necessary (or to have a software interface to do so).

[adrian.brock]

Moderated FAQ: http://www.jboss.org/wiki/Wiki.jsp?page=WhatIsTheCorrectWayToMakeADurableSubscription

[jmargaglione]

Adrian,

Thanks for the pointer to the FAQ. I had actually already read it, but I missed a key point: the setClientID must go before the createDurableSubscriber. I had the setClientID after the createDurableSubscriber, right before connect. I was under the false impression that this was the proper order. The change seems to have made all the difference.

John