On Fri, 23 May 2008, Daniel Pitts wrote:
Mikhail Teterin wrote:
Here is the explanation... My application has to send questions to an
external service, which replies asynchronously (some questions are easier
to answer than others).
Upon submitting a question, the service's API returns a correlation ID,
which the response will also bear.
To match the received replies with the asked questions, I'm using a
Map<CorrelationID,MyObject>.
Once in a blue Moon, an answer would come back to the replies-processing
thread /before/ the questions-asking thread had the chance to finish
inserting the ID into the Map. The replies-processing thread then treated
the reply as "unsolicited", etc.
You should look into Executors and Callable and Futures.
You can keep track of Future values, ones that you expect to have a value
for eventually.
I don't think there's any way to use a future, a callable, or an executor
to beat the race condition here. Those would be useful if the problem was
to do with an answer-demanding thread getting to the map before an
answer-supplying thread: you could use futures as a way of giving the
demanding thread a promise of an answer some time in the future.
But that isn't what the problem is. The problem is the other way round: the
answer-handling thread demands questions from the map, so it can send
answers to them, but it's possible for that thread to beat the
question-supplying thread there. This is despite the fact that the
question-supplying thread goes to the map as soon as it's sent the question
over the wire - it's a simple race condition.
[snip]
I've thought of another solution: make the map sort of bidirectional (and
not typesafe). If the questioning thread gets there first, stash the
question; if the answering thread gets there first, stash the answer. Both
threads have to be prepared to deal with the job of reuniting a question
and an answer. You could use a normal map for this, and lock on every
get-test-put sequence, but a more scalable approach would be to use a
ConcurrentMap and its putIfAbsent method: the questioner does:
Question q = ... ;
Answer a = (Answer)map.putIfAbsent(correlationId, q) ;
if (a != null) reunite(q, a) ;
And the answerer does:
Answer a = ... ;
Question q = (Question)map.putIfAbsent(correlationId, q) ;
if (q != null) reunite(q, a) ;
I think I see the situation a little better now...