Fix[mqbs::DataStoreRecordKeyHashAlgo]: prevent trivial collisions

[678098]

mqbs::DataStoreRecordKey has 2 fields d_sequenceNum (uint64_t) and d_primaryLeaseId (uint32_t):

blazingmq/src/groups/mqb/mqbs/mqbs_datastore.h

Line 179 in 9d5ebe9

unsigned int d_primaryLeaseId;

Before this PR, we calc a hash for this class as a sum d_sequenceNum + d_primaryLeaseId converted to uint64_t:

DataStoreRecordKeyHashAlgo::operator()(const TYPE& type) const
{
    return type.d_sequenceNum +
           static_cast<bsls::Types::Uint64>(type.d_primaryLeaseId);
}

Note that these 2 fields are monotonically incremented, also, when we increment primaryLeaseId, we set sequenceNum to 0:

blazingmq/src/groups/mqb/mqbs/mqbs_filestore.cpp

Lines 6537 to 6542 in 536a3be

	if (primaryLeaseId > d_primaryLeaseId) {
	// Reset the sequence number only if primary leaseId has been bumped
	// up.
	d_sequenceNum = 0;
	}

So it's possible to have multiple colliding hashes like this:

primaryLeaseId | sequenceNum | sum (hash)
=========================================
             0 |           5 |          5
             1 |           4 |          5
             2 |           3 |          5
             3 |           2 |          5
             4 |           1 |          5
             5 |           0 |          5

Or another scenario, when an entire sequence of collisions is generated:

primaryLeaseId | sequenceNum | sum (hash)
=========================================
             1 |           0 |          1
             1 |           1 |          2
             1 |           2 |          3
             1 |           3 |          4
             1 |           4 |          5
>== primary changes, ++primaryLeaseId ==<
             2 |           0 |          2 COLLISION
             2 |           1 |          3 COLLISION
             2 |           2 |          4 COLLISION
             2 |           3 |          5 COLLISION
             2 |           4 |          6

The easy way to address this, is to left-shift d_primaryLeaseId, so this uint32_t value will be added to the highest bits of the hash:

DataStoreRecordKeyHashAlgo::operator()(const TYPE& type) const
{
    return type.d_sequenceNum +
           (static_cast<bsls::Types::Uint64>(type.d_primaryLeaseId) << 32);
}

From the real usage of this structure, we might expect small values for d_primaryLeaseId less than 1000 and d_sequenceNum up to 10s of millions:

02AUG2024_18:10:36.918 (139806285756160) INFO mqbs_filestore.cpp:4664 PartitionId [2] (cluster: local): Received SyncPt indicating rollover: [ primaryLeaseId = 520 sequenceNum = 55479461 dataFileOffsetDwords = 805266269 qlistFileOffsetWords = 206 ], at journal offset: 14131124. Initiating rollover.

So it's very unprobable that d_sequenceNumber in the hash will reach bits occupied by the shifted d_primaryLeaseId.

[678098]

#388
Related

[kaikulimu]

Good improvement!