river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
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 04:47:51 GMT
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
> 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


>> 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.

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
> Dennis
> 1. https://github.com/DawidLoubser/blitz-javaspaces-modularised

View raw message