Back to bug 1898541
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Red Hat Bugzilla | 2020-11-17 13:19:11 UTC | Pool ID | sst_identity_management_rhel_8 | |
| Red Hat One Jira (issues.redhat.com) | 2020-11-17 15:15:15 UTC | Link ID | Red Hat Issue Tracker - Private RHELPLAN-59746 | |
| RHEL Program Management | 2020-12-08 18:50:31 UTC | CC | mreynolds | |
| Whiteboard | sync | |||
| Keywords | Triaged | |||
| Têko Mihinto | 2020-12-10 16:03:39 UTC | Status | NEW | ASSIGNED |
| Whiteboard | sync | sync-to-jira | ||
| CC | tmihinto | |||
| thierry bordaz | 2020-12-14 10:10:19 UTC | Status | ASSIGNED | POST |
| Chris Zinda | 2021-01-07 19:58:41 UTC | CC | czinda | |
| Red Hat One Jira (issues.redhat.com) | 2021-01-07 20:02:06 UTC | Link ID | Red Hat Issue Tracker - Private IDMDS-988 | |
| thierry bordaz | 2021-01-12 16:15:10 UTC | Link ID | Github 389ds/389-ds-base/issues/4492 | |
| Libor Miksik | 2021-01-18 16:47:38 UTC | CC | lmiksik | |
| Marc Sauton | 2021-01-21 07:57:00 UTC | Link ID | Red Hat Issue Tracker - Private IDMDS-1057 | |
| CC | sgouvern | |||
| CC | msauton | |||
| Oneata Mircea Teodor | 2021-01-25 11:22:29 UTC | CC | toneata | |
| Flags | needinfo?(msauton) | |||
| thierry bordaz | 2021-01-25 12:43:31 UTC | Flags | needinfo?(toneata) | |
| Oneata Mircea Teodor | 2021-01-25 13:12:57 UTC | Flags | needinfo?(toneata) | |
| Kaushik Banerjee | 2021-04-13 10:46:35 UTC | Blocks | 1921861 | |
| Pool ID | sst_identity_management_rhel_8 | sst_idm_ds_rhel_8 | ||
| errata-xmlrpc | 2021-05-14 19:49:00 UTC | Status | POST | MODIFIED |
| Fixed In Version | 389-ds-1.4-8050020210514191740-d5c171fc | |||
| Status | MODIFIED | ON_QA | ||
| Akshay Adhikari | 2021-06-02 14:59:46 UTC | CC | aadhikar | |
| thierry bordaz | 2021-06-16 10:33:52 UTC | Status | ON_QA | VERIFIED |
| Blocks | 1972626 | |||
| thierry bordaz | 2021-06-17 13:00:42 UTC | Blocks | 1972738 | |
| Marc Muehlfeld | 2021-10-12 07:07:27 UTC | Doc Type | If docs needed, set a value | Bug Fix |
| Docs Contact | mmuehlfe | |||
| Robin Cain | 2021-10-18 18:21:59 UTC | CC | rcain | |
| Keywords | TestCaseNotNeeded | |||
| Petr Hybl | 2021-10-29 07:46:58 UTC | CC | ldap-maint, phybl | |
| Flags | needinfo?(ldap-maint) | |||
| Docs Contact | mmuehlfe | phybl | ||
| thierry bordaz | 2021-10-29 14:28:22 UTC | Assignee | ldap-maint | tbordaz |
| Flags | needinfo?(tbordaz) | |||
| Doc Text | Cause: Changelog contains updates. If an update is very large (several MB) and a replication session tries to start from such update then the replication session actually starts from beginning of the changelog. Consequence: If the changelog of a host contains many updates before the expected starting point, then replication from the host appears very slow. Fix: The fix is to make sure that a replication session uses a buffer large enough to store the update that is at the starting point Result: The replication session starts immediately sending updates. | |||
| Flags | needinfo?(msauton) needinfo?(ldap-maint) needinfo?(tbordaz) | |||
| Petr Hybl | 2021-11-04 10:35:00 UTC | Doc Text | Cause: Changelog contains updates. If an update is very large (several MB) and a replication session tries to start from such update then the replication session actually starts from beginning of the changelog. Consequence: If the changelog of a host contains many updates before the expected starting point, then replication from the host appears very slow. Fix: The fix is to make sure that a replication session uses a buffer large enough to store the update that is at the starting point Result: The replication session starts immediately sending updates. | .Replication session was slow is now fixed Previously when the changelog contain updates that were larger, the replication session starts from the beginning of the changelog. This seemed to be slow. It was caused by a small buffer that was assigned for a replication session. You have to check that the replication session has a buffer large enough to store the update that is at the starting point. The replication session starts immediately sending updates. |
| Flags | needinfo?(tbordaz) | |||
| thierry bordaz | 2021-11-04 10:45:27 UTC | Flags | needinfo?(tbordaz) | |
| Petr Hybl | 2021-11-05 08:40:30 UTC | Doc Text | .Replication session was slow is now fixed Previously when the changelog contain updates that were larger, the replication session starts from the beginning of the changelog. This seemed to be slow. It was caused by a small buffer that was assigned for a replication session. You have to check that the replication session has a buffer large enough to store the update that is at the starting point. The replication session starts immediately sending updates. | .Replication session was slow is now fixed Previously when the changelog contained updates that were larger, the replication session starts from the beginning of the changelog. This seemed to be slow. It was caused by a small buffer that was used, during the replication session, to store the updates from the changelog. Now replication session checks that the buffer is large enough to store the update that is at the starting point. The replication session starts immediately sending updates. |
| Petr Hybl | 2021-11-05 08:47:31 UTC | Doc Text | .Replication session was slow is now fixed Previously when the changelog contained updates that were larger, the replication session starts from the beginning of the changelog. This seemed to be slow. It was caused by a small buffer that was used, during the replication session, to store the updates from the changelog. Now replication session checks that the buffer is large enough to store the update that is at the starting point. The replication session starts immediately sending updates. | .Replication session was slow is now fixed Previously when the changelog contained larger updates, the replication session starts from the beginning of the changelog. This seemed to be slow. It was caused by a small buffer that was used, during the replication session, to store the updates from the changelog. Now replication session checks that the buffer is large enough to store the update that is at the starting point. The replication session starts immediately sending updates. |
| Petr Hybl | 2021-11-05 12:45:58 UTC | Doc Text | .Replication session was slow is now fixed Previously when the changelog contained larger updates, the replication session starts from the beginning of the changelog. This seemed to be slow. It was caused by a small buffer that was used, during the replication session, to store the updates from the changelog. Now replication session checks that the buffer is large enough to store the update that is at the starting point. The replication session starts immediately sending updates. | .The replication session update speed is now enhanced Previously, when the changelog contained larger updates, the replication session started from the beginning of the changelog. This slowed the session down. The using of a small buffer to store the update from a changelog during the replication session caused this. With this update, the replication session checks that the buffer is large enough to store the update at the starting point. The replication session starts sending updates immediately. |
| Marc Muehlfeld | 2021-11-08 12:23:56 UTC | Doc Text | .The replication session update speed is now enhanced Previously, when the changelog contained larger updates, the replication session started from the beginning of the changelog. This slowed the session down. The using of a small buffer to store the update from a changelog during the replication session caused this. With this update, the replication session checks that the buffer is large enough to store the update at the starting point. The replication session starts sending updates immediately. | .The replication session update speed is now enhanced Previously, when the changelog contained larger updates, the replication session started from the beginning of the changelog. This slowed the session down. The using of a small buffer to store the update from a changelog during the replication session caused this. With this update, the replication session checks that the buffer is large enough to store the update at the starting point. The replication session starts sending updates immediately. |
| errata-xmlrpc | 2021-11-09 00:26:59 UTC | Status | VERIFIED | RELEASE_PENDING |
| errata-xmlrpc | 2021-11-09 18:10:45 UTC | Status | RELEASE_PENDING | CLOSED |
| Resolution | --- | ERRATA | ||
| Last Closed | 2021-11-09 18:10:45 UTC | |||
| errata-xmlrpc | 2021-11-09 18:11:09 UTC | Link ID | Red Hat Product Errata RHBA-2021:4203 | |
| Robin Cain | 2021-11-15 14:34:23 UTC | Keywords | TestCaseNotNeeded | TestCannotAutomate |
Back to bug 1898541