Patch for Enhancement Bug # 6313849 and 417591

[Andreas Schaefer]

Alan Bateman wrote:
> 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).
The underlying resource could be many things and so I would say that the 
disconnect closes the underlying resource as fast as possible maybe 
interrupting a work in progress by another thread and its the user's 
responsibility to handle this.
> 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.
The basic idea is that a disconnect() must be closed in a way that a 
user can (re)connect again afterwards. This does require that the 
connect() and disconnect() do not interfere with each other.

-Andy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: andreas.schaefer.vcf
Type: text/x-vcard
Size: 403 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070518/645a80b3/andreas.schaefer.vcf