Commit 6c8f7475 authored by Marcin Siodelski's avatar Marcin Siodelski
Browse files

[3265] Increased the timeout value in the DNSClient unit test.

This mitigates the problem whereby a packet sent in one test is not dropped
by a kernel and affects the subsequent test. The increased timeout works
around this problem. However, at some point there may be a need to
implement more proper solution (test should capture the packet sent and
drop it on its own, then start another test).
parent f04b1799
......@@ -263,8 +263,16 @@ public:
ASSERT_NO_THROW(message.setZone(Name(""), RRClass::IN()));
// Set the response wait time to 0 so as our test is not hanging. This
// should cause instant timeout.
/// @todo The timeout value could be set to 0 to trigger timeout
/// instantly. However, it may lead to situations that the message sent
/// in one test will not be dropped by the kernel by the time, the next
/// test starts. This will lead to intermittent unit test errors as
/// described in the ticket
/// Increasing the timeout to a non-zero value mitigates this problem.
/// The proper way to solve this problem is to receive the packet
/// on our own and drop it. Such a fix will need to be applied not only
/// to this test but also for other tests that rely on arbitrary timeout
/// values.
const int timeout = 500;
// The doUpdate() function starts asynchronous message exchange with DNS
// server. When message exchange is done or timeout occurs, the
......@@ -324,8 +332,10 @@ public:
// The socket is now ready to receive the data. Let's post some request
// message then.
const int timeout = 5;
// message then. Set timeout to some reasonable value to make sure that
// there is sufficient amount of time for the test to generate a
// response.
const int timeout = 500;
dns_client_->doUpdate(service_, IOAddress(TEST_ADDRESS), TEST_PORT,
message, timeout);
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment