views:

50

answers:

1

My system consists of a "proxy" class that receives "request" packets, marshals them and sends them over the network to a server, which unmarshals them, processes, and returns some "response packet".

My "submit" method on the proxy side should block until a reply is received to the request (packets have ids for identification and referencing purposes) or until a timeout is reached.

If I was building this in early versions of Java, I would likely implement in my proxy a collection of "pending messages ids", where I would submit a message, and wait() on the corresponding id (with a timeout). When a reply was received, the handling thread would notify() on the corresponding id.

Is there a better way to achieve this using an existing library class, perhaps in java.util.concurrency?

If I went with the solution described above, what is the correct way to deal with the potential race condition where a reply arrives before wait() is invoked?

+5  A: 

The simple way would be to have a Callable that talks to the server and returns the Response.

 // does not block
 Future<Response> response = executorService.submit(makeCallable(request));

 // wait for the result (blocks)
 Response r = response.get();

Managing the request queue, assigning threads to the requests, and notifying the client code is all hidden away by the utility classes.

The level of concurrency is controlled by the executor service. Every network call blocks one thread in there.

For better concurrency, one could look into using java.nio as well (but since you are talking to same server for all requests, a fixed number of concurrent connections, maybe even just one, seems to be sufficient).

Thilo
Thank you ! Future seemed like it might be a likely candidate but I wasn't sure if that wasn't an abuse of this class. Looks like response actually has a get with timeout, so that will definitely help.
Uri