Hi Tim, Thanks for checking this part of the code. I've just fixed all the points you have reported in SVN trunk. Regarding the last point you mentioned, I've entered a RFE: "Handlers don't nest consistently when setting current objects" http://restlet.tigris.org/issues/show_bug.cgi?id=621 If you or Leigh could add more details and eventually a patch in the comments of the RFE, that would help fixing any issue in this area before 1.1 release. Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder ~ <http://www.noelios.com/> http://www.noelios.com
_____ De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Tim Peierls Envoyé : vendredi 17 octobre 2008 05:16 À : [email protected] Objet : Re: Assistance and Question On Thu, Oct 16, 2008 at 4:57 PM, Rob Heittman <[EMAIL PROTECTED]> wrote: Pragmatically, our applications do reuse Client instances in production code and have not had any trouble with this. It's meant to be thread safe. Tim points out a valid thread safety issue, but it's not likely to cause you harm and will probably be corrected eventually. While I was looking to see if there were any obvious serious thread-safety issues in Client and friends, I noticed a few minor things that should probably be fixed: * ConnectorHelper has volatile field protocols, which could and should be final. * ConnectorHelper start/stop both have useless synchronized keywords. * ClientHelper.connectTimeout is neither guarded by a lock nor volatile (similar to connectTimeout in Client). On a related note, Leigh Klotz pointed out privately to me that the handlers that set the current request, response, and context don't nest consistently, and there is a potential for memory leaks. The documentation says not to rely to heavily on the static getCurrent() methods, so maybe it's my own fault for writing the Guice FinderFactoryModule in terms of them, but the possibility of a memory leak is worth checking out. --tim
