You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Jeffrey Dever <js...@sympatico.ca> on 2003/01/29 08:47:37 UTC
[VOTE] checkstyle rules
There has not been any more discussion on this topic so its time to call
a vote. Please vote on each entry with one of the following answers:
+1 agree
0 don't care
-1 disagree
For more information on what these mean, please see the email thread on
this and the checkstyle documentation:
http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-httpclient-dev@jakarta.apache.org&msgNo=1316
http://checkstyle.sourceforge.net/config.html
checkstyle.maxlinelen=100
checkstyle.pattern.publicmember=^[a-z][a-zA-Z0-9]*$
checkstyle.pattern.package=^[a-z]+(\.[a-z]*)*$
checkstyle.header.file=license.regexp
checkstyle.header.regexp=true
checkstyle.ignore.maxlinelen=Header:
checkstyle.tab.width=4
checkstyle.pattern.member=^_?[a-z][a-zA-Z0-9]*$
Re: Running out of connections
Posted by Jeffrey Dever <js...@sympatico.ca>.
Yes, there are many uses of HttpClient with massive multiple connections
so this is a serious issue. Mike Becke is the expert here.
Oleg Kalnichevski wrote:
>Jandalf,
>Nobody responded to Simon so far, even though this problem sounds like a
>pretty nasty one. Shall we file a bug report? I suppose we should
>consult Mike Becke first.
>
>Cheers
>
>Oleg
>
>
>On Thu, 2003-01-30 at 03:04, Simon Roberts wrote:
>
>
>>Gidday,
>>
>>With the current CVS version, I seem to be having a problem where I run out of connections to a server. It happens if I do a bunch of HTTP operations that fail (404, as it happens) and the reply include a "Connection: close". If no garbage-collect happens then the connections are not freed!
>>
>>Shouldn't we expire them if we're running out of connections?
>>
>>Cheers, Simon
>>
>>
Re: Running out of connections
Posted by Oleg Kalnichevski <o....@dplanet.ch>.
Jandalf,
Nobody responded to Simon so far, even though this problem sounds like a
pretty nasty one. Shall we file a bug report? I suppose we should
consult Mike Becke first.
Cheers
Oleg
On Thu, 2003-01-30 at 03:04, Simon Roberts wrote:
> Gidday,
>
> With the current CVS version, I seem to be having a problem where I run out of connections to a server. It happens if I do a bunch of HTTP operations that fail (404, as it happens) and the reply include a "Connection: close". If no garbage-collect happens then the connections are not freed!
>
> Shouldn't we expire them if we're running out of connections?
>
> Cheers, Simon
--
Oleg Kalnichevski <o....@dplanet.ch>
Re: Running out of connections
Posted by Simon Roberts <si...@fifthweb.net>.
> Yes, but you have done a very bad thing here. By doing the
> executeMethod(), you have established a connection to the server, and
> have read the headers. But then you are closing the connection before
> reading the body. The client (thats you!) is responsible for completing
> the read by calling one of the getResponseBody() methods. Even though
> you are getting 404 in this case, you don't know that and must still
> read the body after the execute.
Agreed. I changed my code already :)
> I am surprised that calling System.gc() does anything here though.
> There is still a handle on the method at this point, and the connection
> is still in use so neither are elligible for garbage collection ...
Ahh, but it frees the *last* connection, not the current one :)
Re: Running out of connections
Posted by Jeffrey Dever <js...@sympatico.ca>.
>
>
> public void testConnectionPool()
> throws IOException, HttpException
> {
> final MultiThreadedHttpConnectionManager manager = new
>MultiThreadedHttpConnectionManager();
>
> HttpClient httpClient = new HttpClient(manager);
> httpClient.getHostConfiguration().setHost("www.slashdot.org", 80,
>"http");
> httpClient.setHttpConnectionFactoryTimeout(2000); // wait up to 2
>seconds when getting a HttpConnection
> for (int i = 0; i < 30; i++) {
> HttpMethod method = new
>GetMethod("http://www.slashdot.org/notfound");
> int res = httpClient.executeMethod(method);
> // System.gc();
> // method.releaseConnection();
> }
> }
>
>Uncommenting either of the last two lines makes the problem go away...
>
Yes, but you have done a very bad thing here. By doing the
executeMethod(), you have established a connection to the server, and
have read the headers. But then you are closing the connection before
reading the body. The client (thats you!) is responsible for completing
the read by calling one of the getResponseBody() methods. Even though
you are getting 404 in this case, you don't know that and must still
read the body after the execute.
The connection will be closed if there is a "Connection: Close" header
automagicly only *after* you have read the body. Otherwise it will stay
open awaiting the next request. releaseConnection() will forcibly close
the connection regardless of the "Connection" header.
Another note about your example above, you don't need to bother setting
the HostConfiguration if you are using fully qualified urls for the
GetMethods.
I am surprised that calling System.gc() does anything here though.
There is still a handle on the method at this point, and the connection
is still in use so neither are elligible for garbage collection ...
Jandalf.
>
>
>
>----- Original Message -----
>From: "Michael Becke" <be...@u.washington.edu>
>To: "Commons HttpClient Project" <co...@jakarta.apache.org>
>Sent: Sunday, February 02, 2003 6:18 AM
>Subject: Re: Running out of connections
>
>
>
>
>>Hello Simon,
>>
>>Sorry to be replying so late. Connections are released when:
>>
>>1) the response is fully read
>>2) the connection is manually released via
>>HttpMethod.releaseConnection() or HttpConnection.releaseConnection()
>>3) the garbage collector runs and reclaims any connections that are no
>>longer being used
>>
>>The most reliable way is to manually release the connection after use.
>>This goes for successful or unsuccessful requests. Can you send a
>>sample of the code you are using that causes this problem?
>>
>>Mike
>>
>>On Wednesday, January 29, 2003, at 09:04 PM, Simon Roberts wrote:
>>
>>
>>
>>>Gidday,
>>>
>>>With the current CVS version, I seem to be having a problem where I
>>>run out of connections to a server. It happens if I do a bunch of
>>>HTTP operations that fail (404, as it happens) and the reply include a
>>>"Connection: close". If no garbage-collect happens then the
>>>connections are not freed!
>>>
>>>Shouldn't we expire them if we're running out of connections?
>>>
>>>Cheers, Simon
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail:
>>
>>
>commons-httpclient-dev-unsubscribe@jakarta.apache.org
>
>
>>For additional commands, e-mail:
>>
>>
>commons-httpclient-dev-help@jakarta.apache.org
>
>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
>
>
Re: Running out of connections
Posted by Eric Johnson <er...@tibco.com>.
There is one further alternative to Jeffrey's suggestion. You can call
"executeMethod", then get the response stream, then call "close()" on
that. The "close" on the response stream will trigger the right
sequence of events.
-Eric.
Simon Roberts wrote:
>I guess the problem is really mine. I was somewhat expecting the connection
>to be released after it gets a "connection: close".
>
> /**
> * A test that illustrates the problem with connections not being
>recovered from a "Connection: close" response.
> */
> public void testConnectionPool()
> throws IOException, HttpException
> {
> final MultiThreadedHttpConnectionManager manager = new
>MultiThreadedHttpConnectionManager();
>
> HttpClient httpClient = new HttpClient(manager);
> httpClient.getHostConfiguration().setHost("www.slashdot.org", 80,
>"http");
> httpClient.setHttpConnectionFactoryTimeout(2000); // wait up to 2
>seconds when getting a HttpConnection
> for (int i = 0; i < 30; i++) {
> HttpMethod method = new
>GetMethod("http://www.slashdot.org/notfound");
> int res = httpClient.executeMethod(method);
> // System.gc();
> // method.releaseConnection();
> }
> }
>
>Uncommenting either of the last two lines makes the problem go away...
>
>
>
>----- Original Message -----
>From: "Michael Becke" <be...@u.washington.edu>
>To: "Commons HttpClient Project" <co...@jakarta.apache.org>
>Sent: Sunday, February 02, 2003 6:18 AM
>Subject: Re: Running out of connections
>
>
>
>
>>Hello Simon,
>>
>>Sorry to be replying so late. Connections are released when:
>>
>>1) the response is fully read
>>2) the connection is manually released via
>>HttpMethod.releaseConnection() or HttpConnection.releaseConnection()
>>3) the garbage collector runs and reclaims any connections that are no
>>longer being used
>>
>>The most reliable way is to manually release the connection after use.
>>This goes for successful or unsuccessful requests. Can you send a
>>sample of the code you are using that causes this problem?
>>
>>Mike
>>
>>On Wednesday, January 29, 2003, at 09:04 PM, Simon Roberts wrote:
>>
>>
>>
>>>Gidday,
>>>
>>>With the current CVS version, I seem to be having a problem where I
>>>run out of connections to a server. It happens if I do a bunch of
>>>HTTP operations that fail (404, as it happens) and the reply include a
>>>"Connection: close". If no garbage-collect happens then the
>>>connections are not freed!
>>>
>>>Shouldn't we expire them if we're running out of connections?
>>>
>>>Cheers, Simon
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail:
>>
>>
>commons-httpclient-dev-unsubscribe@jakarta.apache.org
>
>
>>For additional commands, e-mail:
>>
>>
>commons-httpclient-dev-help@jakarta.apache.org
>
>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
>
Re: Running out of connections
Posted by Simon Roberts <si...@fifthweb.net>.
I guess the problem is really mine. I was somewhat expecting the connection
to be released after it gets a "connection: close".
/**
* A test that illustrates the problem with connections not being
recovered from a "Connection: close" response.
*/
public void testConnectionPool()
throws IOException, HttpException
{
final MultiThreadedHttpConnectionManager manager = new
MultiThreadedHttpConnectionManager();
HttpClient httpClient = new HttpClient(manager);
httpClient.getHostConfiguration().setHost("www.slashdot.org", 80,
"http");
httpClient.setHttpConnectionFactoryTimeout(2000); // wait up to 2
seconds when getting a HttpConnection
for (int i = 0; i < 30; i++) {
HttpMethod method = new
GetMethod("http://www.slashdot.org/notfound");
int res = httpClient.executeMethod(method);
// System.gc();
// method.releaseConnection();
}
}
Uncommenting either of the last two lines makes the problem go away...
----- Original Message -----
From: "Michael Becke" <be...@u.washington.edu>
To: "Commons HttpClient Project" <co...@jakarta.apache.org>
Sent: Sunday, February 02, 2003 6:18 AM
Subject: Re: Running out of connections
> Hello Simon,
>
> Sorry to be replying so late. Connections are released when:
>
> 1) the response is fully read
> 2) the connection is manually released via
> HttpMethod.releaseConnection() or HttpConnection.releaseConnection()
> 3) the garbage collector runs and reclaims any connections that are no
> longer being used
>
> The most reliable way is to manually release the connection after use.
> This goes for successful or unsuccessful requests. Can you send a
> sample of the code you are using that causes this problem?
>
> Mike
>
> On Wednesday, January 29, 2003, at 09:04 PM, Simon Roberts wrote:
>
> > Gidday,
> >
> > With the current CVS version, I seem to be having a problem where I
> > run out of connections to a server. It happens if I do a bunch of
> > HTTP operations that fail (404, as it happens) and the reply include a
> > "Connection: close". If no garbage-collect happens then the
> > connections are not freed!
> >
> > Shouldn't we expire them if we're running out of connections?
> >
> > Cheers, Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org
>
>
Re: Running out of connections
Posted by Michael Becke <be...@u.washington.edu>.
Hello Simon,
Sorry to be replying so late. Connections are released when:
1) the response is fully read
2) the connection is manually released via
HttpMethod.releaseConnection() or HttpConnection.releaseConnection()
3) the garbage collector runs and reclaims any connections that are no
longer being used
The most reliable way is to manually release the connection after use.
This goes for successful or unsuccessful requests. Can you send a
sample of the code you are using that causes this problem?
Mike
On Wednesday, January 29, 2003, at 09:04 PM, Simon Roberts wrote:
> Gidday,
>
> With the current CVS version, I seem to be having a problem where I
> run out of connections to a server. It happens if I do a bunch of
> HTTP operations that fail (404, as it happens) and the reply include a
> "Connection: close". If no garbage-collect happens then the
> connections are not freed!
>
> Shouldn't we expire them if we're running out of connections?
>
> Cheers, Simon
Running out of connections
Posted by Simon Roberts <si...@fifthweb.net>.
Gidday,
With the current CVS version, I seem to be having a problem where I run out of connections to a server. It happens if I do a bunch of HTTP operations that fail (404, as it happens) and the reply include a "Connection: close". If no garbage-collect happens then the connections are not freed!
Shouldn't we expire them if we're running out of connections?
Cheers, Simon
Re: [VOTE] checkstyle rules
Posted by Simon Roberts <si...@fifthweb.net>.
> checkstyle.maxlinelen=100
+1
> checkstyle.pattern.publicmember=^[a-z][a-zA-Z0-9]*$
+1
> checkstyle.pattern.package=^[a-z]+(\.[a-z]*)*$
+1
> checkstyle.header.file=license.regexp
> checkstyle.header.regexp=true
> checkstyle.ignore.maxlinelen=Header:
+1
> checkstyle.tab.width=4
+1
> checkstyle.pattern.member=^_?[a-z][a-zA-Z0-9]*$
-1
Can I trade my +1's for some more -1's? :)
Cheers, Simon
Re: [VOTE] checkstyle rules
Posted by Ortwin Glück <or...@nose.ch>.
> checkstyle.maxlinelen=100
+1
> checkstyle.pattern.publicmember=^[a-z][a-zA-Z0-9]*$
+1
> checkstyle.pattern.package=^[a-z]+(\.[a-z]*)*$
+1
> checkstyle.header.file=license.regexp
> checkstyle.header.regexp=true
+1
> checkstyle.ignore.maxlinelen=Header:
+1
> checkstyle.tab.width=4
+1
> checkstyle.pattern.member=^_?[a-z][a-zA-Z0-9]*$
0 (okay for private members but should not be enforced)
Re: [VOTE] checkstyle rules - results
Posted by Jeffrey Dever <js...@sympatico.ca>.
The results are pretty conclusive. Everyone's votes were counted (as
best I could figure them out!). Feel free to recount if you have any
doubts. I'll make the change to checkstyle.properties tomorrow to match
the results.
checkstyle.maxlinelen=100
+1 7
0 0
-1 1
checkstyle.pattern.publicmember=^[a-z][a-zA-Z0-9]*$
+1 6
0 0
-1 0
checkstyle.pattern.package=^[a-z]+(\.[a-z]*)*$
+16
0 0
-1 0
checkstyle.header.file=license.regexp
checkstyle.header.regexp=true
+16
0 0
-1 0
checkstyle.ignore.maxlinelen=Header:
+16
0 0
-1 0
checkstyle.tab.width=4
+16
0 0
-1 0
checkstyle.pattern.member=^_?[a-z][a-zA-Z0-9]*$
+11
0 2
-1 5
Jeffrey Dever wrote:
> There has not been any more discussion on this topic so its time to
> call a vote. Please vote on each entry with one of the following answers:
> +1 agree
> 0 don't care
> -1 disagree
>
> For more information on what these mean, please see the email thread
> on this and the checkstyle documentation:
> http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-httpclient-dev@jakarta.apache.org&msgNo=1316
>
> http://checkstyle.sourceforge.net/config.html
>
> checkstyle.maxlinelen=100
>
> checkstyle.pattern.publicmember=^[a-z][a-zA-Z0-9]*$
>
> checkstyle.pattern.package=^[a-z]+(\.[a-z]*)*$
>
> checkstyle.header.file=license.regexp
> checkstyle.header.regexp=true
>
> checkstyle.ignore.maxlinelen=Header:
>
> checkstyle.tab.width=4
>
> checkstyle.pattern.member=^_?[a-z][a-zA-Z0-9]*$
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>
>
Re: [VOTE] checkstyle rules
Posted by Jeffrey Dever <js...@sympatico.ca>.
My votes.
> checkstyle.maxlinelen=100
+1
> checkstyle.pattern.publicmember=^[a-z][a-zA-Z0-9]*$
+1
> checkstyle.pattern.package=^[a-z]+(\.[a-z]*)*$
+1
> checkstyle.header.file=license.regexp
> checkstyle.header.regexp=true
+1
> checkstyle.ignore.maxlinelen=Header:
+1
> checkstyle.tab.width=4
+1
> checkstyle.pattern.member=^_?[a-z][a-zA-Z0-9]*$
-1 (don't like leading or trailing underscores)
Re: [VOTE] checkstyle rules
Posted by Jeffrey Dever <js...@sympatico.ca>.
Correct. There is another property for the maximum number of lines in a
class, which by default is 2000. Currently HttpMethodBase violates this.
Sung-Gu wrote:
>----- Original Message -----
>
>
>>checkstyle.maxlinelen=100
>>
>>
>
>-1
>
>Does it mean really every max line length of a file or class? --a
>I guess probably it means a column length.
>
>else +1
>
>Sung-Gu
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
>
>
Re: [VOTE] checkstyle rules
Posted by Sung-Gu <je...@apache.org>.
----- Original Message -----
> checkstyle.maxlinelen=100
-1
Does it mean really every max line length of a file or class? --a
I guess probably it means a column length.
else +1
Sung-Gu
Re: [VOTE] checkstyle rules
Posted by Sung-Gu <je...@apache.org>.
I miswatched it... ^^;
In general, I would give it -1.
----- Original Message -----
From: "Michael Becke" <be...@u.washington.edu>
> > checkstyle.pattern.member=^_?[a-z][a-zA-Z0-9]*$
> -1
In the Java world, surely it's -1... ;)
Actually, C++ is able to have non-local global varaible with in C.
In order to distinguish it between local variables and them,
it was required, I think... But it would not happen in Java.
In a case of URI class, it was lack of idea.. ^^;;;
Sung-Gu
Re: [VOTE] checkstyle rules
Posted by Michael Becke <be...@u.washington.edu>.
> checkstyle.maxlinelen=100
-1
> checkstyle.pattern.publicmember=^[a-z][a-zA-Z0-9]*$
+1
> checkstyle.pattern.package=^[a-z]+(\.[a-z]*)*$
+1
> checkstyle.header.file=license.regexp
> checkstyle.header.regexp=true
+1
> checkstyle.ignore.maxlinelen=Header:
+1
> checkstyle.tab.width=4
+1
> checkstyle.pattern.member=^_?[a-z][a-zA-Z0-9]*$
-1