From the JEE specification there is nothing exact defined how a timer should work in a cluster.
This behaviour has not changed since the first JBoss versions there are different strategies to persist timers, but there was never a possibility to synchronize it across several nodes.
That has changed in WildFly9, as there is a DB persistence and it is cluster aware, not optimal at the moment as I wish not all timers are loaded into the memory.
As WildFly9+ will be the base for EAP7 this feature will be available then.
As EAP6, AS7 and WildFly8 use the local filesystem to store timers it will not help to restart the servers as each server will only load it's own timers.
Thanks for your answer. It is quite a helpful information to me. But we can't wait for EAP7 available even it can solve this problem.
Maybe we will use Quartz instead of EJB3.1 Timer Service to make our schedule tasks work in the Cluster environment.
You mentioned that "As EAP6, AS7 and WildFly8 use the local filesystem to store timers it will not help to restart the servers as each server will only load it's own timers.".
Actually we use a shared filesystem to store timers instead of the local one on each Server. So when we shutdown the servers, timers' data in each node's cache will be written back to this shared timer filesystem. So when we re-start the servers,each server will load the timers from the shared timer data file instead of the local one into each server's cache and then all timers on each server are consistence.
Shared filesystem might have impacts, i.e. overwrite timers or create it duplicate.
Also you should not share other directories from data as this will not work correctly!