LocalMemberCache should have a choice to use Reliable Topic or Topic

[jontejj]

http://docs.hazelcast.org/docs/latest/manual/html-single/index.html#reliable-topic

If the reliable topic is configured with BLOCK, there's less risk of hazelcast being overloaded (and possibly out of memory) if one member starts to publish lots of events.

Some sacrifices in performance could be worth it to have a higher degree of cache consistency and resistance to failures?

[jontejj]

Looking at hazelcast/hazelcast@ed4c630 it suggests that ringbuffer should also be configured, I don't yet know what would be good defaults to recommend though. @pveentjer maybe you can provide some pointers here?

[mesutcelik]

Hi @jontejj ,
This is not a good place to ask questions. Especially not related to hazelcast-hibernate module. Can you please ask the question in Hazelcast Google Groups?

[jontejj]

It's hazelcast-hibernate (LocalMemberCache) that is using the regular getTopic instead of getReliableTopic. So surely, this is a hazelcast-hibernate issue. Can you reopen this issue? My question to @pveentjer was more about recommendations for how to use that feature as he developed it.

[pivovarit]

That one looks outdated therefore closing. We're not planning to change the architecture of local region caches, but if you think we should, please bring it up.

[jontejj]

How is the problem of losing potential cache invalidations if the node running this local cache goes down dealt with? Only with reliable topic can the cache invalidations actually be trusted to be published properly. Is using a reliable topic problematic? Worried about performance degradations? In that case an option to use a reliable version would be great.

[pivovarit]

When you choose to use local caching, you sacrifice a bit of consistency for the sake of performance. Local region caches are pretty much local in-memory data structures with invalidations being broadcasted on the best-effort basis.

Generally, it's not a tragedy if a message is lost because the eventual consistency is still there since entries would expire due to their TTL anyway. Ideally, each invalidation message would share the same TTL as the invalidated record, there's no point in processing an invalidation message for something that already expired.

Naturally, ensuring reliability comes with a cost, but I agree with you that it would be great to have a choice.

I will keep the issue open and change the title a bit to reflect that.

[jontejj]

Sounds very reasonable to me. Thanks!

[pivovarit]

Just let me provide additional context here. We're aware of the design deficiencies of the RingBuffer backing the implementation of ReliableTopic, and there are plans to rework it, and then we'd happily switch permanently.