Hi Sanjay, I can confirm that Client instances have been designed to be reused concurrently by several threads. The code should be thread-safe (I've just fixed the issue Tim noticed). But, nothing prevents you from having several instances of them if that makes sense, for example for configuration purpose as pointed out by Stephan Koops. In your code snippet, what is missing is a call to c.stop() to make sure that your connector is stopped and any resource used is freed. You could also explicitly do a c.start() by this is done implicitly when the requests is handled. 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é : jeudi 16 octobre 2008 04:55 À : [email protected] Objet : Re: Assistance and Question I think Client is intended to be thread-safe, but it isn't currently, because the connectTimeout field is not guarded by a lock (nor is it volatile) -- sorry Jerome, I just noticed this. This is not likely to cause any problems, but it *is* wrong. And there may be other concurrency issues lurking in Client. My feeling is better safe than sorry. If you really need to have multiple threads talking to a Client instance -- and it's not clear to me that you do -- use a ThreadLocal<Client>. It might be unnecessary, but it limits the number of open file handles to some small factor of the number of threads talking to Clients simultaneously. --tim On Wed, Oct 15, 2008 at 10:14 PM, Sanjay Acharya <[EMAIL PROTECTED]> wrote: Hi Jerome, I believe I have found the cause of our problem. We use Restlet Client by instantiating it every time, for example, for (int i = 0; i < 10000000; i++) { Client c = new Client(); .... Response response = c.handle(request); response.release(); } we end up creating a downstream HttpClient on every client. When release() is called, the socket connection is released back to the HttpConnectionManager. HttpConnectionManager does not close the socket. However, due to garbage collection, at some point the underlying socket is closed out. It happens some times and not others, i.e., via the luck of GC running. If we however, hold a Reference of every client that is instantiated, then we can easily reproduce the open file handle issue as GC will not free the underlying socket and we can see eventually reach a point where all the available file handles are consumed. That said, the direction of preference seems to point to using a single instance of Restlet's Client class and setting the "maxConnectionsPerHost" to some appropriate value. One concern that I have is whether Restlet's Client is designed to be thread safe so that multiple threads can utilize the same instance? In other words, is singleton usage the recommended pattern for using the client? Thanks much, Sanjay _____ > From: [EMAIL PROTECTED] > To: [email protected] > Date: Wed, 15 Oct 2008 08:46:06 +0200 > Subject: RE: Assistance and Question > > > Hi Sanjay, > > As a first step, I would highly recommend moving to 1.1 RC2 or a more recent > snapshot. There is a good chance that it will fix your issue. > > If not, we'll investigate more. > > Best regards, > Jérôme Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > > -----Message d'origine----- > De : Sanjay Acharya [mailto:[EMAIL PROTECTED] > Envoyé : mercredi 15 octobre 2008 02:39 > À : [email protected] > Objet : Assistance and Question > > > Hi, > > I am using Restlet version 1.1 m1. There are times when we run out of open > file handles in stage environment with "too many open file handles" error. I > am also using the JaxbRepresentation to marshall the data. > I am trying to recreate the issue related to > http://restlet.tigris.org/issues/show_bug.cgi?id=439 and not sure how to do > the same. I would like to be able to recreate a state where connections are > left in > "CLOSE_WAIT and FIN_WAIT_2 state" by the client. > > I have limited the number of open file handles to 200 for the user. > > Any assistance to be able to duplicate the issue would be great. > Thanks, > Sanjay > > Code on Resource class: > @Override public void post(Representation representation) { > > String greeting = "Hello thgere"; > > Person p = new Person(); > p.setFirstName("Foo"); > p.setLastName("Bar"); > > // A Large address list > p.setAddresses(buildAddress()); > SayHelloResponse resp = new > SayHelloResponse().withPerson(p).withGreeting(greeting); > > JaxbRepresentation responseRep = new > JaxbRepresentation(MediaType.APPLICATION_XML, resp); > > getResponse().setEntity(responseRep); > > getResponse().setStatus(Status.SUCCESS_OK); > } > > Code on Client class: > Person p = new Person().... > .... > SayHelloRequest sayHelloRequest = new SayHelloRequest().withPerson(person); > > Request restRequest = createRequest(); > request.setEntity(new JaxbRepresentation(MediaType.APPLICATION_XML, > sayHelloRequest)); > Response response = client.handle(restRequest); > response.getEntity().release(); > _________________________________________________________________ > See how Windows connects the people, information, and fun that are part of > your life. > http://clk.atdmt.com/MRT/go/msnnkwxp1020093175mrt/direct/01/= > _____ Want to do more with Windows Live? Learn "10 hidden secrets" from Jamie. Learn Now <http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns%2 1550F681DAD532637%215295.entry?ocid=TXT_TAGLM_WL_domore_092008>
