river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: svn commit: r1464321 - in /river/jtsk/branches/2.2: ./ asm/ qa/ qa/doc/ src-doc/static/ src/com/sun/jini/resource/ src/net/jini/config/ src/net/jini/export/
Date Sat, 06 Apr 2013 03:43:23 GMT

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.

> I've fixed all the findbugs issues, has anyone used 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?



1. https://github.com/DawidLoubser/blitz-javaspaces-modularised

View raw message