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), but - 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, Norbert -----Ursprüngliche Nachricht----- Von: Jay D. McHugh [mailto:jaydmch...@gmail.com] Gesendet: Freitag, 2. Oktober 2009 22:51 An: user@geronimo.apache.org Betreff: Re: Persistence Issue on Timers - Geronimo 2.1.4 / EJB 3 Norbert, It -seems- as though shutting down Geronimo 'effectively undeploys' my app. Then, bringing Geronimo 'effectively redeploys and starts' the app again. 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: https://issues.apache.org/jira/browse/GERONIMO-4901 Thanks, Jay 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 timers.https://issues.apache.org/jira/browse/GERONIMO-4901 > > 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, >>> >>> were using Geronimos 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 if >>> >>> - the bean is redeployed >>> - Geronimo is shutting down >> I'm not sure how the current timer persistence works but... I'd expect that >> - 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 timers 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
