2010/9/25 Patricia Shanahan <[email protected]>

> On 9/25/2010 2:23 AM, Sim IJskes - QCG wrote:
>
>> On 09/25/2010 11:05 AM, Patricia Shanahan wrote:
>>
>>> I needed to do a general reset before starting a new set of tests. I
>>> completely shut down (virtual power off) all my VMs and restarted the
>>> system. This happened during the first build I did after restarting the
>>> VM in question. Before the build, I had run gedit but no tests. If it is
>>> a testing framework problem, it has to be in the junit testing that is
>>> done during the build.
>>>
>>
>> The operating system is not without state, so a test might be influenced
>> by the state changes in the OS from the previous test.
>>
>> For instance when a server socket is opened, and closed, you cannot
>> immediately bind on that same server socket, unless you specify
>> SO_REUSEADDR with setsockopt(). This is because after closing the socket
>> stays in TIME_WAIT2 state for some time.
>>
>
> Across a reboot? I did a complete shut down of the VM, and restart of the
> hosting WindowsXP, between the last test and this build failure.
>
> I have had problems in the past in which killing a test left a socket tied
> up, but rebooting has always cleared it.
>
>
Yes, killing a test process could very well leave resources open.
However, the QA framework is written in such a way that tests clean up for
themselves (setup & teardown, much like JUnit tests), even if they fail or
if they cause an Exception.
When you kill a test during its execution, obviously the teardown step is
never performed...

Also .. note that activatable services leave their state written to a log
(usually in /tmp), so that they can restore themselves after a
crash/reboot/kill.
These logs are typically removed by the QA harness in the teardown step as
well.



>
>
>> So if you forget to specify SO_REUSEADDR on your server sockets, and run
>> the same test in rapid succession, it might fail.
>>
>> I did a small codereview on the TcpServerEndpoint, and no mention of the
>> ServerSocket.setReuseAddress() call, so that is a potential cause.
>>
>> Gr. Sim
>>
>>
>>
>>
>>
>

Reply via email to