• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Wait, notify alternative

 
Taariq San
Ranch Hand
Posts: 192
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 443
3
C++ Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ?)
 
Henry Wong
author
Marshal
Pie
Posts: 21010
77
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
 
Taariq San
Ranch Hand
Posts: 192
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
...deleted
 
Taariq San
Ranch Hand
Posts: 192
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic