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?
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 ?
We also needed that funcstionality and used threads which are performing perfect till now.
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.
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.
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.)
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.