3 Replies Latest reply on Aug 28, 2004 6:08 PM by John Margaglione

    On-the-fly durable subscriptions?

    John Margaglione Newbie

      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