Hi Eric, I've fixed several internal connector issues today and vastly improved their performance using proper IO buffering. I suggest that you try a recent snapshot when you have a chance next week. It will certainly work better and faster! 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 : Eric Lui [mailto:[EMAIL PROTECTED] Envoyé : mardi 12 août 2008 22:28 À : [email protected] Objet : Re: release() method - doesn't appear to release connections? Using httpclient explicitly, instead of through restlet.Client, resolved the problem. (Simple remained the same.) This meant constructing our own MultiThreadedHttpConnectionManager, passing it around via context attributes, and explicitly requesting HttpMethod objects, instead of relying on Restlet's Client() class to handle connections using the Request/Response framework. On Tue, Aug 12, 2008 at 1:06 PM, Kevin Conaway <[EMAIL PROTECTED]> wrote: I thought you said that using httpclient+simple resolved the problem? On Tue, Aug 12, 2008 at 12:56 PM, Eric Lui <[EMAIL PROTECTED]> wrote: Unfortunately, we've moved past that revision and are steaming ahead toward an imminent release date. I'll look at what i can do in about a week. The issue occurred with: Restlet Client connector backed by httpclient-3.0.1 Restlet Server connector backed by Simple web server. On Mon, Aug 11, 2008 at 4:42 PM, Kevin Conaway <[EMAIL PROTECTED]> wrote: Can you post a thread dump of the system when the code is blocked? Which client + server connectors were you using when this issue occurred? On Wed, Aug 6, 2008 at 10:41 PM, Eric Lui <[EMAIL PROTECTED]> wrote: I'm new to the world of Restlet, but i'm finding it a really expressive framework. I have an application which sends POST requests to a Restlet server using the Restlet Client library, using threads for each POST request. Upon sending the third request, the thread will block indefinitely. It seems the previous requests never release the connection back to the pool, even though I am explicitly calling release() in my finally block: try { System.out.println("connection # " + ++count); response = client.handle(request); status = response.getStatus(); text = response.getEntity().getText(); // should close the representation } catch (IOException e) { throw new RuntimeException (e); } finally { response.getEntity().release(); } If I adjust maxConnectionsPerHost, the number of requests before blocking goes up by the same amount. What am I doing wrong? Is there another step to make sure the representation is completely read and released? -- Eric -- Eric -- Eric
