Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (athena.apache.org: domain of dan.creswell@gmail.com
 designates 209.85.219.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BC18EA8B-D53F-41E9-8E44-CD0BB6ECFA81@gmail.com>
References: <20130404073254.F2D1023888E7@eris.apache.org>
	<1365061347.13775.142.camel@cameron>
	<1365213374.6614.17.camel@Nokia-N900-51-1>
	<BC18EA8B-D53F-41E9-8E44-CD0BB6ECFA81@gmail.com>
Date: Sat, 6 Apr 2013 10:04:04 +0100
Message-ID: 
 <CAMPUXz_=Kscvp234Gjca5M+S5n=GM1T9CB+h2Su8Mk-CvE+=mg@mail.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/
From: Dan Creswell <dan.creswell@gmail.com>
To: dev@river.apache.org
Cc: Peter <jini@zeus.net.au>
Content-Type: multipart/alternative; boundary=f46d044789054b4f6404d9ad7cb5

--f46d044789054b4f6404d9ad7cb5
Content-Type: text/plain; charset=ISO-8859-1

On 6 April 2013 04:43, Dennis Reedy <dennis.reedy@gmail.com> 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.
> >
>

They'll be apparent already in previous builds too. As much as they are
going to be. We've certainly had the odd complaint from those shunting big
load but there are a lot of Blitz users out there doing what they're doing
and not hitting problems.

I see way more complaining from the community in respect of Levels.

I guess what I'm saying is, this is about needs. The community is shouting
loud about one particular need and it's not the concurrency stuff though
you and I both know it will become more of a problem (how much more, we
cannot know, nature of the concurrency beast. You can run for years with no
problems and then hit the same issue 20 times in an hour).


> > 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'd say we need to get a release cycle going with some smaller bits which
naturally leads to the need for some form of "modularization". In this
though, I think it's a red herring to focus on that, the real issue at hand
is too many changes, not enough releases. We've (well Peter has in the
majority to be fair) done concurrency work, security work, test framework
overhaul and some bugfixes. That's way too much for a single release.

And yeah, I've got my hindsight glasses on. Nevertheless we can't hide from
the problem, we should address it straight on.

I believe we have a stable build and an experimental build (call them
branches if you like 2.2.x and 2.3.x). We should get 'em both out the door
and then we can choose where we want to work on the modularization work.

[ Personally I don't rate maven all that highly but then I don't rate any
of the other build tools highly either. It's just "the standard". XML?
Really? Nevertheless, time has clarified things somewhat as the Java
modularization JSR's have basically died a death which means there's really
only one "standard" for this now. And though I dislike Maven, it has, at
least in 3.0 to my mind, become rather more tractable as a tool ]

>
> > I've fixed all the findbugs issues, has anyone used JPF?
>
> 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?
>
> Regards
>
> Dennis
>
> 1. https://github.com/DawidLoubser/blitz-javaspaces-modularised
>
>

--f46d044789054b4f6404d9ad7cb5--