How about using the MultiThreadedHttpConnectionManager and then calling
method.releaseConnection() after executing each method in WebdavResource.
For example, a typical fragment in WebdavResource:
int statusCode;
try {
statusCode = client.executeMethod(method);
} finally {
method.releaseConnection();
}
setStatusCode(statusCode);
return (statusCode >= 200 && statusCode < 300) ? true : false;
}
Will this work?
Carlos
Ingo Brunberg wrote:
Your assumptions are correct. The exisiting close() method does almost
do nothing. I had also thought about fixing it the way you propose and
will do so now.
The price to pay for closing connections is that a new connection has
to be created when you execute the next method. I have always
recommended that only one WebdavResource instance be created by
calling one of its constructors and then using getChildResources()
where possible. This way only one conection is used. But if you close
one of these resources all of the others are affected.
However, in a scenario where you have to create multiple independent
WebdavResource instances, closing them is crucial, so it should work
right. In a client application where you only use one connection you
would most likely not care to explicitly close it anyway.
Ingo
Ingo, Thanks for the fix and your suggestion, they both worked great!
We still have a problem with connections not being closed, and going into
CLOSE_WAIT state though. A WebdavResource.close() method that explicitly
closes the connection solves this problem (see below), although I'm sure
it would break if MultiThreadedConnectionManager was in use. How does the
existing close() behavior work? Does it rely on GC and Socket.finalizer()?
Any ideas why my connections aren't closing and I am having to forcefully
close them in this way? (NB the connections do get closed when the program
exits - the problem only shows with long-running code! It's easy to
reproduce it by adding a Thread.sleep() at the end of any simple test
program.)
Thanks,
Neil
public void close() throws IOException {
HttpConnection conn =
this.client.getHttpConnectionManager().getConnection(this.client.getHostConfiguration());
conn.close();
}
Hi Neil,
I have corected the isTheClient() call so that you can now ommit the
default port.
Why do you make a separate setUserInfo() call? Just put that info
directly into your URL to avoid an additional PROPFIND.
Ingo
Hi,
I am seeing a few problems performing PUTs against Apache 1.3 in a
production environment. This test code:
WebdavResource r = new WebdavResource("http://server/dir/";);
r.setUserInfo(username, password);
r.putMethod("/dir/foo9.txt", "hello");
opens 3 connections. It does 2 PROPFINDS (one for ctor, and one for
setUSerInfo) and a PUT. It then keeps those 3 connections alive a la
HTTP
1.1, but never reuses them. The Apache server closes them after a short
timeout and they sit in CLOSE_WAIT for a while. This is causing the
server
to run too many processes, and the client to run out out of file
descriptors.
Debugging this, I found that the reason it is failing to reuse
connections
seems to be WebdavResource.isTheClient(), which contains this line:
return clientHttpURL.getAuthority().equals(httpURL.getAuthority());
This check is failing, because
clientHttpURL.getAuthority() --> "server:80"
httpURL.getAuthority() = "server"
So changing my client code to this helps:
WebdavResource r = new WebdavResource("http://server:80/dir/";);
But we'd really like to be able to turn off keep-alive behavior, or
manually close the connection when we're done, rather than waiting for
garbage-collection & OS timeouts - we have so many clients and servers,
and so much traffic that leaving the connections open is too expensive.
We'd also like to avoid the PROPFINDS, which don't seem essential.
I am testing a hack/patch to bypass the PROPFINDs and forcibly close the
connection after a PUT, but would prefer better solutions obviously!
Thanks for any insights you can offer,
Neil
---------------------------------------------------------------------
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]
