Skip to main content

This content has been archived and is no longer being updated. Links may not function; however, this content may be relevant to outdated versions of the product.

Support Article

Lot of JMS/SIB communication beetwen servers in cluster



Noticed some Chordiant activity on JMS and SIB components on WebSphere Application Server. In our solution we suspect that there is no need for any data to be synchronized by Chordiant between servers in cluster (at the moment we have 2 nodes with 3 app servers on each). Users should be sticked to one server and their http sessions aren't replicated.

Is it possible to disable any such communication for Chordiant? Its been noticed that it takes noticeable amount of CPU to execute onMessage metods related to ex. UserProfile_Cache_Topic

During diagnostic of performance problem we are changing number of concurrently running application servers. Can it cause any problems or overhead if number of all servers in config file is bigger than real number of servers/instances?

We are using Chordiant 6.6 on WebSphere Application Server 7 on AIX.

Error Messages


Steps to Reproduce

Log in to Chordiant

Root Cause

The root cause of the issue was number of JMS messages being passed between servers in Cluster


Given the uniques cluster requirement at customers end, following suggestion and a tuning patch to mitigate the problem has been provided:

1. Setting RegistryConnector.xml \ SYNCACHE parameter to false
Please note: SYNCCACHE set to true synchronizes UserProfileCache across cluster, at the time of failover the user activity are not affected.
If you set this to false, UserProfileCache is not updated across cluster, so if you add roles or permission to user from a different machine, its very likely that the cache in other jvm’s won’t be updated and changes will not reflect.
However, subsequent re-start of cluster will pick up new values from DB and then changes will be reflected. This is a trade-off, if you set SYNCCACHE to false.

2. Applying tuning patch HotFix-912 (modifications of SessionTopicListener java class).

3. Setting "Maximum concurrent MDB invocations per endpoint" parameter value to 1 in WAS admin console.

Published June 12, 2015 - Updated October 8, 2020

Was this useful?

0% found this useful

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice
Contact us