I want to run a job to show all of the persistent EJB3 Times that are currently scheduled
for my jboss as-7 application server.
After creating a couple of persistent Timers in the future I tried running the follownig code
from another session bean.
public void dumpTimers()
Collection<Timer> timers = timerService.getTimers();
for(Timer timer : timers)
The above code produces NO info on my scheduled Timers.
Does anyone know how I might do this?
Any help is greatly appreciated.
Have you tried query/parse the underlying timer storage? Of course its format or structure may change any time but that seems to be the quickest way to get what you want.
in EJB 3.2 there will be a TimerService.getAllTimers() to return all timers for the current ejb jar, but still won't give you all timers in the server instance.
In your code above, you could return a string representation t.getInfo(), or TimerHandler. I suppose you only need timers for view only purpose, without invoking any timer operations on them.
A Timer is a server internal Object that should not be given to an external program, also it is not usable for this. This is the reason for Timer not implement Serializable.
If you only want to have an overview you might collect a string representation with some properties (i.e. next timeout, persistent, recurring, owner, ...).
Until EJB3.2 you have to implement a Bean wich calls all known timers in your app, starting with 3.2 you might use the approach Cheng mentionend.
That sounds even better Jaikiran.
I do have a couple of more questions regarding timers.
1. If the date and time defined in a scheduleExpression of a Timer are in the past will they
be processed once the application server is started?
2. If the Timer is not explicitly canceled with the .cancel() method will the Timer continually
try and get processed if the date and time are in the past?
Thanks again for all of your help.
This Is what the EJB spec says:
Timers are persistent objects (unless explicitly created as non-persistent timers). In the event of a container crash or container shutdown, any single-event persistent timers that have expired during the intervening time before container restart must cause the corresponding timeout callback method to be invoked upon restart. Any interval persistent timers or schedule based persistent timers that have expired during the intervening time must cause the corresponding timeout callback method to be invoked at least once upon restart.
If yo add the timer via API persistent will call the timeout-method for each missing event, a non-persistent timer does not exist after server (re)start.
If you have a @Schedule annotated one a persistent timer behaviour is the same as above, a non-persistent will call the timeout-method for the next schedule, missed times are lost.