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/

[Dennis Reedy <de...@gmail.com>]

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?  

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

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/

[Patricia Shanahan <pa...@acm.org>]

On 4/6/2013 2:04 AM, Dan Creswell wrote:
> On 6 April 2013 04:43, Dennis Reedy <de...@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.
...

If that is the situation, regardless of anything else you do, I think
you should create a point release based on the in-field release that
most of your users are using, that just fixes the Levels issue.

Patricia

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/

[Dan Creswell <da...@gmail.com>]

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

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/

[Peter Firmstone <ji...@zeus.net.au>]

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