Hash ode map json deduplication#11
Conversation
drewjj
left a comment
drewjj
left a comment
There was a problem hiding this comment.
Just a few questions. Looks good, though.
Michael7371
left a comment
Michael7371
left a comment
There was a problem hiding this comment.
LGTM, just noticed an outdated comment.
| List<KeyValue<String, OdeMessageFrameData>> mapDeduplicationResults = outputOdeMapData | ||
| .readKeyValuesToList(); | ||
|
|
||
| // validate that only 3 messages make it through |
There was a problem hiding this comment.
chore: stale comment, update to 4 messages.
| int oldHash = Objects.hash(lastMessage.toString()); | ||
| int newHash = Objects.hash(newMessage.toString()); | ||
|
|
||
| if(oldHash != newHash){ |
There was a problem hiding this comment.
issue: the hash can have collisions.
suggestion: test object equality instead. Either using 'toString' if there is some reason to do that (not sure if there is):
lastMessage.toString().equals(newMessage.toString())or use the 'equals' method defined on OdeMessageFrameData (by the @EqualsAndHashCode annotation on OdeData):
lastMessage.equals(newMessage)There was a problem hiding this comment.
The two objects being compared are different objects, with different nested elements. ToString is used as a quick way to ensure I am comparing the content of the object as opposed to the memory pointers.
Using the message hash's instead of the messages themselves was selected for performance reasons. From my testing it takes about 1 ms to compare the message hashes from the strings compared to about 3ms to perform string comparison on the strings. While a collision is possible it is quite unlikely given that MAP messages change very infrequently.
In the event that a collision did happen, the impact is fairly minimal. The original MAP would be retained for at most 1 additional hour, before the new MAP message takes over anyway.
4 participants
This PR updates the logic in the OdeMapJson deduplication topology so that it will forward a new MAP message if the new map message is different from the previous message. Previously, a new OdeMapJson message would only be forwarded if it happens more than 1 hour after the preceeding message. After this update, a new OdeMapJson message will also be forwarded if it has different contents than the previous MAP message. For example, if the new message has different lane ID's or geometries it will be forwarded regardless of how long after the previous message the new message occurred. This update changes the OdeMapJson topology logic to be more in line with how the ProcessedMap and other topologies operate. As with the ProcessedMap topology, this update ignores changes to the ASN.1, odeReceivedAt, and MOY fields since these fields are expected to change frequently and do not necessarily correspond to a change in the intersection geometry.