I think the real problem is some people haven't been reading up on
concurrency and are insufficiently informed to be able to properly
discuss the issue.
When I don't know something, I either ask someone who does, or I keep my
mouth shut so as not to look like a fool.
It's more a case of, if
I have not seen any evidence of lack of understanding. I believe there
is a genuine lack of consensus on how to deal with some of these
ordering issues.
In particular, to what extent should River live with code that will
almost always work?
The damage from export-from-constructor with final
Yes it's a difficult decision, originally when I set out to fix the issues I
found, I didn't expect to be here today, on one hand, I'd like to complete the
work I started, I've invested too much time to walk away now.
On the other hand, The community may not want it fixed.
Patricia, you're
Thank you.
- Original message -
I'll try. I really think there are three strategies that should be
considered separately:
1. Fix concurrency bugs in River code, even if the bug can only be
identified in theory, without causing any known external symptoms.
2. Externalize some or
No problem, don't beat yourself up about it.
- Original message -
Peter - I apologize. I had meant to keep my suggestion to cool down
off-list, but it appears that I failed to remove dev@river.apache.org
from the recipients when I replied.
Cheers,
Greg.
On Dec 21, 2013,
See https://builds.apache.org/job/river-qa-refactor-arm/92/
--
[...truncated 8522 lines...]
[java] Test Passed: OK
[java]
[java] -
[java]
See https://builds.apache.org/job/river-qa-refactoring/131/changes
Changes:
[peter_firmstone] Fix LeaseExpiration test synchronization
Fix FiddlerImpl thread initialization
Fix race condition in WakeupManagerTaskExceptionTest after test failure was
experienced.
Change logging in
