RE: Pool running out of connections
Hello, Thanks for your response. I suppose that this eviction policy that you are saying is achieved by using IdleConnectionTimeoutThread. Am I right? Joan. -Mensaje original- De: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Enviado el: miércoles, 16 de julio de 2008 18:03 Para: HttpClient User Discussion Asunto: Re: Pool running out of connections On Wed, 2008-07-16 at 09:03 +0200, Joan Balagueró wrote: Hello, We have developed software that uses HttpClient 3.1. It has been working for 2 months. Recently though, we have been getting 'Maximum number of simultaneous requests exceeded' errors. We are using a multi-threaded pool with 100 connections. Our application never has more than 10 simultaneous requests. The error is Socked closed. These connections were established on the 14th of July. The shutdown was done on the 15th of July (in other words, these connections were open for more than a day). What we don't understand is how it is possible that these connections can be open for so long when they have a timeout of 26 seconds (which we assign in the PostMethod). Socket timeout applies to _active_ read operations only. Idle connections cannot time out, as they are not blocked in a read operation. You should implement an eviction policy to close connections that have been idle for too long. Hope this helps Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient invalidates session
On Wed, 2008-07-16 at 16:18 -0700, Leena Borle wrote:
Hi,
I have a struts-2 application running on Tomcat-5 with Single Sign on
enabled. What I am trying to do is , use HttpClient(struts2 app) to access
data other WAR(say WAR2) which also has Form Based login system. To avoid
sending user's credentials(Which I don't have in my application), I am
trying to send cookie-JSESSIOIDSSO in the request header.
Everything works fine, I get the data back. But after that, my application
throws error that, session is invalidated.
How do I stop HttpClient from invalidating the session ?
Thanks
Leena.
Leena,
The HTTP session can only be invalidated by the server. HttpClient
merely uses the session cookie to inform the server that requests are
logically related.
Oleg
Here is the code in my application ,
(Struts-2) HttpServletRequest request = ServletActionContext.getRequest();
//try out httpclient
javax.servlet.http.Cookie[] cookies = request.getCookies();
HttpState newState = new HttpState();
javax.servlet.http.Cookie ssoID = null;
for(int c = 0; c cookies.length; c ++) {
javax.servlet.http.Cookie k = cookies[c];
if(k.getName().equalsIgnoreCase(JSESSIONIDSSO))
ssoID=k;
}
HttpClient client = new HttpClient();
client.setState(newState);
GetMethod getMethod = new GetMethod(
http://localhost:8080/war2/exceuteServlet;);
getMethod.getParams().setCookiePolicy(org.apache.commons.httpclient.cookie.CookiePolicy.IGNORE_COOKIES);
getMethod.setRequestHeader(Cookie, ssoID.getName() + = +
ssoID.getValue());
try {
int responseCode =
client.executeMethod(null,getMethod,newState);
String body = getMethod.getResponseBodyAsString();
AppLogger.getLogger().debug(Response code = + responseCode+
\nResponse is + body);
} catch (HttpException e) {
// TODO Auto-generated catch block
} catch (IOException e) {
// TODO Auto-generated catch block
} finally {
// release any connection resources used by the method
getMethod.releaseConnection();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Long wait times in MultiThreadedHttpConnectionManager.doGetConnection(...)
On Wed, 2008-07-16 at 16:19 -0700, Algirdas Veitas wrote:
Hi,
Our application is using HttpClient 3.0.1 and is experiencing long wait
times (started happening recently it seems) in the method
MultiThreadedHttpConnectionManager.doGetConnection(...). To give a summary
of the application, we have a bunch of threads (message driven beans, JBoss
4.0.2, JDK 1.4) that are processing a message, creating xml out of it and
then sending the xml over an HTTP Post. The HTTP Post is always to one
static URL and the target web server is IIS. Threads are running
concurrently and have a cap of 30 in the pool, all threads are pretty much
constantly processing a request.We release the connection in our finally
block (if (postMethod != null) { postMethod.releaseConnection(); } )
As an example of the long wait times, we profiled one of our worker threads
and it took 3781 ms to process a message and do the HTTP Post. Out of the
3781 ms, 3628 ms are within
MultiThreadedHttpConnectionManager.doGetConnection(...) versus 67 ms to
perform the actual HTTP Post (via PostMethod.execute()).
Our profiler shows that methods called within
MultiThreadedHttpConnectionManager.doGetConnectiont(...) take no more than 1
ms.
Not sure what to make of this at this point, but it seems strange that there
is such a long wait time. We wire up the HttpClient configuration via
Spring, but essentially it looks like this:
httpConnectionManagerParams.setMaxConnections(40);
httpConnectionManagerParams.setSoTimeOut(1500);
multiThreadedHttpConnectionManager.setParams(httpConnectionManagerParams);
httpClient.setHttpConnectionManager(multiThreadedHttpConnectionManager);
Has anyone experienced such behavior before? Perhaps need to fine tune the
configuration?
Please let me know if more information is needed, will certainly provide it.
Thanks,
Al
Per default HttpClient uses only two simultaneous connections to the
same host regardless of how many total connections are allowed. Try
increasing the number of maximum connections per host.
Hope this helps
Oleg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: PUT Expect:100-continue
On Wed, 2008-07-16 at 17:34 -0700, Uday Subbarayan wrote:
Hi All,
I am having trouble in using HTTPClient 3.1 for PUT method w/
Expect:100-Continue header.
My requirement is that,
[1] client sends a PUT request to the server with header only using this
Expect header and waits for the 100 response back from the server.
[2] Then client sends the body, after it received the 100 status back from
the server.
The problem is that if my server sends back 100-continue, HttpClient
complaints about,
INFO: Discarding unexpected response: HTTP/1.1 100 Continue.
Here is sample code:
String testURL=http://localhost:8080/testci/index;;
HttpClient client = new HttpClient();
PutMethod put = new PutMethod(url);
put.setUseExpectHeader(true);
int statusCode = client.executeMethod(put);
if(statusCode==100){
System.out.println(server response is 100!);
put.setRequestBody(new FileInputStream(test.txt));
}
It looks like i am making some mistake Can some one shed some light here?
Uday,
HTTP agents are not supposed to return 1xx status codes to the caller.
These are special purpose codes that are meant to be used internally
Just let HttpClient handle the expect-continue handshaking.
http://hc.apache.org/httpclient-3.x/performance.html#Expect-continue_handshake
You can see exactly what gets transferred across the wire by turning on
the wire logging on the client side.
http://hc.apache.org/httpclient-3.x/logging.html
Hope this helps
Oleg
Thanks,
-Uday.
-
I do not blog but e-write:
http://uds-web.blogspot.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: PUT Expect:100-continue
Hi Oleg,
I disagree with you. This 100 status from HTTP Servers are valid response,
to indicate to the client to continue sending the body.
The HTTP 1.1 spec says,
This interim response is
used to inform the client that the initial part of the request has
been received and has not yet been rejected by the server. The client
SHOULD continue by sending the remainder of the request or, if the
request has already been completed, ignore this response. The server
MUST send a final response after the request has been completed.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.1.1
A good example is Amzon's S3:
http://docs.amazonwebservices.com/AmazonS3/2006-03-01/
Here client will send the header first and S3 authenticates request based on
header. Then if auth succeeds it will respond with 100 to indicate to the
client to continue with the body OR 417 OT to send the body.
So,
Is it safe to assume that Apache's HTTPClient is NOT supporting this
Expect:100-Continue header in HTTP1.1?
Thanks,
-Uday.
-
I do not blog but e-write:
http://uds-web.blogspot.com
--- On Thu, 7/17/08, Oleg Kalnichevski [EMAIL PROTECTED] wrote:
From: Oleg Kalnichevski [EMAIL PROTECTED]
Subject: Re: PUT Expect:100-continue
To: HttpClient User Discussion httpclient-users@hc.apache.org
Date: Thursday, July 17, 2008, 10:03 PM
On Wed, 2008-07-16 at 17:34 -0700, Uday Subbarayan wrote:
Hi All,
I am having trouble in using HTTPClient 3.1 for PUT method w/
Expect:100-Continue header.
My requirement is that,
[1] client sends a PUT request to the server with header only using this
Expect header and waits for the 100 response back from the server.
[2] Then client sends the body, after it received the 100 status back from
the server.
The problem is that if my server sends back 100-continue, HttpClient
complaints about,
INFO: Discarding unexpected response: HTTP/1.1 100 Continue.
Here is sample code:
String testURL=http://localhost:8080/testci/index;;
HttpClient client = new HttpClient();
PutMethod put = new PutMethod(url);
put.setUseExpectHeader(true);
int statusCode = client.executeMethod(put);
if(statusCode==100){
System.out.println(server response is 100!);
put.setRequestBody(new
FileInputStream(test.txt));
}
It looks like i am making some mistake Can some one shed some light
here?
Uday,
HTTP agents are not supposed to return 1xx status codes to the caller.
These are special purpose codes that are meant to be used internally
Just let HttpClient handle the expect-continue handshaking.
http://hc.apache.org/httpclient-3.x/performance.html#Expect-continue_handshake
You can see exactly what gets transferred across the wire by turning on
the wire logging on the client side.
http://hc.apache.org/httpclient-3.x/logging.html
Hope this helps
Oleg
Thanks,
-Uday.
-
I do not blog but e-write:
http://uds-web.blogspot.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
