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: Progress, and a problem
Date Sat, 04 Dec 2010 02:51:39 GMT
Gregg Wonderly wrote:
> On 12/3/2010 9:43 AM, Patricia Shanahan wrote:
>> Gregg Wonderly wrote:
>>> Many people are using Dan Creswell's Blitz JavaSpaces implementation or
>>> commercial versions. I'm partially inclined to suggest that we 
>>> should discuss
>>> EOL of outrigger at some point. Even though Javaspaces
>>> is a large part of what Jini has been recognized for, it has a focused
>>> audience and if we don't have someone with knowledge and interest to 
>>> support
>>> outrigger, it may be more of a wart than River can deal with.
>> Although I have limited multi-processor Java and River experience, I do
>> have the right general background for that mission. I've got decades of
>> system performance experience, including finding bottlenecks in
>> multiprocessor operating systems, I understand memory models, and I have
>> the academic computer science education to look for and understand the
>> latest research on concurrent data structures.
> I do believe you can dive in and do the discovery needed if you have 
> that interest.
>> On the other hand, if we are merely duplicating functionality that is
>> already available from other sources, that may not be the best use of my
>> River time.
> The other JavaSpaces implementations are just that.  I did say I was 
> partially inclined to make this suggestion.  I'm not at all interested 
> in pushing outrigger out of the nest, really.  I just don't want 
> anyone to spend too much time on one facet of River that there are 
> actually other usable open source implementations of, if we don't have 
> bandwidth to do it.
>>> One of the issues that I've found in network intensive applications, 
>>> is that
>>> the latency of communications is so huge compared to code paths, 
>>> that all
>>> active threads will fairly quickly end up hovering on
>>> top of any use of "synchronized" so that there is always the worst case
>>> contention for such protected resources.
>> Communications latency is something that seriously worries me in the
>> current QA strategy, in which all components run on the same system. We
>> are not testing with the sort of timing and contention issues our real
>> world users will experience. There is a risk of not finding bugs that
>> only happen with timings induced by communications latency, as well as
>> not noticing performance regressions.
> I'm glad we both have this worry.  It is important and until you see 
> it happening, it's hard to understand.  I've spent a lot of time at 
> the shell prompt typing ^\ digging through stack traces, chasing down 
> contention issues and its not my idea of a fun time compared to 
> writing useful code.
> Gregg Wonderly

Good point, anyone got any ideas for spreading the qa tests over 
multiple computers in a network?


View raw message