Dennis Reedy wrote:
On Apr 5, 2013, at 956PM, Peter wrote:
We can't afford to hold up 2.3.0 much longer, the 2.2.0 release has numerous
synchronization bugs, these will become more apparent on multicore hardware.
The longer we wait the more likely they'll present in deployed systems.
The latest branch is in skunk/qa-refactoring, I encourage anyone to jump in and
help. We're currently investigating replacing TaskManager. This branch passes
all TCK tests, we just need to fix remaining synchronization issues.
Because changes have a ripple effect, one fix will expose other bugs because execution paths change. It's probably better that we fix these issues while the build is monolithic, otherwise there are more possible combinations that would require additional integration testing.
I proposed a modular build 2 years ago, but developers were divided over it at that time.
I'm all for this [1] It's straight forward, mostly grunt work to break out the
modules and make sure everything builds and works. The big question is whether
the project can stomach Maven or not. That being said, just need to know what
branch you want me to base River modularization on and I'll start. However,
before that effort starts we need a release of what is out now.
Ok, lets look at it again after 2.3.0. BTW your artifact: URI is
RFC3986 compliant, it's actually URN syntax (apologies for the slow
answer). Previously codebase annotations were space delimited URL, but
they've been change to space delimited RFC3986 compliant URI in 2.3.0.
This change was made because the codebase URL's were used as key's in
Map, so the DNS cache was consulted for every hashCode call.
BTW, how does the ClassLoader hierarchy work with Maven and smart proxy's?
Something else I thought was worth mentioning was a package names for
ServiceAPI should be different than their implementations, to avoid
issues with sealed packages existing in different ClassLoader's.
I've fixed all the findbugs issues, has anyone used JPF?
JPF?
Java Path Finder
http://babelfish.arc.nasa.gov/trac/jpf/
I'm going to try this after we've fixed TaskManager.
A TaskManager fix or replacement with Executors? Was just looking for usages of
runAfter(), initial look seems the only use is in ServiceDiscoveryManager. So
is runAfter() a YAGNI issue?
It's much more prevalent than that.
See
https://issues.apache.org/jira/secure/attachment/12577348/TaskManager_uses.pdf
for more details.
I figured if we tackle the most complex use cases first, since these are
more likely to produce errors, then leave the simple cases that don't
use runAfter until after the next release.
Regards,
Peter.
Regards
Dennis
1. https://github.com/DawidLoubser/blitz-javaspaces-modularised
