No currently using aspectj, but that's bad news about the deadlock risk. I was
considering using it later on for various things... :-(
"Kevin Conaway" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
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
