Validation failur ZnImageExampleDelegateTests>>#testDefaultImage
Anyone has an idea why this test fails so often? In ZnImageExampleDelegateTests>>withServerDo: block we use ZnServer on: 1700 + 32 atRandom. I don't know if this is related to the validation failure, but the randomly generated portnumber makes it hard get reliable results. nicolai
All Zn tests that run local servers work like that, using a random port from a range of 32. With fixed ports, we would get many more conflicts because tests and/or CI jobs are running concurrently on slaves. We could increase the range. We could pass some small unique ID to each image and use that to compute a unique port. Testing if a port is available is a total mess because the different socket plugins behave slightly different. Maybe starting servers and letting the OS give out a next available port could work, I should try that. In any case, unless this is a persistent problem I would not do it now.
On 05 Mar 2015, at 10:29, Nicolai Hess <nicolaihess@web.de> wrote:
Anyone has an idea why this test fails so often?
In ZnImageExampleDelegateTests>>withServerDo: block we use ZnServer on: 1700 + 32 atRandom.
I don't know if this is related to the validation failure, but the randomly generated portnumber makes it hard get reliable results.
nicolai
Is it possible to see the result of the failing test 2015-03-05 10:40 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
All Zn tests that run local servers work like that, using a random port from a range of 32.
With fixed ports, we would get many more conflicts because tests and/or CI jobs are running concurrently on slaves.
We could increase the range.
We could pass some small unique ID to each image and use that to compute a unique port.
Testing if a port is available is a total mess because the different socket plugins behave slightly different.
Maybe starting servers and letting the OS give out a next available port could work, I should try that.
In any case, unless this is a persistent problem I would not do it now.
On 05 Mar 2015, at 10:29, Nicolai Hess <nicolaihess@web.de> wrote:
Anyone has an idea why this test fails so often?
In ZnImageExampleDelegateTests>>withServerDo: block we use ZnServer on: 1700 + 32 atRandom.
I don't know if this is related to the validation failure, but the randomly generated portnumber makes it hard get reliable results.
nicolai
On 20 Mar 2015, at 21:02, Nicolai Hess <nicolaihess@web.de> wrote:
Is it possible to see the result of the failing test
I can't find it ;-) I made the image used in #testUpload [ http://zn.stfx.eu/zn/Hot-Air-Balloon.gif ] smaller (it is downloaded during the test). Doing real, live networking during the tests sometimes results in failures, there is no way around that.
2015-03-05 10:40 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>: All Zn tests that run local servers work like that, using a random port from a range of 32.
With fixed ports, we would get many more conflicts because tests and/or CI jobs are running concurrently on slaves.
We could increase the range.
We could pass some small unique ID to each image and use that to compute a unique port.
Testing if a port is available is a total mess because the different socket plugins behave slightly different.
Maybe starting servers and letting the OS give out a next available port could work, I should try that.
In any case, unless this is a persistent problem I would not do it now.
On 05 Mar 2015, at 10:29, Nicolai Hess <nicolaihess@web.de> wrote:
Anyone has an idea why this test fails so often?
In ZnImageExampleDelegateTests>>withServerDo: block we use ZnServer on: 1700 + 32 atRandom.
I don't know if this is related to the validation failure, but the randomly generated portnumber makes it hard get reliable results.
nicolai
participants (2)
-
Nicolai Hess -
Sven Van Caekenberghe