Socket InputStream.available may return a positive value after shutdown

Chris Hegarty chris.hegarty at oracle.com
Thu Aug 11 08:58:20 PDT 2011


Here is a first stab at fixing this issue.

   http://cr.openjdk.java.net/~chegar/7014860/webrev.00/webrev/

-Chris.

On 07/21/11 09:42 AM, Jing LV wrote:
> Hi,
>
> Thank you Chris! Would you please send the link when you have some
> progress?
>
> 于 2011-7-18 18:00, Chris Hegarty 写道:
>> On 07/18/11 09:09 AM, Jing LV wrote:
>>> Hi Chris, Alan,
>>>
>>> Thanks for reply. I am looking for a conclusion and solution for this
>>> issue. If I understand correctly, it'd fix the spec rather than fix the
>>> code?
>>
>> The current plan of record is to clarify the spec to indicate that
>> available will return 0 after shutdownInput is invoked. Then change
>> the implementation to do just this.
>>
>> I'll send out a webrev soon.
>>
>> -Chris.
>>
>>>
>>> 于 2011-7-14 17:00, Chris Hegarty 写道:
>>>> On 07/14/11 09:36 AM, Alan Bateman wrote:
>>>>> Chris Hegarty wrote:
>>>>>> :
>>>>>>
>>>>>> I can't see that anyone could be depending on the fact the
>>>>>> available()
>>>>>> would return > 0 after shutdownInput(), given that subsequent reads
>>>>>> will always return -1. I just can't see why anyone would require
>>>>>> this,
>>>>>> but maybe I'm missing something.
>>>>> You're probably right, and it's just the concern that there may be
>>>>> code
>>>>> that won't now read and see the end-of-stream. The other concern is
>>>>> that
>>>>
>>>> Yes, interesting point. I think this may be less of a concern though.
>>>> Can anyone even depend on this today, i.e. use available to determine
>>>> when to read and expect to reach eof? I don't think so because they
>>>> may just happen to read the exact amount of data being sent and
>>>> available will always return 0.
>>>>
>>>> Also, it does seems unlikely that this change would surprise too may
>>>> people, they are calling shutdownInput explicitly on the socket.
>>>>
>>>> Let me put together a webrev and see the extent of the changes.
>>>>
>>>> -Chris.
>>>>
>>>>> we don't know how custom SocketImpls might behave. Overall the risk
>>>>> does
>>>>> seem low.
>>>>>
>>>>> -Alan.
>>>
>>>
>
>



More information about the net-dev mailing list