river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: Progress, and a problem
Date Fri, 03 Dec 2010 16:33:33 GMT
HazelCast provides an in memory data grid, but I'm pretty sure it has no implementation of
JavaSpace or JavaSpace05, and from what I can tell does not include any Jini technology whatsoever.

On Dec 3, 2010, at 1109AM, Mike McGrady wrote:

> Do not forget HazelCast.  The spaces concept is on the upswing in my opinion.  
> 
> Sent from my iPhone
> 
> Michael McGrady
> Principal investigator AF081_028 SBIR
> Chief Architect
> Topia Technology, Inc
> Work 1.253.572.9712
> Cel 1.253.720.3365
> 
> On Dec 3, 2010, at 7:43 AM, Patricia Shanahan <pats@acm.org> 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.
>> 
>> 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.
>> 
>>> 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.
>> 
>> Patricia


Mime
View raw message