Assuming the response entity is NOT pre-fetched, what about wrapping the InputRepresentation used to store the response so that release() closes the associated client socket.
Is it safe to assume that the socket is no longer needed once a user calls release() on the Response entity? On 3/23/08, Kevin Conaway <[EMAIL PROTECTED]> wrote: > > Jerome, I think you misunderstood me. I was suggesting it might be useful > to allow the client to tell Restlet to read and store the response entity to > be consumed later. > > If the response entity is read right away and stored, there would be no > need to keep the connection open and the entire request/response cycle could > be completed in short order. > > On Sun, Mar 23, 2008 at 2:28 PM, Jerome Louvel <[EMAIL PROTECTED]> > wrote: > > > > > Hi Kevin, > > > > Why not, but what would be the use case for making such a request? If a > > client application isn't interested in the entity, it can always issue a > > HEAD request. > > > > Best regards, > > Jerome > > > > > -----Message d'origine----- > > > De : Kevin Conaway [mailto:[EMAIL PROTECTED] > > > > > Envoyé : samedi 22 mars 2008 13:33 > > > À : discuss@restlet.tigris.org > > > Objet : Re: StreamClientCall and FH exhaustion > > > > > > Would it make sense to add an option to the Client or Request > > > that specifies whether Restlet should prefetch the Response > > > entity? If the response entity was prefetched, the socket > > > could be closed quite easily. > > > > > > > > > On Tue, Mar 18, 2008 at 12:42 PM, Jerome Louvel > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
