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
