Re: cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclientTestGetMethodLocal.java TestHttps.java TestMethodsExternalHost.java TestMethodsLocalHost.javaTestWebappBasicAuth.java TestWebappCookie.java TestWebappHeaders.java TestWebappMethods.javaTestWebappParameters.java TestWebappRedirect.java
Too may deprecation warnings for ya? Sorry about that. I don't know why the tests all bothered to call useDisk(false), it was the default anyway. I also see that finally deprecating those usdisk methods has caused some gump warnings for Slide. I'll see what I can do over there, but they have lots of other warnings/errors not caused by HttpClient. Jandalf. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running out of connections
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 [EMAIL PROTECTED]
To: Commons HttpClient Project [EMAIL PROTECTED]
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:
[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: more common classes need a home
Jeffrey Dever wrote: There are still a bunch of classes that are in both HttpClient and Slide. In particular: Base64.java HttpsURL.java HttpURL.java URIException.java URI.java URIUtil.java URLUtil.java First of all, I think these should come out of Slide as part of their migration to commons-httpclient which is still underway. Second, I thnk that these classes are too general to be part of HttpClient. They have use well beyond a http client, and so should be available to other packages without requiring the commons-httpclient.jar. Do people agree with me? If so, any idea where these could go? Perhaps the root of org.apache.commons? or a new commons-net package? put Base64 in commons-lang, and create a new commons-uri package? Base64 at least is in the Commons Codec package, which is currently in the sandbox. In Apache XML-RPC, we recently discovered interoperability problems with Base64, and fixed them. We will be pushing these changes upstream to Codec. We are leaning towards introducing a dependency instead of rolling them into our JARs, as some of the contributors have found wierd classloader problems if the same class is in the classpath more than once. I would agree with you for the others, they are useful to more than just this project. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more common classes need a home
Jeffrey Dever wrote: Also noticed that codec and xml-rpc also have their own Base64 classes. You can also add Tomcat to the list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more common classes need a home
Sounds like Base64 has found a home. What are HttpsURL and HttpURL generally used for? The various URI classes seem to need a home. They might be big enough for their own package. Where is URLUtil? We should probably require the various classes as a dependency. The only down side being that a person has to download a lot more jars, etc. to get started working with HttpClient. It's kind of nice to have everything in one jar. Perhaps that could be a release option. We could package everything in one jar as a fat release and have just HttpClient code as another skinny option. Mike On Sunday, February 2, 2003, at 07:17 PM, Jeffrey Dever wrote: There are still a bunch of classes that are in both HttpClient and Slide. In particular: Base64.java HttpsURL.java HttpURL.java URIException.java URI.java URIUtil.java URLUtil.java First of all, I think these should come out of Slide as part of their migration to commons-httpclient which is still underway. Second, I thnk that these classes are too general to be part of HttpClient. They have use well beyond a http client, and so should be available to other packages without requiring the commons-httpclient.jar. Do people agree with me? If so, any idea where these could go? Perhaps the root of org.apache.commons? or a new commons-net package? put Base64 in commons-lang, and create a new commons-uri package? If we do this, would it be better for HttpClient to roll the classes into the commons-httpclient.jar, or require it as a dependancy? Any comments would be helpful. Jandalf. - 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]
more common classes need a home
There are still a bunch of classes that are in both HttpClient and Slide. In particular: Base64.java HttpsURL.java HttpURL.java URIException.java URI.java URIUtil.java URLUtil.java First of all, I think these should come out of Slide as part of their migration to commons-httpclient which is still underway. Second, I thnk that these classes are too general to be part of HttpClient. They have use well beyond a http client, and so should be available to other packages without requiring the commons-httpclient.jar. Do people agree with me? If so, any idea where these could go? Perhaps the root of org.apache.commons? or a new commons-net package? put Base64 in commons-lang, and create a new commons-uri package? If we do this, would it be better for HttpClient to roll the classes into the commons-httpclient.jar, or require it as a dependancy? Any comments would be helpful. Jandalf. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running out of connections
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 :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more common classes need a home
What are HttpsURL and HttpURL generally used for? Nothing. They are never even imported in httpclient classes, they are just ghosts in some comments and log strings. Thats part of the reason why I want to move them away from here. Also I don't find them a particularly useful abstraction that justifies an inheritence hierachy. The various URI classes seem to need a home. They might be big enough for their own package. org.apache.jakarta.commons.uri Sounds like a good candidate to me. Sung-Gu appears to be the only one who works on these (same story in the Slide project) so it would be good to hear what he has to say. Where is URLUtil? Dunno. Seems logical though. We should probably require the various classes as a dependency. The only down side being that a person has to download a lot more jars, etc. to get started working with HttpClient. It's kind of nice to have everything in one jar. Perhaps that could be a release option. We could package everything in one jar as a fat release and have just HttpClient code as another skinny option. We still have this problem now, as commons-logging is required to build or run httpclient. This is where I look to Commons to provide some guidance on this as its a general project problem. Jandalf. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] name clash? (Was: more common classes need a home)
On Mon, 3 Feb 2003, Tomasz Pik wrote: Jeffrey Dever wrote: There are still a bunch of classes that are in both HttpClient and Slide. In particular: Base64.java HttpsURL.java HttpURL.java URIException.java URI.java URIUtil.java URLUtil.java Base64 into 'codec' but the rest? commons-net is reserved... in the time of moving from 'sandbox'. Maybe it's a good moment for change from commons-net to commons-protocols? Or maybe those classes should go into commons-lang (another subpackage, lang.net, another long discussion about the scope of lang :-)? Definitely outside commons-lang scope I think. I'd have said 'commons-net' too, but there is already a project there. Any ideas from the [net] people? :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more common classes need a home
Jeffrey Dever wrote: There are still a bunch of classes that are in both HttpClient and Slide. In particular: Base64.java HttpsURL.java HttpURL.java URIException.java URI.java URIUtil.java URLUtil.java Base64 into 'codec' but the rest? commons-net is reserved... in the time of moving from 'sandbox'. Maybe it's a good moment for change from commons-net to commons-protocols? Or maybe those classes should go into commons-lang (another subpackage, lang.net, another long discussion about the scope of lang :-)? -- Regards Tomek Pik Jandalf. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
