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
