Cluster Singleton listeners

[welle]

If several ESB instances are running with the same services deployed it seems to me that some event listeners needs to be cluster-singletons. (Only active on one node at the time)

For example if you use the ScheduledListener in your service and it's deployed on several ESB in a cluster they may trigger exact at the same time and that may be a problem if you can't allow that concurrency.

One solution is to only deploy the service on one of the ESB, but then you lose the high availability of the cluster. Is there any solution for this in the ESB?

A solution could be to extend the needed listener with the following Singleton solution (based on a JGroups stack shared by all nodes) before actual triggering:

Check for a parameter to the Listener that states an integer and check that against the JGroups list of members. If the current node is the member of the location pointed by the integer then go ahead and run otherwise stop. (If the integer is greater than the length of the list just execute your standard modulo operation). This will give the possibility to spread the load on several nodes and not just on the master. (As the Application Servers singelton service does)

/Anders W.

[welle]

Hmm....

Am I the only one with this problem? Does anyone use the ESB in a clustered environment?

I really thought that we would get a discussion going about this,

/Anders W.

[tfennelly]

Hi Anders.

Sorry for not responding to the original post.

So wrt the ScheduledListeners, I think the way to make them clusterable is by making the underlying Quartz schedule jobs clusterable. I already created a JIRA for this... JBESB-1646.

As far as the other transports are concerned...

JMS Queues are clustered by nature if you configure the destinations and the JMS providers properly.
HTTP endpoints... a load balancer
FTP etc... then you might be into a shared cash type solution ala your JGroups suggestion

[welle]

Making the Quartz singleton/clustered aware should fix it for ScheduledListeners. Perhaps add a flag indicating if the listener really should be singleton or not.

Perhaps all other listeners that uses intervalls etc (for example FTP) should then extend the ScheduledListener so we get the same functionality, or?

/AW

[tfennelly]

"Welle" wrote:
Making the Quartz singleton/clustered aware should fix it for ScheduledListeners. Perhaps add a flag indicating if the listener really should be singleton or not.

I think it would be configured on the schedule instance and all schedule listeners "listening" to that schedule would then pick it up.

"Welle" wrote:
Perhaps all other listeners that uses intervalls etc (for example FTP) should then extend the ScheduledListener so we get the same functionality, or?

Now that you say it... I think they already do :-)