Patch for Enhancement Bug # 6313849 and 417591
Alan.Bateman at Sun.COM
Fri May 18 03:34:33 PDT 2007
Andreas Schaefer wrote:
> For the Jar- and FileURLConnection there is no such thing as an
> invocation. For the FTPURLConnection I am not quite sure if it would be
> a great thing to wait until an invocation is done especially when a huge
> file is transferred. Mostly we are dealing with Input / Output Stream
> and when they are closed the using thread gets an exception.
> On the other hand right now a user of any URLConnection has to make
> handle by themselves already so why we just let them handle it by
> themselves now.
> I suggest that we refer to the sub class' disconnect() method for
> protocol specific issues like concurrency and say by default the user
> has to take care of it by themselves.
> I also have a problem to come up with an use case of an asynchronous
> disconnect. How would another thread knows when to disconnect. The only
> use case I can come up with is than two threads could collide during
> connect / disconnect and we might want to prevent the URLConnection from
> doing so. This way we make sure that either a URLConnection is fully
> connected or disconnected.
If you add a disconnect method (maybe it should be named "close" and
have URLConnection implement Closeable), then it is likely that
developers may attempt to use it for cancellation. In error situations
or network file systems then access to JAR or file resources may block
or take significant time. There is nothing in the spec that requires
protocol handlers to support asynchronous close and it is highly likely
there are protocol handlers where it doesn't work - invoking close on
the intput or output stream may block or may not preempt threads blocked
doing I/O on the streams for example. For the proposed disconnect method
I'm just suggesting that these issues need to be considered. One
suggestion is to specify that it can't make any guarantees, beyond a
best effort attempt, to close the connection to the resource in a
timely manner. It would not be unreasonable to specify that, on
completion, the connection to the resource has been closed (which means
that disconnect may block).
One other thing - a common issue for new developers is to attempt re-use
a URLConnection (it comes up with http a lot as developers don't know
how the HTTP protocol handler works with persistent connections). In the
disconnect method it may be useful to set expectations. Also, you may
need to add wording to the connect method to specify the behavior after
the connection has been closed.
More information about the net-dev