Stateless cluster issue


We are in process of migration from 8.2 to 9.8 and facing a strange issue, which is as below.

Existing system is configured to work with stateless cluster( not using any clustering solution) e.g. two IntegrationServer connected to same Broker , using same database schema for product database, using shared client prefix to identify the IS at Broker etc. Which is working fine on existing environment.

On the new build with all the above configuration, if trigger is enabled at both the IntegrationServer it’s not working ( unable to trigger the flow ), however once trigger is disabled on either of IS it works fine.

Any idea what could be reason or we are missing something?

Thanks in advance for help



Can you please confirm.triggers from two different IS, are consuming same document type ?


Both the ISs have same business logic. Yes, both trigger is consuming same document type

Hi Manish ,

Are you getting any error on the Integration Server / Messaging provider when the trigger is enabled on both the cluster members , can you please post the error message.

Are you using Broker or UM as messaging provider in the upgraded 9.8 environment ?


My troubleshooting procedure would be:

  • monitor the queue
  • Increase logging to debug or trace on the broker/UM and IS (assuming you are on a isolated environment)
  • have a Dead Letter Queue enabled to catch unsubscribed/dead events
  • disable all the triggers
  • publish a document
  • check if the document is in the queue
  • enable one trigger
  • check the document is no longer in the queue
  • check the document was processed in the IS
  • reverse the triggers and test again
  • enable both triggers and test again
  • is the document still in the queue?
  • if not, which IS processed the document?
  • if none, is the document in the DLQ?
  • do you have anything logged?

Best Regards

also check how many client queues are created for the trigger? If you have set the client ID same for both the IS, you should just see one trigger client queue… Click on the client queue and see how many sessions you can see… verify the IP address from where the sessions has got established… if you see two different IP addresses of stateless IS cluster, then the configuration is right… once we have that confirmation, can move to the next level of debugging where else things might go wrong…


Can you check properly whether triggers are created and enabled properly in both the IS? Also compares the borker settings between old and new.

Increase the log level and see if there are any errors in IS.