#49619 adjustment of csn_generator can fail so next generated csn can be equal to the most recent one received
Closed: wontfix 5 years ago by mreynolds. Opened 6 years ago by tbordaz.

Issue Description

On consumer side csn_generator ajustment occurs (let CSN = highest known csn)

  • when a replication session starts
  • when a csn is generated locally and than csn is <= CSN

During adjustment, in the case

  • there is no remote/local offset (time change)
  • the current_time on the consumer is identical to CSN

Then next locally generated csn will only differ with seqnum

The seqnum of the csn_generator is increased only if CSN.seqnum is larger
than the csn_generator one.
In case of egality, it remains unchanged.

The consequence is that the next locally generated csn will be identical to CSN (except for the RID). So even after csn_generator adjustment, csn_generator may create csn that are not larger than the CSN

Package Version and Platform

All versions

Steps to reproduce

  1. see FREEIPA-921

This is a timing issue, so it is not systematic. Now on the test systems it happens one time out of two.

Actual results

The generated csn can be lower than the highest known csn and urp can order operations in the opposite way.

Expected results

generated csn should strictly be larger than the most recent one received


Metadata Update from @tbordaz:
- Custom field component adjusted to None
- Custom field origin adjusted to IPA
- Custom field reviewstatus adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None

6 years ago

Metadata Update from @tbordaz:
- Issue assigned to tbordaz

6 years ago

The attached patch is still under tests.
Before the failure happened 1 time out of 2.
With the patch, it runs successfully 10 times (continuing the tests up to 20 runs)

Metadata Update from @tbordaz:
- Custom field reviewstatus adjusted to review (was: None)

6 years ago

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to ack (was: review)

6 years ago

@mreynolds thanks for the review. The tests complete successfully so I think it is okay to push the patch. Now it has not been triaged yet. It applies to all branches. Is it okay to push it master/1.3.7/1.3.6/1.2.11 ?

@mreynolds thanks for the review. The tests complete successfully so I think it is okay to push the patch. Now it has not been triaged yet. It applies to all branches. Is it okay to push it master/1.3.7/1.3.6/1.2.11 ?

yes that is fine

To ssh://pagure.io/389-ds-base.git
5ba0181..5bfe2a3 master -> master
To ssh://pagure.io/389-ds-base.git
485cf0c..d5e2f74 389-ds-base-1.3.7 -> 389-ds-base-1.3.7
To ssh://pagure.io/389-ds-base.git
73ba039..92c4c2a 389-ds-base-1.3.6 -> 389-ds-base-1.3.6

Finally not committed to 1.2.11

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1559945

6 years ago

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.3.7.0

6 years ago

Metadata Update from @mreynolds:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

5 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2678

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

4 years ago

Log in to comment on this ticket.

Metadata