active-active quickstart cluster-ha-singleton

[jjfraney]

I'm struggling with the following.  I will explain using the cluster-ha-singleton as a base.

The timer in this quickstart is predefined, or can be read from the database.  I understand how this clearly operates well in a active-passive context.  When the ha-singleton becomes active it reads persistent state while starting.  Then, what about active-active where there is a failure of a server without reactivation of the ha-singleton?

Lets say there are two servers, A and B, both active, and the ha-cluster timer, as designed in the quickstart, is bound in server A.  Then, a future firing is requested by a bean in server B, and server B promptly dies.  The ha-singleton does not undergo re-activation because server A did not fail.  How does the scheduled firing propagate to server A?

Thanks.

[wdfink]

From the design the ha-singleton use local beans to start timers.

If the server fail the beans are dead also. If the server is shutting down the singleton will remove the timers.

If two clusters are merged one ha-singleton will be stopped and remove it's timers.

If you implement a remote access you need to ensure that the same remote bean will be used and the impelemtation check that there is no double start.

[jjfraney]

Wolf-Dieter Fink wrote:

From the design the ha-singleton use local beans to start timers.

If the server fail the beans are dead also. If the server is shutting down the singleton will remove the timers.

Yes. I understand this much....I'm not sure how it helps me build a solution to my question.

Wolf-Dieter Fink wrote:

If two clusters are merged one ha-singleton will be stopped and remove it's timers.

No.  Merging two clusters is not my intended use case.

Wolf-Dieter Fink wrote:

If you implement a remote access you need to ensure that the same remote bean will be used and the impelemtation check that there is no double start.

I think you are saying I have the option of implementing the ha singleton timer bean as a remote ejb (@Remote).  Exactly what I was thinking.

I intend to use the ha-singleton pattern, as you put forth in the quickstart, to avoid the double start, of course.

How would I "ensure that the same remote bean will be used"?  Does a jndi lookup return a reference to the live remote bean?  If the ha-timer was bound to server A, can the app in server B do a jndi lookup to get a reference to it?

Lets say server A and B are both running, with a clustered app that includes an ha-singleton timer.  Server B processes a users request that requires a timer, and because the singleton is deployed and running in A, server B must send a message to the remote bean singleton in A.  How does server B get a reference to the remote bean in server A?  With JNDI, right?  If so, do I have to provide the ip address of server A into initial context? or is the naming directory also somehow upto date with the location of the bean?  IF the former (providing the ip address in the initial context), how can the application get the ip address of the server where the ha-singleton is currently running?

Thanks,

John

[wdfink]

The ha-singleton is not designed for that, it is only for scheduled timers which are configured and run on the same server.

What you mean is a cluster aware ejb-timer.

This is not implemented at the moment. There are JIRA issues for that you might vote/watch it

[WFLY-283] EJB timers in cluster and failover support

[WFLY-285] Add clustered database based timers