Hi,
In an application deployed on an App Server (iPlanet 6.0SP4), I need to trigger a request from time to time.
Well, as something like an "infinite loop" running in the app server is not really great, is there something like a timer mechanism etc in the J2EE world. to whom I can subscribe and who'd wake up the app let's say every 10 secs or so.
Or any other idea?
Thanks,
Wolfgang
-
Timer in J2EE? (7 messages)
- Posted by: Wolfgang Sporer
- Posted on: September 30 2002 11:51 EDT
Threaded Messages (7)
- Timer in J2EE? by Ahmed Talaat on September 30 2002 16:35 EDT
- Timer in J2EE? by Burak AKSOY on October 01 2002 01:08 EDT
-
Timer in J2EE? by Ahmed Talaat on October 01 2002 09:32 EDT
- Timer in J2EE? by Pranab Ghosh on October 10 2002 10:35 EDT
-
Timer in J2EE? by Ahmed Talaat on October 01 2002 09:32 EDT
- Timer in J2EE? by Burak AKSOY on October 01 2002 01:08 EDT
- Timer in J2EE? by Sean Sullivan on October 01 2002 12:43 EDT
- Timer in J2EE? by Tomas Inger on October 04 2002 11:14 EDT
- Timer in J2EE? by Dieter Cailliau on October 11 2002 10:09 EDT
-
Timer in J2EE?[ Go to top ]
- Posted by: Ahmed Talaat
- Posted on: September 30 2002 16:35 EDT
- in response to Wolfgang Sporer
Have you thought of MDBs ? Some deamon outside of the appserver pushing JMS messages on a queue that triggers an MDB in your J2EE app ? Would that do the job in your case ?
-
Timer in J2EE?[ Go to top ]
- Posted by: Burak AKSOY
- Posted on: October 01 2002 01:08 EDT
- in response to Ahmed Talaat
We also needed that funcstionality and used threads which are performing perfect till now. -
Timer in J2EE?[ Go to top ]
- Posted by: Ahmed Talaat
- Posted on: October 01 2002 09:32 EDT
- in response to Burak AKSOY
according to the specs you should not be doing that too. I'm not saying that we should follow the specs blindly even if we have very good reasons not to, but I guess this should be a last resort sort of thing. -
Timer in J2EE?[ Go to top ]
- Posted by: Pranab Ghosh
- Posted on: October 10 2002 22:35 EDT
- in response to Ahmed Talaat
I don't think it should be taken literally. The intent of the spec is that the J2EE container takes no resposibility for managing your thread. As long as you manage your thread
properly and shut it down before the server shutdown, there should not be a problem. I have used a java Timer object which spawns it's own thread, wrapped in JMX bean without any problem at all.
Pranab -
Timer in J2EE?[ Go to top ]
- Posted by: Sean Sullivan
- Posted on: October 01 2002 12:43 EDT
- in response to Wolfgang Sporer
EJB 2.1 has a Timer service
http://www.onjava.com/pub/a/onjava/2002/08/14/ejb21.html?page=last
javax.ejb.TimerService
javax.ejb.Timer
See also:
Job schedulers
http://www.theserverside.com/resources/article.jsp?l=Job-Scheduling-In-J2EE-Applications
http://sourceforge.net/projects/quartz/
http://clockwork.sourceforge.net/
http://www.simscomputing.com/products/flux/
-
Timer in J2EE?[ Go to top ]
- Posted by: Tomas Inger
- Posted on: October 04 2002 11:14 EDT
- in response to Wolfgang Sporer
Hi!
For now, I recommend a deamon outside the EJB container. That deamon can work in two ways:
1. Call a Stateless SessionBean.
2. Put a message in a queue. Then you have to write a MessageDriven Bean to take care of the message.
If you do not have a message queue in the architecture today, I strongly recommend the first solution.
When you migrate to EJB 2.1, you should change the inplementation to Timer Service (new feature), and I recommend you to prepare the code for that change now. (Means: Do not do all the stuff in onMessage method.)
/Tomas -
Timer in J2EE?[ Go to top ]
- Posted by: Dieter Cailliau
- Posted on: October 11 2002 10:09 EDT
- in response to Wolfgang Sporer
sometimes you don't really need an acurate timer; if you need a kind of monitoring thread watching for special things periodically:
i wrote a thing with the same interface as java.util.Timer, and re-implemented the functionality, without spawning a new thread. In stead i just added a run() method which should be called "frequently", and i put my object somewhere global (static).
Next, every ejb that needs the timer can shedule tasks with that central timer, and every ejb that does, is also responsible for calling run() on that central timer.
I used this trick to sweep a cache when memory is running low. I call run() whenever a new entry is about to be calculated and put in the cache.
The frequent calls to timer.run() are no real overhead because the timer does not need to check every time it's runned, because it can remember it's own last execution and the shortest period of all its periodic tasks.