river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: Progress, and a problem
Date Sat, 04 Dec 2010 13:31:00 GMT
Dan has some interesting ideas on doing remote testing on a single
machine.  Some of them we could possibly adapt to our needs/use.


Obviously, there might/probably/definitely be some QA and/or River
refactoring that needs to doing before we can do any of the stuff he
suggests.  Personally, I'd be tempted to take a test we want to run
remotely, duplicate it, and refactor it to get what we want.  But
then, I'm always in favour of adding additional tests...

On Sat, Dec 4, 2010 at 2:51 AM, Peter Firmstone <jini@zeus.net.au> wrote:
> 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?
> Peter.

View raw message