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]
