Disabling wM component in clustered environment in one go....

, ,
1

Hi Everyone,

Is there any way we can configure our IS in clustered environment so that we can control all IS from any of the IS server in cluster.

Generally we monitor our various IS component like trigger/schedular/notification and make them enable disable depending upon target availability.
Suppose I have one schedular service which runs on 5 mins interval and check the target connectivity and if we get target is not UP then we make our corresponding component disable and vice-versa.The same thing I want to make in cluster environment of 4 server and schedular will run only in one environment and if we get target is Un-available/Available then needs to disable/enable component across the cluster.
I know that we can make the schedular service to run on each server on cluster will serve the problem,but I am looking to run the service on one server only.
I am trying to do this in 8.2 environment.

So,for this scenerio can we develop any custom service or if we can change some configuration on IS settings.

Thanks
Baharul Islam

2

are you using terracotta clustering?

3

Hi Mangat,
Currently I am not implementing anything on this,but looking for some generic implementation for the same.In my last project we have used terracotta clustering.
So,what will be step,if we use terracotta clustering.

Thanks
Baharul Islam

4

Baharul - I don’t think any built-in option available in wM8.2 and not sure in higher versions. I say, we can some custom service to achieve the same depending on wM tables which share the data among IS’s which are in cluster.

Thanks,

5

Hi,

from wM 9.x onwards there is Command Central availabla which was introduced to achieve this requirement.

wM 8.2.x uses Coherence Caching, but this has changed to Terracotta Caching in wM 9.x for sharing states between cluster members.

See the appropriates guides (esp. Clustering Guides) for details.

Regards,
Holger

6

In my humble opinion, you may be over-engineering your system a bit. Having a scheduled task to monitor your target systems so that you can suspend triggers and etc is not foolproof. It is still possible that a target system will go down before your scheduled task runs, meaning your trigger has to be capable of dealing with the failure anyway. Furthermore, even if a target system is unavailable, you may not receive any data for that system during the time that it is unavailable so why go through the hassle of suspending things that may not get executed?

Stick with things that exist out of the box such as automatic trigger retries and resource monitoring services and I’ll think you’ll be happier.

Percio