org.jivesoftware.util.cache.Cache has different characteristics when HZ clustered

Openfire Openfire Dev
1

When running in the old-style Coherence cluster, or non-clustered, a Cache object will happily take a null key (when non-clustered, it’s backed by DefaultCache, a wrapper around a plain-old HashMap).

Unfortunately, the Hazelcast backed Cache will not take a null key;

java.lang.NullPointerException: Null key is not allowed!

at com.hazelcast.util.Preconditions.checkNotNull(Preconditions.java:41) ~[?:?]

at com.hazelcast.map.impl.proxy.MapProxyImpl.get(MapProxyImpl.java:79) ~[?:?]

at org.jivesoftware.openfire.plugin.util.cache.ClusteredCache.get(ClusteredCache.j ava:92) ~[?:?]

at org.jivesoftware.util.cache.CacheWrapper.get(CacheWrapper.java:140) ~[openfire.jar:?]

I think that the clustered and non-clustered maps should be consistent; I’m happy to submit a patch request to DefaultCache to reject null keys/values just like the Hazelcat map, if it would (in principle) be accepted.

OK, so it’s a bug in my code that’s triggered this, I just would have found it quicker had the behaviour been consistent between the two Cache implementations.

Greg

2

That’s enough of an edge case for me to assume that those (third party) implementations that make use of null-keys are very few in number. I’d prefer consistency, and would welcome a pull request.

I’ve created this issue in our bugtracker for this: [OF-1156] Cache implementations should have consistent behavior regarding null keys - IgniteRealtime JIRA

3

Thanks for the PR ( OF-1156: Be consistent with the contents of DefaultCache with the HZ cache by GregDThomas · Pull Request #609 · ignitere… )

Your fix has been merged, and should be part of the 4.1.0 release.