Hi,
I know that the developers of this project are very busy and don't mean to
intrude. I'm tasked with finding why a problem is occurring in an
application of ours and haven't been having very much luck with it. We are
still using HttpClient 3.0.1 and encounter a problem where after a few days
to a week of making HttpClient connections to an SSL site, the application
container will be working fine and then suddenly the response times will get
longer and longer, then they will go through the roof and the application
will stop responding completely until it's restarted. From what I
understand, a few other people where I work who have looked at this problem
have used profiling tools to narrow down where the problem is happening to
HttpClient but they aren't sure why it is happening.
I saw there is a bug HTTPClient-675 that was fixed by Roland Weber in
version 3.1. It talks about thread-starving in the
MultiThreadedHttpConnectionManager and made me wonder if we were seeing
something similar occurring. I emailed Roland and asked if he might know a
test case in 3.0.1 that would cause this problem to occur. He replied back
and stated that he is no longer on the project and hasn't been involved for
a year, but that I should email the developer mailing list to see if anyone
might know.
The suspected code isn't doing anything complicated, it just looks like
this:
HttpClient client = new HttpClient();
PostMethod post = new PostMethod(inUrl);
post.setRequestEntity(new StringRequestEntity(inPayload, null,
null));
int statusCode = client.executeMethod(post);
log.debug(new StringBuilder("inUrl=").append(inUrl).append(",
inPayload=")
.append(inPayload).append(", statusCode=")
.append(statusCode).toString());
String payload = readPayload(post);
return payload;
The readPayload method just uses post.getResponseBodyAsStream and a
BufferedReader to read the response.
The BufferedReader is then closed in a finally block.
If anyone might know how to reproduce that issue or has any thoughts on what
might be happening I'd appreciate it. The ultimate goal is to be able to
get it to happen with just the isolated code sample, try an upgraded jar
file and if the problem doesn't happen after the upgrade then we could move
forward with doing an upgrade to the jar in Production to see if this
problem goes away. I've been using JMeter to simulate the calls that were
being made but haven't had much luck with it and i've been working at this
problem for a few weeks and looking on newsgroups for people who might be
having similar problems without much luck.
Sincerely,
David Hamilton
