Here’s a situation that I’m hoping someone can help out with. I’ve read through a bunch of the docs and haven’t found an approach…

We have multiple IS instances in a an IS-cluster. All connected to a single Broker. All using the same client group and client prefix. Each instance has the same packages with the same triggers. With this configuration, a published document will get processed by just one of the IS instances. This is exactly as desired for 99.999% of the documents.

There is a situation in which we want every IS instance in the cluster to get and process a given document. For example “clear your custom configuration cache.” What are the techniques available to accomplish this?

I see that “State Sharing” = “Disabled” clients are created by IS with client ID of the form <ip><port><function>, such as 12.12.12.12_5555_SyncClient or 12.12.12.12_5555_RequestReplyClient. This sort of configuration would provide the desired behavior. The question is how can we configure/use something like this with the existing Developer/Administrator tools? Can we tap into one of these? Can we create such clients ourselves (without resorting to using the Java API)? Any and all thoughts appreciated.

Rob

Rob,

Why not make a service on the IS instance that receives the message do a remote invoke on each server in the cluster in this special case?

In this way your messaging works exactly the same way, but the service that is invoked (and only that service) has the burden of identifying the servers in the cluster and invoking the “clear your configuration cache” service. This service should be configured to not be load balanced.

HTH,

Mark

Mark:

We are considering doing exactly what you describe. We may end up doing that but wanted to see if there is a Broker-based way to do it.

Rob

Well, that “without using the Java API” constraint probably means that there is no way to what you want, but maybe someone else may have a suggestion.

IMHO, your use case is another good reason for an IS server to be able connect to more than one Broker or to connect to the same Broker multiple time. One connection could be shared state and the other could be “normal”.

Mark

It is indeed very nice that IS hides a bunch of the details under the covers for managing the Broker queues (not sure why they insist on calling these “clients”) but it would also be nice to be able to control the settings of a queue for a given trigger when necessary.

The ability to connect to multiple brokers from a single IS just seems so obvious that I really don’t understand why that facility isn’t provided…

Oh well.

Rob,
I’m just thinking out loud here, might be a dumb idea but. Could you use jms instead? I’m thinking one topic with multiple shared clients subscribing. Each IS server would be able to connect via the JMS adapter in a shared state to the same broker. I’ve only tried this with java clients but in theory it could work with the IS servers acting as clients as well. Maybe a bit of overkill for what you are trying to do. But I think it might would work.

markg
http://darth.homelinux.net

Another hack would be to have the IS instance that received the published document post the message to each IS instance in the cluster. Might be a bit cleaner than remote invoke (my original suggestion) and less work than JMS.

Both good alternatives to explore. Thanks for the input.