Hi all, The client should indeed make sure it either consumes the response entity (via getText(), getStream(), etc.) or that it calls the release() method.
Otherwise, there indeed seem to be a bug related to the keep alive connections not being closed (after a given timeout?). We have a bug report pending: http://restlet.tigris.org/issues/show_bug.cgi?id=439 We hope to have that fixed in 1.1 M3 at the end of the month. Best regards, Jerome > -----Message d'origine----- > De : Kevin Conaway [mailto:[EMAIL PROTECTED] > Envoyé : mardi 18 mars 2008 00:36 > À : discuss@restlet.tigris.org > Objet : Re: StreamClientCall and FH exhaustion > > Its my understanding that the socket can't be automatically > closed by Restlet because the response entity body isn't > ready until the caller decides to access it. > > If this is correct, I think its up the client to some how > alert the Client or the Response that he is through with the entity > > > On Mon, Mar 17, 2008 at 7:20 PM, Matt Reynolds > <[EMAIL PROTECTED]> wrote: > > > I have a question around the StreamClientCall code and > socket use. > > The setup : > We're using a single client (org.restlet.Client) > instance through a > number of threads (more than 10 or so), and calling a > service repeatedly > that has a 50ms round-trip time. We're using M1 > (moving to M2, but more > on that later). > > The symptoms : > During a performance test, after 20 minutes or so, we > run out of file > handles. We used lsof and /proc to isolate the number > of handles used, > and noticed they're mostly sockets. > > I created a small test harness around our usage of > Client to see what > happens. When I run this client very fast (30 threads, > no waiting), I > can reproduce the problem in less than 10 seconds (on > my local linux > machine, albeit not the same). > > Anyway, the exception thrown comes through > StreamClientCall.createSocket:80/sendRequest:211 . In > that code, I > notice that the socket is created, but never closed. > Following the code > paths, I notice that an OutputStream and InputStream > and "gotten" and > passed around to other methods, that end up calling OS.close and > IS.close. However, the code paths appear to be calling > close on the > wrapper instances of the OS/IS, either > ChunkedOutputStream(which doesn't > call the > destination.close)/KeepAliveOutputStream(which, seemingly > obviously, has no close) or ChunkedInputStream(no underlying > close)/InputEntityStream(same). > > So, it simply appears that the Client socket isn't > being closed. I'm > guessing it should be closed as part of the finally > block, with a null > check and then a call to isClosed? Anyway, please let > me know if I > debugged this path correctly and, if possible, what I > should do to get > around this. > > Thanks, > Matt > > > >
