Back to bug 1310848
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Noriko Hosoi | 2016-02-22 19:34:52 UTC | Status | NEW | POST |
| Sat6QE Jenkins | 2016-03-28 20:15:54 UTC | Status | POST | MODIFIED |
| Mike McCune | 2016-03-28 23:13:32 UTC | Status | MODIFIED | POST |
| Noriko Hosoi | 2016-05-04 19:47:15 UTC | Status | POST | MODIFIED |
| Fixed In Version | 389-ds-base-1.3.5.2-1.el7 | |||
| errata-xmlrpc | 2016-05-04 20:08:41 UTC | Status | MODIFIED | ON_QA |
| German Parente | 2016-06-06 08:17:19 UTC | CC | ekeck, gparente | |
| Flags | needinfo?(ekeck) | |||
| Eugene Keck | 2016-06-06 15:26:43 UTC | Priority | unspecified | urgent |
| Hardware | Unspecified | All | ||
| Flags | needinfo?(ekeck) | |||
| OS | Unspecified | Linux | ||
| Severity | unspecified | urgent | ||
| Marcel Kolaja | 2016-06-07 08:03:31 UTC | CC | mkolaja | |
| Flags | needinfo?(ekeck) | |||
| Noriko Hosoi | 2016-06-29 20:23:02 UTC | Flags | needinfo?(ekeck) | needinfo?(mkolaja) |
| Marcel Kolaja | 2016-06-30 06:19:51 UTC | Blocks | 1351447 | |
| Marcel Kolaja | 2016-06-30 06:20:21 UTC | Keywords | ZStream | |
| Noriko Hosoi | 2016-06-30 17:46:20 UTC | Doc Text | Cause: If a replicated update fails on the consumer, the update is never tried. This is due to the replication async result thread missing the failure before another update is replicated and it succeeds. Then, the next update that succeeds updates the consumer's replication status. Consequence: This makes it appear that the consumer is caught up, and the supplier never resends that original failed update. Fix: When a replicated update fails, and its an error we can not ignore, the connection is closed. Which stops the replication session, and prevents any further updates coming in and updating the consumer's replication status. Result: This allows the supplier to correctly retry the operation that failed on the next replication session, which prevents the replication data loss. | |
| Flags | needinfo?(mkolaja) | |||
| Petr Bokoc | 2016-07-21 13:17:05 UTC | CC | pbokoc | |
| Doc Text | Cause: If a replicated update fails on the consumer, the update is never tried. This is due to the replication async result thread missing the failure before another update is replicated and it succeeds. Then, the next update that succeeds updates the consumer's replication status. Consequence: This makes it appear that the consumer is caught up, and the supplier never resends that original failed update. Fix: When a replicated update fails, and its an error we can not ignore, the connection is closed. Which stops the replication session, and prevents any further updates coming in and updating the consumer's replication status. Result: This allows the supplier to correctly retry the operation that failed on the next replication session, which prevents the replication data loss. | Previously, if a replica update failed on the consumer side and was followed by another update which succeeded, the consumer's replication status was updated by the successful update, which made it seem as though the consumer was caught up. Consequently, the failed update was never retried, leading to data loss. With this update, a replication failure closes the connection and stops the replication session. This prevents further updates from changing the consumer's replication status, and allows the supplier to retry the failed operation in the next session, avoiding data loss. | ||
| Petr Bokoc | 2016-07-21 15:03:10 UTC | Doc Text | Previously, if a replica update failed on the consumer side and was followed by another update which succeeded, the consumer's replication status was updated by the successful update, which made it seem as though the consumer was caught up. Consequently, the failed update was never retried, leading to data loss. With this update, a replication failure closes the connection and stops the replication session. This prevents further updates from changing the consumer's replication status, and allows the supplier to retry the failed operation in the next session, avoiding data loss. | If a replica update failed on the consumer side and was followed by another update that succeeded, the consumer's replication status was updated by the successful update, which caused the consumer to look like it was caught up. Consequently, the failed update was never retried, leading to data loss. With this update, a replication failure closes the connection and stops the replication session. This prevents further updates from changing the consumer's replication status, and allows the supplier to retry the failed operation in the next session, avoiding data loss. |
| Petr Bokoc | 2016-08-01 11:42:06 UTC | Doc Text | If a replica update failed on the consumer side and was followed by another update that succeeded, the consumer's replication status was updated by the successful update, which caused the consumer to look like it was caught up. Consequently, the failed update was never retried, leading to data loss. With this update, a replication failure closes the connection and stops the replication session. This prevents further updates from changing the consumer's replication status, and allows the supplier to retry the failed operation in the next session, avoiding data loss. | Failed replication updates are now retried correctly in the next session If a replica update failed on the consumer side and was followed by another update that succeeded, the consumer's replication status was updated by the successful update, which caused the consumer to look like it was caught up. Consequently, the failed update was never retried, leading to data loss. With this update, a replication failure closes the connection and stops the replication session. This prevents further updates from changing the consumer's replication status, and allows the supplier to retry the failed operation in the next session, avoiding data loss. |
| Petr Bokoc | 2016-08-01 11:42:57 UTC | Docs Contact | pbokoc | |
| Kamlesh | 2016-08-02 09:34:23 UTC | Status | ON_QA | VERIFIED |
| CC | kchaudha | |||
| Petr Bokoc | 2016-08-22 11:33:07 UTC | Doc Text | Failed replication updates are now retried correctly in the next session If a replica update failed on the consumer side and was followed by another update that succeeded, the consumer's replication status was updated by the successful update, which caused the consumer to look like it was caught up. Consequently, the failed update was never retried, leading to data loss. With this update, a replication failure closes the connection and stops the replication session. This prevents further updates from changing the consumer's replication status, and allows the supplier to retry the failed operation in the next session, avoiding data loss. | Failed replication updates are now retried correctly in the next session If a replica update failed on the consumer side and was followed by another update that succeeded, the consumer's replication status was updated by the successful update, which caused the consumer to seem as if it was up to date. Consequently, the failed update was never retried, leading to data loss. With this update, a replication failure closes the connection and stops the replication session. This prevents further updates from changing the consumer's replication status, and allows the supplier to retry the failed operation in the next session, avoiding data loss. |
| John Skeoch | 2016-10-23 22:39:34 UTC | CC | kchaudha | kbanerje |
| errata-xmlrpc | 2016-11-02 12:24:51 UTC | Status | VERIFIED | RELEASE_PENDING |
| errata-xmlrpc | 2016-11-03 20:39:41 UTC | Status | RELEASE_PENDING | CLOSED |
| Resolution | --- | ERRATA | ||
| Last Closed | 2016-11-03 16:39:41 UTC | |||
| Noriko Hosoi | 2016-11-15 16:04:11 UTC | CC | tmihinto | |
| Simon Pichugin | 2020-09-13 21:04:32 UTC | Link ID | Github 389ds/389-ds-base/issues/1119 |
Back to bug 1310848