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 <p...@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
