Summary: IMM: Failure to send completed to PBE defaulted to ccb-recovery [#1127] Review request for Trac Ticket(s): 1127 Peer Reviewer(s): Neel Pull request to: Affected branch(es): 4.3: 4.4; 4.5; default(4.6) Development branch:
-------------------------------- Impacted area Impact y/n -------------------------------- Docs n Build system n RPM/packaging n Configuration files n Startup scripts n SAF services y OpenSAF services n Core libraries n Samples n Tests n Other n Comments (indicate scope for each "y" above): --------------------------------------------- changeset 9f43733a20d973b066e87a0a1d3251c6f89afdb9 Author: Anders Bjornerstedt <[email protected]> Date: Wed, 24 Sep 2014 13:00:35 +0200 IMM: Failure to send completed to PBE defaulted to ccb-recovery [#1127] The fix is mainly in immnd_evt_proc_ccb_apply, but also some cleanup in immnd_evt_proc_ccb_compl_rsp where part of the same problem was addressed by the earlier ticket: #1096. The general case is that the ccb has just gone critical in ImmModel (at all IMMNDs) and one IMMND is just about to send the completed callback to the PBE. The completed callback can be sent to PBE either in 'proc_ccb_apply' when there are no regular OIs involved with the ccb; or in 'proc_ccb_compl_rsp' if there are regular OIs and the reply from all of them has been received. Solution: The impossible case of the PBE-OI being known to ImmModel yet the client_node not existing is handled by osafassert. The rare but possible case of the client_node existing but being stale is handled by skipping over the send-attempt (which would fail) and letting ccb-recovery sort things out. The rare but possible case of the client_node being ok but the send over MDS resulting in an error return from MDS is also handled by letting ccb- recovery sort it out. Note that the handling an error code from MDS for this case as the send having been processed is safer, since the message could possibly have reached the PBE despite that MDS reported error. The client node stale case could in principle have been handled by aborting the CCB, but the ImmModel has entered the critical state for this ccb at all nodes and so such a solution would require a new message type: revert- critical-and-abort-ccb being broadcast. Just broadcasting the currenttly supported ccb-abort would not work because ccbs in critical will (correctly) discard such a request. Complete diffstat: ------------------ osaf/services/saf/immsv/immnd/immnd_evt.c | 63 ++++++++++++++++++++++++++++++++++++++++++--------------------- 1 files changed, 42 insertions(+), 21 deletions(-) Testing Commands: ----------------- Testing, Expected Results: -------------------------- Conditions of Submission: ------------------------- Ack from Neel Arch Built Started Linux distro ------------------------------------------- mips n n mips64 n n x86 n n x86_64 n n powerpc n n powerpc64 n n Reviewer Checklist: ------------------- [Submitters: make sure that your review doesn't trigger any checkmarks!] Your checkin has not passed review because (see checked entries): ___ Your RR template is generally incomplete; it has too many blank entries that need proper data filled in. ___ You have failed to nominate the proper persons for review and push. ___ Your patches do not have proper short+long header ___ You have grammar/spelling in your header that is unacceptable. ___ You have exceeded a sensible line length in your headers/comments/text. ___ You have failed to put in a proper Trac Ticket # into your commits. ___ You have incorrectly put/left internal data in your comments/files (i.e. internal bug tracking tool IDs, product names etc) ___ You have not given any evidence of testing beyond basic build tests. Demonstrate some level of runtime or other sanity testing. ___ You have ^M present in some of your files. These have to be removed. ___ You have needlessly changed whitespace or added whitespace crimes like trailing spaces, or spaces before tabs. ___ You have mixed real technical changes with whitespace and other cosmetic code cleanup changes. These have to be separate commits. ___ You need to refactor your submission into logical chunks; there is too much content into a single commit. ___ You have extraneous garbage in your review (merge commits etc) ___ You have giant attachments which should never have been sent; Instead you should place your content in a public tree to be pulled. ___ You have too many commits attached to an e-mail; resend as threaded commits, or place in a public tree for a pull. ___ You have resent this content multiple times without a clear indication of what has changed between each re-send. ___ You have failed to adequately and individually address all of the comments and change requests that were proposed in the initial review. ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc) ___ Your computer have a badly configured date and time; confusing the the threaded patch review. ___ Your changes affect IPC mechanism, and you don't present any results for in-service upgradability test. ___ Your changes affect user manual and documentation, your patch series do not contain the patch that updates the Doxygen manual. ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
