The distributed timer service does not handle server suspension correctly. The scheduler mechanism (i.e. org.wildfly.clustering.server.scheduler.Scheduler) runs and timers are scheduled to fire even when the server is suspended. While timer invocation is prevented while the server is suspended, the fact that the timer service is effectively running while the server is suspended creates some problems.
In the distributed timer service case, a suspended server will still own cache segments, and thus will prevent successful invocation of persistent timers that could be handled by another cluster member. Additionally, the timer service consumes CPU unnecessarily while the server is suspended.

For the distributed timer service, we want a suspended server to own no segments. We can achieve this by configuring the cache with a zero capacity. On resume, we restart the cache with its default capacity. No actual change to the timer service itself should be required.
This strategy has the advantage of handling other cases as well. For example, a suspended server should also not own any web sessions (scheduling them for expiration, etc).