river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: Bug nominations
Date Wed, 09 Feb 2011 23:13:59 GMT
On 2/9/2011 7:41 AM, Brian Murphy wrote:
> On Tue, Feb 8, 2011 at 1:17 PM, Patricia Shanahan<pats@acm.org>  wrote:
> I don't really know enough about River yet to contribute to a lot of the
>>   futures discussions. On the other hand, I can track down and fix bugs, and
>> doing so helps me learn about more areas.
> You seem to me have that increasingly rare respect for
> code you didn't originally write; where you dig deep into the
> code to understand intent as well as function before declaring
> something broken and needing whole-house changes. Your
> work with FastList was exemplary. For what it's worth, FastList
> was always on the old JavaSpace team's hit list of things that
> needed to be re-done; for the exact reasons you've identified.
> Unfortunately, there was always some higher priority that needed
> to be addressed first. But your analysis of the issues seemed
> to be spot on.

The choice between fixing an almost-working implementation and rewriting 
using new facilities is always a difficult one, just because there can 
be so much temptation to rewrite. It's reassuring to know that FastList 
was on the hit list already.

>> Any opinions on what I should go after next?
> With respect to attracting users, speaking from personal experience,
> I think people would be surprised by the number of companies
> using river in their products (for example, my previous company and
> my current company). But the fact that Outrigger and Mahalo are single
> points of failure is an issue when deciding on a service based
> infrastructure; just as the NameNode is similarly an issue for Hadoop.
> I suspect then that providing replicated, fault-tolerant implementations
> of those two services would at least remove one of the reasons
> for rejecting river.
> For what it's worth, one of my personal regrets is that we did
> the LookupDiscoveryService (Fiddler) and the LeaseRenewalManager
> (Norm) instead of focusing on replicating Outrigger and Mahalo;
> although I do believe that the EventMailbox (Mercury) has great
> value. Of course, hindsight is 20-20, but it seems like river is
> providing the opportunity for a "do-over". So maybe the stars
> are aligning for this sort of work.
> The fact that you've been digging deep into the Outrigger code,
> and the fact that Dan Creswell has re-engaged means that, with
> respect to JavaSpace implementations in particular, we have two
> very knowledgeable, motivated, people now participating. Maybe the
> starting point might even be with the Blitz implementation, instead
> of Outrigger.

What do others think of this general idea, as a development direction 
for River?

As Brian says, it could be implemented in parallel with the Internet 
idea. I think it is complementary. In the Internet world there is a 
significant risk of losing access to a server without the sort of total 
collapse of the infrastructure that would doom the application anyway.

A fault-tolerant transaction manager would be both useful in its own 
right, and potentially useful in maintaining coherence among replicated 
JavaSpaces. I'm not so sure a fault-tolerant JavaSpaces would be 
meaningful without a fault-tolerant transaction manager. For that 
reason, it seems to me that TransactionManager should come before 


View raw message