Jon's analysis looks right. I don't really understand the BaseClientHelper, but it looks as though handle() stashes the latch on the request, enqueues the response, and waits for someone to open the latch. Both handleInbound and handleOutbound have code to open the latch, but there are a lot of ways for latch.countDown *not* to be called in these methods. Seems very fragile and mysterious.
Minor nit: Maybe use a String constant for "org.restlet.engine.http.connector.latch" ? Better yet, just encapsulate the latching code to avoid all the repetition. Does this have to be done via the attributes map? Is there some compatibility problem that prevents adding a field or fields to Request for asynchronous processing purposes? Another worrisome thing: Requests and Responses now have to be thread-safe, because of asynchronous processing, but the attributes map (initialized lazily in Message) is a TreeMap, which is not thread-safe. (I doubt that this is responsible for the observed behavior, but it's still a problem.) I'm not sure what the right fix is here, because eager construction of a thread-safe map (does it really need to be sorted?) forces everyone to pay even if they don't use the attributes map (but maybe it's rare for the attributes map to go unused). But constantly dereferencing through a guarded or volatile field has its own costs. I've added a comment to the "Concurrency Issues" issue in the tracker: http://restlet.tigris.org/issues/show_bug.cgi?id=987 --tim On Wed, Mar 3, 2010 at 4:50 PM, <[email protected]> wrote: > Jerome, > > I have the same problem and am running the 2.0m7 version. I can replicate > the problem with the sample resource code, using the sample client software, > with the resources hosted within a servlet container. > > It appears that the client hangs on the Latch on the GET directly after a > PUT on the same resource. Let me know what additional information I can > provide. > > Regards, > Jon Cook > > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2454984
