You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't know if it is discussed before. Our code samples use internal API, which caused compile problem in this release when changed. Fixed here https://github.com/hazelcast/hazelcast-code-samples/pull/303/files
The reason of usage seems to demonstrate some features are working. And it resembles our unit tests.
I think the code sample does not need that much verification. Since it is to show how hazelcast should be used, it is giving wrong advice.
I see generateKeyOwnedBy usage. I don't think we are advising this to our users. Make sense for tests but users should use affinity features instead of generating the key for a specific partition. And interestingly, this also accesses to node.
I think we also need rules for using assertions. We have the following methods on Common Utils. My gut feeling says that code samples should not do assert.
.assertClusterSizeEventually;
.assertEquals;
.assertOpenEventually;
I am keen to do the following System.out.println(cache1.get("key1"));//prints 'value'
instead of assertEquals("value",);
Lastly, I see abstract class usages too much. Especially around SplitBrainSamples. I think code samples should be one class and simple. Using abstractions to demonstrate simple usages will scare of the users. This again seems to be caused by simulating the split brain. When we remove that part, abstractions will go away too.
The text was updated successfully, but these errors were encountered:
I don't know if it is discussed before. Our code samples use internal API, which caused compile problem in this release when changed. Fixed here https://github.com/hazelcast/hazelcast-code-samples/pull/303/files
The reason of usage seems to demonstrate some features are working. And it resembles our unit tests.
I think the code sample does not need that much verification. Since it is to show how hazelcast should be used, it is giving wrong advice.
Heaviest usage is around simulating the split brain. That requires access to
node
. I think this should not be part of the code samples. Configuring split brain on code samples make sense. But simulating the behavior I think is part of the unit tests.https://github.com/hazelcast/hazelcast-code-samples/blob/master/jcache/src/main/java/com/hazelcast/examples/splitbrain/AbstractCacheSplitBrainSample.java#L105
I see
generateKeyOwnedBy
usage. I don't think we are advising this to our users. Make sense for tests but users should use affinity features instead of generating the key for a specific partition. And interestingly, this also accesses tonode
.I think we also need rules for using assertions. We have the following methods on Common Utils. My gut feeling says that code samples should not do assert.
.assertClusterSizeEventually;
.assertEquals;
.assertOpenEventually;
I am keen to do the following
System.out.println(cache1.get("key1"));//prints 'value'
instead of
assertEquals("value",);
Lastly, I see abstract class usages too much. Especially around SplitBrainSamples. I think code samples should be one class and simple. Using abstractions to demonstrate simple usages will scare of the users. This again seems to be caused by simulating the split brain. When we remove that part, abstractions will go away too.
The text was updated successfully, but these errors were encountered: