https://bugzilla.redhat.com/show_bug.cgi?id=158593
Description of problem: While running Reliability 16 I noticed a bunch of errors in the master error logs for each of the three masters. --------------------------------------------------------- [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE2_M2C1" (babylon5:9002): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE2_M2C2" (galadriel:9002): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE3_M2M1" (gamgee:9002): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE3_M2M3" (oceanus:9002): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE3_M2C1" (babylon5:9002): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE3_M2C2" (galadriel:9002): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE4_M2M1" (gamgee:9001): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE4_M2M3" (oceanus:9001): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE4_M2C1" (babylon5:9001): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE4_M2C2" (galadriel:9001): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE5_M2M1" (gamgee:9001): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE5_M2M3" (oceanus:9001): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE5_M2C1" (babylon5:9001): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE5_M2C2" (galadriel:9001): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE6_M2M1" (gamgee:9001): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE6_M2M3" (oceanus:9001): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE6_M2C1" (babylon5:9001): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE6_M2C2" (galadriel:9001): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE7_M2M1" (gamgee:9001): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE7_M2M3" (oceanus:9001): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE7_M2C1" (babylon5:9001): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE7_M2C2" (galadriel:9001): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [21/May/2005:00:00:00 -0700] NSMMReplicationPlugin - agmt="cn=RA_BE8_M2M1" (gamgee:9001): Incremental protocol: event update_window_opened should not occur in state wait_for_changes ----------------------------------------------------------------- They all occured at midnight or 1 minute past midnight. Version-Release number of selected component (if applicable): 20050518.3.qa How reproducible: always - given the right circumstances Steps to Reproduce: 1. Run reliab 16 2. 3. Actual results: We see these error messages Expected results: We shouldn't Additional info: The problem, Nathan has found out, is that if the schedule item crosses a day boundary we will get this error because we have not implemented code to cover this case. There is a comment at the top of repl5_schedule.c that says this: /* ONREPL - I made a simplifying assumption that a schedule item does not cross day boundaries. Implementing this is hard because we search for the items for a particular day only based on the item's staring time. For instance if the current time is tuesday morning, we would not consider the item that started on monday and continued through tuesday. To simulate an item that crosses day boundaries, you can create 2 items - one for the time in the first day and one for the time in the second. We could do this internally by allowing items do span 2 days and splitting them ourselves. This, however, is not currently implemented */ It does look like a the issue is that we have a schedule item that is crossing a day boundry. -NGK
batch move to milestone future
set default ticket origin to Community
Added initial screened field value.
Metadata Update from @nkinder: - Issue set to the milestone: FUTURE
I am just commenting to state my interest in having replication be able to process during all of the 1440 minutes of each day, rather than only 1439 minutes of replication per day. From an outside perspective, it seems like it'd be pretty easy to do. From the perspective of someone who's looked at some of the 389-ds code, I wish whomever tackles this all the luck they need. (To be fair, I've only looked at other parts, but it's been made very clear to me that directory software has a lot more details which must be tracked and handled than I could possibly imagine.)
Hi @edgrimm,
I believe that replication does already work for all 1440 minutes of a day. I think this issue specifically is related to replication scheduling when you want valid time windows for replications to occur, and when those time windows cross day time boundaries. IE you can only have the schedule between 00:00 to 23:59, but not say ... 22:40 to 4:30 crossing midnight.
Given this issue is 7 years old, I'm not sure any interest still exists in fixing this. @mreynolds Do you think we should close this as "wont fix" given the lack of interest?
If you have a specific replication @edgrimm please email us on 389-users or report a new issue so we can investigate!
Thanks,
Metadata Update from @firstyear: - Custom field reviewstatus adjusted to None (was: Needs Review) - Issue close_status updated to: None
Metadata Update from @mreynolds: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
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/228
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.