On 5 April 2013 04:16, Levente Uzonyi <leves at elte.hu> wrote:
> On Thu, 4 Apr 2013, Frank Shearar wrote:
>
>> So this isn't exactly a common use case, except on build.squeak.org:
>>
>> You have a bunch of network tests, so in your #setUp you start up a
>> server on some port and in #tearDown you shut down the server. What
>> port do you use? Well, it doesn't really matter too much, as long as
>> the port's available. So you choose some probably-not-used port, like
>> 7799. (WebClient's test suite uses this.) All is almost always well,
>> because tests only fail when something's using 7799, which is almost
>> never.
>>
>> build.squeak.org has two executors, which means it can run two builds
>> concurrently. Suddenly, if you build SqueakTrunk, you'll trigger
>> ExternalPackages, ExternalPackages-Squeak4.3 and External-Squeak4.4.
>> Which means you will often execute the same test suite in different
>> images at the same time. Suddenly those tests using a hard-coded port
>> all fail, causing noise. (Xtreams' test suite is also vulnerable to
>> this problem: look at the  XTSocketReadingWritingTest failures in
>> http://build.squeak.org/job/ExternalPackages/43/testReport/)
>>
>> So what do we do?
>>
>> One approach that I can think of is, like WebClient's test suite, to
>> use a method #port returning the port to use in a test. However, #port
>> should not return a constant but rather attempt to open a port within
>> some range, and return _some_ open port. The problem here is a
>> time-of-check-time-of-use race.
>>
>> Now that might nearly always work. Can anyone think of a better method?
>
>
> The current socket implementation does exactly what you need. If a port is
> being used, the socket will listen on a random free port. So the solution is
> to ask the created Socket instance for which port it's listening on.
>
> Code showing the behavior:
>
> s := Socket newTCP.
> s listenOn: 1234 backlogSize: 10.
> s port.
> s2 := Socket newTCP.
> s2 listenOn: 1234 backlogSize: 10.
> { s port. s2 port } "==> #(1234 50542)"

That's.... surprising. Is that something the SocketPlugin does? No EADDRINUSE?

OK, so leaving aside that I think that's crazy behaviour, that means
Xtreams could be easily fixed. In its #setUp there's a block

[output := Socket newTCP.
    output connectTo: #[127 0 0 1] port: 9999 waitForConnectionFor: 2.
    sync signal] fork.

which should become

[output := Socket newTCP.
    output connectTo: #[127 0 0 1] port: listene port waitForConnectionFor: 2.
    sync signal] fork.

frank

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