potential clash while tracking pending requests in CaliforniumLwM2mRequestSender

[balsmn]

CaliforniumLwM2mRequestSender uses a ConcurrentNavigableMap#L57 for tracking pendingRequests before sending it using a coap endpoint. The key is of the format registrationId#requestId and the key generation uses hashCode()#L257

I suppose, the implementation assumes the hashCode to be unique to track pendingRequests and I assume it is implemented in this way to avoid use of ConcurrentMap<String, Collection<requestId>> for tracking all pending requests for a given registrationId. If the assumption is correct, then it is really clever way of doing it. 👍

Only one problem to it. Unfortunately the hashCode is not implemented and left to the default java Object's implementation.

Now as per java doc of hashCode

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the Java(tm) programming language.)

However, when on morden machines we have 64 bit address space and when mapped to 32 bit integer we will have clashes in hashCode. Also the hashCode algorithm can be influenced using the java VM parameter like -XX:hashCode=2 (which always returns 1 for all hashCode() calls).

The hashCode alogirthm also differs widely from Java 7 to Java 8.

[sbernard31]

Good catch.
What do you propose to replace hashcode() ? UUID ?

[balsmn]

Yes, we can use UUID in that place to maintain the uniqueness

[sbernard31]

It seems default java UUID is not so efficient
(We probably don't care for now as we probably faced more important performance issue)

Did you faced the problem you described ?