[tickets] [opensaf:tickets] #1855 imm: Implementer is marked as dying forever when IMMND fails to send discard msg
- **status**: review --> invalid - **Comment**: Close this ticket as invalid since this is a problem with network. --- ** [tickets:#1855] imm: Implementer is marked as dying forever when IMMND fails to send discard msg** **Status:** invalid **Milestone:** 4.7.2 **Created:** Mon May 30, 2016 07:06 AM UTC by Hung Nguyen **Last Updated:** Tue May 31, 2016 11:26 AM UTC **Owner:** Hung Nguyen When discarding a client connection, if IMMND fails to send the implementer discard message, D2ND_DISCARD_IMPL will not be broadcasted back to all IMMNDs. The implementer will be marked as dying on local node. Also the remote nodes are not aware of that, so they still see implementer as connected. ~~~ 13:21:54 SC-1 osafimmnd[433]: ER Discard implementer failed for implId:5 but IMMD is up !? - case not handled. Client will be orphanded 13:21:54 SC-1 osafimmnd[433]: NO Implementer locally disconnected. Marking it as doomed 5 <191, 2010f> ~~~ IMMND currently doesn't handle that case so the implementer is stuck in dying state. Any attempt to set to that implementer will be rejected with TRY_AGAIN (see immModel_implIsFree). The OI will fail to set implementer no matter how many times it retires. A node reboot is needed to recover from this situation. This can also happen if IMMD crashes when processing the implementer-discard message (crashing before immd_mbcsv_sync_update). This is very hard to happen though. If IMMD crashes after immd_mbcsv_sync_update, it's still safe because the standby IMMD will re-broadcast the fevs messages after failing over. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohomanageengine___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1855 imm: Implementer is marked as dying forever when IMMND fails to send discard msg
- **status**: accepted --> review --- ** [tickets:#1855] imm: Implementer is marked as dying forever when IMMND fails to send discard msg** **Status:** review **Milestone:** 4.7.2 **Created:** Mon May 30, 2016 07:06 AM UTC by Hung Nguyen **Last Updated:** Mon May 30, 2016 09:07 AM UTC **Owner:** Hung Nguyen When discarding a client connection, if IMMND fails to send the implementer discard message, D2ND_DISCARD_IMPL will not be broadcasted back to all IMMNDs. The implementer will be marked as dying on local node. Also the remote nodes are not aware of that, so they still see implementer as connected. ~~~ 13:21:54 SC-1 osafimmnd[433]: ER Discard implementer failed for implId:5 but IMMD is up !? - case not handled. Client will be orphanded 13:21:54 SC-1 osafimmnd[433]: NO Implementer locally disconnected. Marking it as doomed 5 <191, 2010f> ~~~ IMMND currently doesn't handle that case so the implementer is stuck in dying state. Any attempt to set to that implementer will be rejected with TRY_AGAIN (see immModel_implIsFree). The OI will fail to set implementer no matter how many times it retires. A node reboot is needed to recover from this situation. This can also happen if IMMD crashes when processing the implementer-discard message (crashing before immd_mbcsv_sync_update). This is very hard to happen though. If IMMD crashes after immd_mbcsv_sync_update, it's still safe because the standby IMMD will re-broadcast the fevs messages after failing over. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1855 imm: Implementer is marked as dying forever when IMMND fails to send discard msg
- Description has changed: Diff: --- old +++ new @@ -1,5 +1,6 @@ When discarding a client connection, if IMMND fails to send the implementer discard message, D2ND_DISCARD_IMPL will not be broadcasted back to all IMMNDs. The implementer will be marked as dying on local node. Also the remote nodes are not aware of that, so they still see implementer as connected. + ~~~ 13:21:54 SC-1 osafimmnd[433]: ER Discard implementer failed for implId:5 but IMMD is up !? - case not handled. Client will be orphanded 13:21:54 SC-1 osafimmnd[433]: NO Implementer locally disconnected. Marking it as doomed 5 <191, 2010f> @@ -9,7 +10,7 @@ Any attempt to set to that implementer will be rejected with TRY_AGAIN (see immModel_implIsFree). The OI will fail to set implementer no matter how many times it retires. -A cluster reboot is needed to recover from this situation. +A node reboot is needed to recover from this situation. This can also happen if IMMD crashes when processing the implementer-discard message (crashing before immd_mbcsv_sync_update). This is very hard to happen though. If IMMD crashes after immd_mbcsv_sync_update, it's still safe because the standby IMMD will re-broadcast the fevs messages after failing over. --- ** [tickets:#1855] imm: Implementer is marked as dying forever when IMMND fails to send discard msg** **Status:** accepted **Milestone:** 4.7.2 **Created:** Mon May 30, 2016 07:06 AM UTC by Hung Nguyen **Last Updated:** Mon May 30, 2016 07:06 AM UTC **Owner:** Hung Nguyen When discarding a client connection, if IMMND fails to send the implementer discard message, D2ND_DISCARD_IMPL will not be broadcasted back to all IMMNDs. The implementer will be marked as dying on local node. Also the remote nodes are not aware of that, so they still see implementer as connected. ~~~ 13:21:54 SC-1 osafimmnd[433]: ER Discard implementer failed for implId:5 but IMMD is up !? - case not handled. Client will be orphanded 13:21:54 SC-1 osafimmnd[433]: NO Implementer locally disconnected. Marking it as doomed 5 <191, 2010f> ~~~ IMMND currently doesn't handle that case so the implementer is stuck in dying state. Any attempt to set to that implementer will be rejected with TRY_AGAIN (see immModel_implIsFree). The OI will fail to set implementer no matter how many times it retires. A node reboot is needed to recover from this situation. This can also happen if IMMD crashes when processing the implementer-discard message (crashing before immd_mbcsv_sync_update). This is very hard to happen though. If IMMD crashes after immd_mbcsv_sync_update, it's still safe because the standby IMMD will re-broadcast the fevs messages after failing over. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets