I want to process some very long running tasks using MDBs (hours), but MDBs are backed by JMS, which has some timeout (about 10 minutes in tomEE I think).
To make things worse, jobs are persistent too.
Since I can't catch the timeout exception on the MDB (can I?), I was considering the option of manually deal with the JMS consumer. Manually dealing with it can be done in two ways: synchronously or asynchronously.
Asynchronously I'll fall back to a stateless bean that implements MessageListener, and then I'll just not be able to treat the timeout again.
Synchronously, I guess, I can deal with the timeout in the catch block, but then, how can I implement a pool of instances/workers/whatever inside TomEE+ that are listening to a queue, waiting for a job to process? (remember, timeout here is not the time to wait for a message to appear in the queue, but the time to execute the long running task)
Why don't you fork off the long running process to a separate object ? > If there's a way to control the pool size of these separate objects, it could be a way. Do you want to try an answer? :-)
You do not want an uncontrolled object growth over time ? Hmmm...I can see where you are going with that.
The only thing I can think of is use a FixedThreadPool from the concurrent framework. Spawn a thread for executing the long running task and ensure that the MDB returns immediately after handing over the work. Keep the thread pools controlled by profiling your application in a test environment.
Application servers like Weblogic and Websphere give you sophisticated frameworks like WorkManager for such tasks.