File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Threads and Synchronization and the fly likes Wait, notify alternative Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Wait, notify alternative" Watch "Wait, notify alternative" New topic
Author

Wait, notify alternative

Taariq San
Ranch Hand

Joined: Nov 20, 2007
Posts: 192
Hi

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.

Any hints are welcome.
Taariq
Chris Hurst
Ranch Hand

Joined: Oct 26, 2003
Posts: 416
    
    2

Could it return a java.util.concurrent.FutureTask and then your caller can use its methods to determine completion eg get () or something fancier as required ? (no wait notify then ?)


"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18715
    
  40


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.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Taariq San
Ranch Hand

Joined: Nov 20, 2007
Posts: 192
...deleted
Taariq San
Ranch Hand

Joined: Nov 20, 2007
Posts: 192
Good stuff, thanks to you both.

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?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Wait, notify alternative