Visitor tasks print the wrong vBucket in the Slow runtime warnings

Any tasks using the VBCBAdapter and log slow runtimes like the following:

2024-03-14T01:18:31.640086+07:00 WARNING (com.amdocs.digital.ms.productorder.productorder) Slow runtime for 'Expired item remover on vb:568' on thread NonIoPool1: 944 ms

Will print the vBucket number of the next vBucket that is on that node. In the example above, we print "Expired item remover" and we say "on vb:568", but actually, the task hasn't run for vb:568. vb:568 is just the next vBucket that we need to run for.

The actual slowness was on the vBucket "before" 568 on that node. It could be 567, or it could be something else, depending on the vBucket map at the time. This is important in cases where a vBucket is locked by an ongoing operation.

For support

This applies only to the following tasks:

• "Item Access Scanner on vb:N"
• "Checkpoint Remover on vb:N"
• "DurabilityTimeoutVisitor on vb:N"
• "Hashtable resizer on vb:N"
• "Item pager on vb:N"
• "Expired item remover on vb:N"

—

This is caused by the following logic in the task:

    while (!vbucketsToVisit.empty()) {

        const auto vbid = vbucketsToVisit.front();

        VBucketPtr vb = store->getVBucket(vbid);

        if (vb) {

            currentvb = vbid.get();            <Maybe pause task here>

            visitor->visitBucket(*vb);

        }

        vbucketsToVisit.pop_front();

    }

At the point that we pause currentVb is set to the next vBucket to visit. But the log message is always generated by "TaskName on vb:currentVb", so it contains the next vBucket to visit.