[squeak-dev] WebClient test fails in trunk

Levente Uzonyi leves at elte.hu
Wed Jul 4 21:46:58 UTC 2012


On Tue, 3 Jul 2012, Frank Shearar wrote:

> On 3 July 2012 17:42, Frank Shearar <frank.shearar at gmail.com> wrote:
>> On 3 July 2012 17:38, Levente Uzonyi <leves at elte.hu> wrote:
>>> On Tue, 3 Jul 2012, Frank Shearar wrote:
>>>
>>>> Hi,
>>>>
>>>> I took WebClient for a spin in a trunk image, and found a failing
>>>> test: WebClientServerTest >> #testServerDestroy throws a
>>>> "ConnectionClosed: Connection closed while waiting for data". That
>>>> sounds familiar - I think this was introduced in a recent Network
>>>> change.
>>>>
>>>> Still, it means WebClient needs fixing. I'll try fix it on my evening
>>>> commute, but if anyone feels like racing me, I'll be happy!
>>>
>>>
>>> Interesting, I had no issue with it on windows, except for some extension
>>> methods trying to use the CrLf class variable in HTTPSocket (or some other
>>> class), but that variable doesn't exist.
>>
>> Which reminds me of an important fact I should mention: I'm testing
>> this on an Ubuntu Lynx box.

The VM also matters in this case. I tried it with an older CogVM which 
doesn't have the new socket primitives.

>
> Peek tries to read data, which waits for data, which raises the
> ConnectionClosed. If peek must return nil when the socket's closed,
> I'd expect to see the receiveData wrapped appropriately. Something
> like
>
> peek
> 	"Return next byte, if inBuffer is empty
> 	we recieve some more data and try again.
> 	Do not consume the byte."
>
> 	self atEnd ifTrue: [^nil].
> 	self isInBufferEmpty ifTrue:
> 		[[self receiveData] on: ConnectionClosed do: [^nil] "<--"
> 		self atEnd ifTrue: [^nil]].
> 	^inBuffer at: lastRead+1
>
> That's a random hack that makes the test pass (and doesn't break any
> others); I don't know if it has any negative consequences elsewhere. I
> guess the method as above means "return the next thing in the stream,
> unless we're at the end of the stream, or there's no data", which
> doesn't seem entirely unreasonable.

I never really used or looked deeply into SocketStream, so I'm not sure if 
it's okay to catch that exception.


Levente

>
> frank
>
>> frank
>>
>>> Levente
>>>
>>>>
>>>> frank
>>>>
>>>>
>>>
>
>


More information about the Squeak-dev mailing list