An EAP application exposes REST APIs to create and cancel an interval timer.
Both methods belong to a stateless bean.
The scenario has been reproduced on OCP, where the mentioned app has 2 replicas, but would apply to a local cluster made of 2 standalone instances as well.

The timer creation works fine, and the timer expiration is executed by the EAP instance that receives the HTTP request.

The deletion method uses getTimers() to fetch all the timers, and then find the one which is expiring by its info.
That said though, it can happen that getTimers() is executed by the other instance, and the timer won't be deleted since it will return just the timers which are owned by the node where it's called.

This is not aligned with the current APIs semantics which shouldn't be affected by the executing environment, i.e. a timer service is one timer service, despite the number of instances that implement it in a HA environment.

Besides, the existing JDBC based persistence timer implementation follows the same principle already , i.e. it returns all the clustered timers, by querying the database (although the implementation doesn't guarantee for the result to be in sync as it is strongly affected by the timers refresh policy.

The distributed timers implementation should be aligned with the above principles as well, and getTimers() should return all the timers in a cluster.