I'm still in the scribbling phase, haven't implemented any of the following yet so
if there's a better way of doing things please advise.
We'll have a cluster of JVMs receiving JMS messages, the sender expects a response, eventually.
Halfway through the message processing we'll get a distributed lock from a cache to be able to do some
batch processing of these messages, and send the message off to the batch processing code.
So in effect there's only ever one JVM sending out batches at any given time.
The response will not be immediate, but eventually as I said the JMS consumer should send
back a response based on whatever happens in that batching process.
Now the title says "Wait, notify alternative", because one of the solutions I thought of is
to have the batching process expose a public method that returns the result, but keeps the
calling thread waiting until some other process is done with the batch that includes the caller's message,
then obviously returns the result. It could sync on some object and wait for a notify,
then check if it's message has been processed.
I'm looking through the concurrency package and other sources to see if there's something efficient to help out,
as this is expected to scale to deal with at least a million such messages per day and that batching process
is always going to be a singleton due to the nature of the business.
Agreed. There are higher level concurrency classes -- that hide all the synchronization and wait notify details. Take a look at the Callable interface for a runnable that returns stuff. Take a look at ExecutorService for implementation of thread pools, that uses Callable, and hides the thread creation details. And as already mentioned, take a look at the Future stuff for getting the results from the callable to the thread that needs the result.
I've been reading the docs and fiddling with some code and just want to check I understand correctly.
At this point I don't yet see how it's going to work, so a little patience please.
Hang on, I just found that Spring provides a ThreadPoolTaskExecutor, so I'll use that to return the Future to the calling client, which will obviously hang on the get() until it's response is available.
The business of getting that response after it's been put into the collection for processing brings me back to the wait and notify scenario
to get the response out of the outgoing collection, so please ignore the previous post and let me know if you have something in mind to replace that wait/notify on the outgoing collection.
I'm looking around in the locks package, so I can perhaps have an exclusive write lock and a lot of concurrent reads until the response is there?