Hi,
that's great! Thanks for identifying the issue!
Andy
Andy Turner wrote:
Hi,
that's great! Thanks for identifying the issue!
Andy
1. First off, the thanks are from us to you, for bringing the issue forward.
2. Second thanks are for providing a working unittest. I honestly do not remember of another concurrecy bug report that came with unittests attached.
3. At least here the unittests run in ~ 1m40s on trunk. If I synchronize QueueImpl.deliver() with a guard of its own, your tests will run in 3s and they pass.
I added this guard without making a comphehensive assessment of that class' concurrency model/assumptions. I still need to do that. (although Howard has obviously already inspected it).
Which brings me to practical matters, are you willing to distribute the unittests you submited under the Apache License 2.0? If you are, I would commit them to the HQ code tree.
+1
This shows again how important a good unittest can be.
How can you explain any bug without a good unit test? Particularly race conditions and threading issues "sometimes I get this stack trace, can you fix it?" :)
Regarding the test case itself, there are no issues checking that in, although if I'd known I would have documented it a bit better, and given myself full credit!
Andy