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: Pool running out of connections
On Thu, 2008-07-17 at 17:41 +0200, Joan Balagueró wrote: > Hello, > > Thanks for your response. I suppose that this eviction policy that you are > saying is achieved by using IdleConnectionTimeoutThread. Am I right? > > Joan. Yes, you are. You do not necessarily need a special thread to achieve that. Just call HttpConnectionManager#closeIdleConnections method after a period inactivity to purge stale connections: http://hc.apache.org/httpclient-3.x/apidocs/org/apache/commons/httpclient/HttpConnectionManager.html#closeIdleConnections(long) Oleg > > > > -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] > - 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"
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]
Re: PUT & Expect:100-continue
Uday Subbarayan wrote: 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. You are very welcome to disagree. RFC 2616, section 10.1 " 10.1 Informational 1xx This class of status code indicates a _provisional_ response, ... A client MUST be prepared to accept one or _more_ 1xx status responses prior to a _regular_ response ... " 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? You can assume whatever you please. HttpClient is fully RFC 2616 compliant with regards to the expect:continue handshaking. Oleg Thanks, -Uday. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
