Basically what I'm asking is if I would see any problems in a class that extends Thread and implements MessageListener handling both asynch messages in onMessage and some periodic processing in run?
The 'run' code wakes up every 5 seconds, checks the status of some caches and processes according to the states before going back to sleep again. Or should I have run fire off another Runnable via scheduleWithFixedDelay from the ScheduledExecutorService?
In the Enterprise world it is better to rely on Timer services than to handle threads directly (even if it is via Executors).
If you are using EJB 3.1, you can use the @Schedule annotation to periodically run tasks. I think this works for both Session and MDBs.
If you are using EJB 3.0, you can use the timer service. The timers can be initialized programatically. This trigger can be based on user request (from a Servlet's service method which in turn invokes a Session bean method which then initializes the timer) or a message to an MDB. But a proper initiation of timer would be done via ServletContextListener (this will again invoke a Session Bean method that initializes a timer). And remember that, in this case you should also handle cancellation of the timer when application is stopped.
SCJP 1.4, OCMJEA/SCEA 5.0.
Joined: Sep 19, 2012
Sorry. I should have pointed out that I'm using ActiveMQ with POJOs. So no EJBs or app server is involved. This is also using the Spring Framework.
oh ok. I don't know much about Active MQ, but I will post some questions for you to think about:
1) How are you going to start the service? I mean, are you going to do it in your onMessage method? if so you will have to do it based on some condition. what is that condition? is that a specific message which signals you to start the service?
2) How are you going to stop the service? i.e suppose your listener is supposed to run from 8-8, then you should stop your service when the listener is stopped. You have to decide how you are going to handle this.
3) In the Enterprise world, the application server will manage the listeners...there can be more than one listener for the same queue/topic. I am not sure how it is done in your case. If there is going to be more than one listener, then potentially there is a possibility of your scheduler running at more than 1 place - may be this is far-fetched, but I think you have to think about all these...