summaryrefslogtreecommitdiff
path: root/annotations/generate_annotated_java_files.py
diff options
context:
space:
mode:
authorTobias Thierer <tobiast@google.com>2018-06-28 20:38:29 +0100
committerTobias Thierer <tobiast@google.com>2018-07-03 14:34:09 +0000
commit267c6757301a0beca9d294d5345bcd36c6b11890 (patch)
tree67829d03627bdea839e78a74876af61edf53bead /annotations/generate_annotated_java_files.py
parentd7ab0877dc2ae2b60b1c1c0733823f58ac4de351 (diff)
DatagramChannelMulticastTest: Briefly wait for non-instantaneous reads.
This test previously assumed that communication within localhost is instantaneous, but this was observed to be flaky in some contexts (on the network where I personally observed it to fail, if it failed then several test methods in this test failed at once). An external developer reported that in their case, the flakiness was sensitive to timing (perhaps the instantaneous communication does not happen, at least in some environments, perhaps depending on the network or kernel version). Since the test originally wanted to do blocking calls (but those potentially blocked indefinitely), and because the communication "typically" (based on historical observation) happens instantly, there's not really any harm in adding a small timeout. This CL allows a timeout up to 100msec when the read is expected to fail, or 1000msec if it's expected to succeed. The delay is only incurred (in 20msec increments) in the (currently rare / unexpected) case where the initial (instantaneous) read failed. Bug: 109652909 Bug: 80513007 Test: DatagramChannelMulticastTest Change-Id: Ie17e97a8b128b2a087fa432970c9ec8d81d9f85b Merged-In: Ie17e97a8b128b2a087fa432970c9ec8d81d9f85b (cherry picked from commit 94e2f754782974a7535a0a6f72f314254204a5b6)
Diffstat (limited to 'annotations/generate_annotated_java_files.py')
0 files changed, 0 insertions, 0 deletions