I’m having a hard time figuring out how to architect the final piece of my system. Currently I’m running a Tomcat server that has a servlet that responds to client requests. Each request in turn adds a processing message to an asynchronous queue (I’ll probably be using JMS via Spring or more likely Amazon SQS).
The sequence of events is this:
Sending side:
1. Take a client request
2. Add some data into a DB related to this request with a unique ID
3. Add a message object representing this request to the message queue
Receiving side:
1. Pull a new message object from the queue
2. Unwrap the object and grab some information from a web site based on information contained in the msg object.
3. Send an email alert
4. update my DB row (same unique ID) with the information that operation was completed for this request.
I’m having a hard figuring out how to properly deal with the receiving side. On one hand I can probably create a simple java program that I kick off from the command line that picks each item in the queue and processes it. Is that safe? Does it make more sense to have that program running as another thread inside the Tomcat container? I will not want to do this serially, meaning the receiving end should be able to process several objects at a time — using multiple threads. I want this to be always running, 24 hours a day.
What are some options for building the receiving side?
‘On one hand I can probably create a simple java program that I kick off from the command line that picks each item in the queue and processes it. Is that safe?’
What’s unsafe about it? It works great.
‘Does it make more sense to have that program running as another thread inside the Tomcat container?’
Only if Tomcat has a lot of free time to handle background processing. Often, this is the case — you have free time to do this kind of processing.
However, threads aren’t optimal. Threads share common I/O resources, and your background thread may slow down the front-end.
Better is to have a JMS queue between the ‘port 80’ front-end, and a separate backend process. The back-end process starts, connects to the queue, fetches and executes the requests. The backend process can (if necessary) be multi-threaded.