webMethods

Product/components used and version/fix level:

Integration Server 10.3 Core_Fix19
Broker 9.6 9.6.0.26.1004 090321

Detailed explanation of the problem:

We recently upgraded a system from webMethods version 9.8 to 10.3. The system uses Broker not Universal Messaging.
On the 9.8 system, the Integration Servers were using separate client prefixes, in the Broker Connection Aliases. Lets say Integration Server 1 was using prefix ‘X’ and IS 2 was using ‘Y’. When we upgraded to 10.3, we modified the prefix on IS 2 to use ‘X’ like IS 1. We migrated all of the Integration Server Packages using the webMethods migration scripts and we migrated the Broker Storage using the procedure in the upgrade manual.

Although both new, 10.3 Integration Servers are now using prefix ‘X’, Broker clients still exist with the prefix ‘Y’. Documents still get queued against these clients which steadily fills up the available storage, because no Integration Server Client is configured to handle these queue entries.

We thought that the queues for clients with prefix ‘Y’ would not be used once both Integration Servers were configured to use prefix ‘X’. Why are entries still being queued against them?

Is it safe to simply delete the Broker clients which use the unwanted ‘Y’ prefix?

Error messages / full error message screenshot / log file:

Question related to a free trial, or to a production (customer) instance?

Production

you can go ahead delete them …Make sure you do them in non prod first and test the interface flow for couple of them …then you can ahead with production.

Hi Miles,

are IS1 and IS2 running in cluster mode or not?
When running in cluster mode you can proceed as Sandeep has described.

When not running in cluster mode, each IS should have its own prefix to avoid mix up of data between the instances esp. while running Process Models with resubmit feature enabled.

Regards,
Holger

The word “cluster” without qualification is ambiguous. There are multiple types of clusters that are useful with IS. Which to use depends how you want the IS instances to behave

• Load balanced (LB) cluster – a network device of some sort sits in front of 2+ identically configured (mostly) IS instances and routes traffic to them as configured by the LB device (round robin, least busy, sticky, session-based, etc.)

• IS cluster - 2+ identically configured (mostly) IS instances configured to use Terrracotta to share state data between them; typically (always?) in conjunction with an LB cluster; IS instances running process models require the use of IS cluster (as @Holger_von_Thomsen notes) since step transitions can hop servers and they need the shared state data.

• Messaging cluster - 2+ identically configured (mostly) IS instances configured with the same client prefix. Broker and UM. This does not need an IS cluster to function, unless there are message joins used in subscribers. In this structure, only one of the nodes ever processes a given message from the queue/topic. This also supports serial processing of a topic, even with multiple IS nodes.

• TN cluster - 2+ identically configured (mostly) IS instances configured to use the same TN DB and settings so that they know about each other so then when a config item is changed on a node, it can notify the others to reload their TN config.

Our usage – 2 instances use the same prefix for messaging cluster (we have 7 sets of these). 2 other instances run PRT/PE and have the same client prefix too. I’m not familiar with the limitation @Holger_von_Thomsen mentions – we’ve moved off PRT/PE but in the past I know we were able to resubmit/resume without issue. If you’re using PRT/PE then this can be explored further. But if not, likely don’t need to elaborate.

I would recommend to first understand where the “old” queues come from.

Can it be that you did not upgrade Broker but only IS?

@jahntech.cj - based upon this, they are retiring the old queues, having IS 1 and 2 be a messaging cluster. The old queues were because IS 1 and 2 used different client prefixes. Now they don’t.

From what I see, the old queues/topics can be deleted. Indeed, need to be manually deleted because from a Broker perspective, they are still active.

Yeah, that is a trap I also fell into many years ago. It is one of those situations that makes you realize that a distributed system definitely has some “interesting” properties