geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norbert Rieger" <>
Subject AW: Persistence Issue on Timers - Geronimo 2.1.4 / EJB 3
Date Sat, 03 Oct 2009 11:53:57 GMT
Hi Jay,

thanks a lot for reproducing the described behaviour/failure and adding the
JIRA entry.

I will describe the behaviour I've expected:

- undeploying the ejb will destroy associated timers (timer without callback
makes not sense), 
- redeploying (e.g. after a little bug fix) should maintain timers (this
means redeploy is different from undeploy + deploy)

- shutting down/crashing app server should never destory pending timers (see
your JIRA issue)

This is how we use timers:

We are using Timer Service to delete data from a database after a specified
period of time (we have to hold them e.g. for at least 24h).
We have and we don't wanna have cyclic processes for polling database
tables, etc.

If an entry was marked for deletion, we establish a new timer (e.g. now +
24h), which will delete this entry (and all related entries....) .

Currently we loose timers if geronimo restart or the application/ejb is
redeployed (which happens frequently during application tests).
As an result, the database entries will never be deleted automatically. 

As a workaround we can establish all the timers on the application startup
by scanning the database for marked entries.

Maybe we are using Timer Service in a way it was never supposed to be ?

Is there another mechanism for delayed processing of data within EJB (e.g
JMS with delayed delivery) ?

Thanks a lot for your help and assistance,


-----Ursprüngliche Nachricht-----
Von: Jay D. McHugh [] 
Gesendet: Freitag, 2. Oktober 2009 22:51
Betreff: Re: Persistence Issue on Timers - Geronimo 2.1.4 / EJB 3


It -seems- as though shutting down Geronimo 'effectively undeploys' my
app.  Then, bringing Geronimo 'effectively redeploys and starts' the app

The expected behavior for undeploy/redeploy would be to drop all of the
timers.  So that is probably why the timers are going away.

But, shutting down the server (however we are actually implementing it)
should not kill pending timers.  So, this is a bug.

Please add any additional information you can to the JIRA:



Jay D. McHugh wrote:
> Hey David and Norbert,
> I have been using timers in Geronimo for a while - but, I have not been
> using long running timers.  Instead, I have been using them as a way to
> get processes to run in the background.
> So, I have not ever needed to shut down the server while there were
> active timers running.  But, just for fun, I tried doing exactly that
> just now and it appears that Norbert is right - Shutting down Geronimo
> seems to destroy the
> I am trying to double check that this is actually what is happening.
> If it is, then we need to get a JIRA filed for it.
> Jay
> David Jencks wrote:
>> On Oct 2, 2009, at 1:45 AM, Norbert Rieger wrote:
>>> Hi,
>>> we’re using Geronimo’s Timer Service with one of our SLSBs (using
>>> @Timeout annotation).
>>> As described in the specs the timers are persistent – or should be.
>>> But in our environment/application it seems that the timers are dropped
>>> -      the bean is redeployed
>>> -      Geronimo is shutting down
>> I'm not sure how the current timer persistence works but... I'd expect
>> - redeploy would eliminate the timers from the original app and set up
>> new timers for the redeployed app.  I don't see any other reasonable
>> behavior, since there's no reason to suppose the 2 versions of the app
>> have the same timers.
>> - shutting down geronimo would turn off the timers until either geronimo
>> or the app is restarted, at which time you'd start getting new timeouts.
>> I'm not sure exactly what behavior you expect, could you explain in more
>> detail?
>>> Are persistent timers the default behaviour within Geronimo, or must
>>> this be turned on (xml config e.g.) ?
>> there's no way to modify this by configuration.
>>> Is there a configuration file for timer‘s persistence configuration ?
>> I don't think so, but I'm not certain of how they are persisted at the
>> moment.
>> thanks
>> david jencks
>>> Thanks a lot for your help.
>>> Many Greetings
>>> NR

View raw message