Hello,
so far nathelper was using id column (auto-incremented for mysql) from database table location for deciding what records will be used for sending keepalive requests on a timer execution.
Practically, it was like:
id % max_partitions = current_iteration
max_partitions is computed based on number of nat ping processes and nat ping interval.
We changed the way we mark the records for sending keepalives, in order to have proper indexing -- by adding the keepalive column.
Initially I thought that can be used for keeping the partition index as well, but there is one thing that prevents it: pinging all contacts. So no matter is behind nat or not, there is the option to ping the contact. In this case, the natted state is no longer related to keepalive flag and the keepalive column cannot be used.
The solution is to add a dedicated column for partition index. I already implemented it in a separate branch, named tmp/usrloc-partion. The new code is rather small, because is only about inserting into database, the value is not used when having records in memory, therefore not needed to be loaded back in memory or updated. But it changes the database structure, by adding a new column to location table.
I think this is a fix and still ok to apply in this testing phase. There is no new feature comparing with previous stable, but making it be the same in functionality. However, I wanted to check with all devs and see other opinions. And again, it is only about db_mode=DB_ONLY for usrloc.
The alternative will be to add back the selection based on modulo over id column (that was based on a raw query), which makes it work only with mysql and postgress (like it was so in the old versions), plus, it is not suitable for indexing.
If nobody has anything against, I will merge it.
Cheers, Daniel