"In addition, the names of Hazelcast’s datatypes, and the functions provided on those types, imply a certain fitness-for-purpose, e.g. that users can use these types and functions in a meaningful way. What is the point of an ID Generator which emits duplicate IDs? A lock that doesn’t lock? Who wants an AtomicReference which is not atomic? Of what possible use is a queue which doesn’t, well, queue?"<p>Wow. I wonder if the documentation and naming schemes are bad because they're aspirational, or because the developers don't know what they're doing?
Is there some award Jepsen and Aphyr can be nominated for? Kyle's work has improved so many open source projects it needs acknowledgement.<p>Also, his Twitter is a great thing for confusing people who want to read about lock schemes and relationship management etc...
Hazelcast has officially responded to the Jepsen Analysis here. <a href="https://blog.hazelcast.com/jepsen-analysis-hazelcast-3-8-3/" rel="nofollow">https://blog.hazelcast.com/jepsen-analysis-hazelcast-3-8-3/</a>
For anyone wondering if there is a set of Hazelcast like data structures and primitives that actually have safe, strong consistency (based on Raft consensus), check out Atomix:<p><a href="http://atomix.io/atomix/" rel="nofollow">http://atomix.io/atomix/</a>
Ouch. (Someone please give this guy an industry medal.)<p>Talk of Hazelcast reminded me of Coherence (now Oracle, before Tangosol): <a href="https://www.javalobby.org//java/forums/t78008.html" rel="nofollow">https://www.javalobby.org//java/forums/t78008.html</a><p>Oracle docs sensibly call it a distributed cache:
<a href="http://www.oracle.com/technetwork/middleware/coherence/distributed-caching-100021.html" rel="nofollow">http://www.oracle.com/technetwork/middleware/coherence/distr...</a>
We use Hazelcast at Verizon Labs for a couple services, and one of the issues we ran into is how much <i>work</i> it takes to replicate split brain to test various and custom merge policies.<p>When reading that the distributed map implements the ConcurrentHashMap interface we were immediately skeptical, but it took more work to prove our skepticism was founded.<p>Hazelcast has a <i>fantastic</i> foundation for building clustered applications, but some of the design choices they made both internally and API wise are not choices we would have made.<p>We are moving to a custom merge policy because of some of these choices.
If a system is so "broken by design", shouldn't it include a flag for running under worst-case mode, so that users can more easily detect faults in their assumptions about the system?
Wait, is this Kyle Kingsbury? If so, where is his name? Who are the authors? I notice this text doesn't mention the authors:<p>"We wish to thank Jordan Halterman for his discussion of Hazelcast use cases. Luigi Dell’Aquila & Luca Garulli from OrientDB, and Denis Sukhoroslov from BagriDB, were instrumental in understanding those systems’ use of Hazelcast. Thanks also to Julia Evans, Sarah Huffman, Camille Fournier, Moishe Lettvin, Tim Kordas, André Arko, Allison Kaptur, Coda Hale, and Peter Alvaro for reading and offering comments on initial drafts. This research was performed independently by Jepsen, without compensation, and conducted in accordance with the Jepsen ethics policy."<p>I'd like to know who stands behind this research
It's going to take me a while to go through all of this, so I'll miss the boat on the HN comments<p>However, I'd really like to credit the author on the design of the site, a pleasure to read.
Question: why do we still use sequential ID's for identifying objects in data stores? There are many known problems with using numeric ID's (anyone remember Twitter's overflow issue), so when they are sent to a remote system, they should probably be strings anyways. Sorting or doing math on ID's is basically useless. Memory savings are the only thing I can think of, and while yes that's a nice feature, when a cluster of N nodes is generating ID's that are supposed to be globally unique, aren't UUID-type things better?
Is this use of Hazelcast in Apero CAS safe? It is built on IMap.
<a href="https://apereo.github.io/cas/5.1.x/installation/Hazelcast-Ticket-Registry.html" rel="nofollow">https://apereo.github.io/cas/5.1.x/installation/Hazelcast-Ti...</a>
We have been using Hazelcast for a while now. Currently evaluating K tables if we could get the same performance. Any learnings or advices would be welcome if anyone has done the switch.
Fairly brutal for a Jepsen report.<p>What fascinates me about the now-known-to-be-untrue claims in the Hazelcast documentation is that the claims were made despite the developers having know way of knowing if they were true because they’d not conducted these kinds of tests themselves.<p>Documentation that reflects what the developers wish were true rather than what is actually true is not a new phenomenon, but is potentially fatal for this kind of software.