Are you using aspectj at all? I've seen aspectj and log4j deadlock in certain cases.
On Fri, Aug 8, 2008 at 1:11 PM, Aaron Crow <[EMAIL PROTECTED]> wrote: > It turns out that the connection problem was a symptom and not a root > cause. The root cause seems to have something to do with our use of log4j... > it seems to > cause hanging, perhaps due to deadlocks. For now we've turned off file > logging via log4j. We're going to experiment with log4j's asyncappender to > see if that's a better workaround. > > > "Aaron Crow" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > We're having a serious issue with entity.getText(), where it often hangs >> for a second or so, then completes but with missing content. >> >> We have written a proxy service which takes POST requests and hands them >> off to Resources attached to our REST Application. >> The resources generate new Request objects and uses the client.handle() >> method to send essentially the same Request to one or more feeder servers. >> The feeder servers are reading data off of disk, and then returning it in a >> string format as the content of the response. >> >> The resources generate the clients as Runnable objects, which are handed >> to new Threads to execute. >> >> As part of the run() method in the threads, we start up new Threads which >> call entity.getText() for every Response object coming back from >> client.handle. We are under the impression this should satisfy the >> requirement to "read entirely each response". ( >> http://www.restlet.org/documentation/1.0/connectors#httpclient ) It's >> not our preference to start a new thread for every getText() request, but >> requests against response objects without Entity text take about 1 second to >> process, which seems tied to a global timeout for an empty input stream >> defined somewhere. That 1 second is too long for our performance needs. >> >> When using curl or other applications, the first request of this nature >> goes in and comes back out correctly, returning the expected content. >> >> The second request blocks.[1] In particular, it blocks in the middle of >> client.handle(): >> httpClientCall:437 >> >> // Now we can access the status code, this MUST happen after >> closing >> // any open request stream. >> result = new Status(getStatusCode(), null, >> getReasonPhrase(), null); >> >> >> If the application blocks on a request in this way, it will try to sit >> until the readTimeout expires. At that point, it gives up and sends a >> request to the waiting application on the other side. However, that request >> does not have the POST content-- only the resourceUrl, etc. It is entirely >> driven by this readTimeout-- adjusting readTimeout directly impacts the wait >> time. >> >> We've tried increasing maxConnectionsPerHost and maxTotalConnections for >> the context, but it does not seem to impact performance or behavior. >> >> Significant (or not), the proxy service handles GET requests without >> experiencing this blocking problem. Only POSTS seem to cause the problem. >> >> Also, JUnit tests do not reproduce this problem. However, we are using >> the Restlet Client library to make these connections, so maybe there is a >> connection pooling benefit derived here? >> >> We are currently using restlet and noelios 1.0.7. Upgrades to 1.0.10 and >> 1.1.M4 have not resolved the problem. (we even added entity.release() after >> entity.getText() in the 1.1M4 version of our code) >> >> The feeder servers are also running a Restlet application, and can be >> polled at very high levels of activity without noticeable problems. We >> don't think it's related to the feeder server behavior. >> >> [1] If there is a delay greater than the readTimeout parameter ( >> http://osdir.com/ml/java.restlet/2007-04/msg00026.html ) before the 2nd >> request, the request runs fine. >> >> Anyone have any experience with this or any idea how to resolve the issue? >> >> Many many thanks in advance for any advice... this is really holding us >> back... >> >> >> Best wishes, >> Aaron >> >> >> > >
