It is quiet possible to receive down-event even when the process is alive. If client does MDS unregister (through UNISTALL), DOWN event will be generated.
In my opinion, there is no harm in deleting the process-info for the last down-event of that adest (if svc-id is not part of the key) (or) can directly delete the process_info for a down-event when svc-id is part of key (adest + svc-id). Deleting the process info as and when the down event arrives seems to be a consistent approach to follow. Once the down-event occurs for a client, there shall not be any MDS communication channel exist for this client. Let the client again establish the new connection through INSTALL (UP event) and even establishing the authentication socket when the peer UP event is detected. Also receiving the old-DOWN event in a delayed manner that too after new register is a serious concern, not only in this case but across the OpenSAF. Till now such incidents were not observed/reported and so can treat such occurrences are very unlikely to happen. May be I am missing some aspects of it, please educate me with the issues been observed from your testing when process_info was deleted for a DOWN event and process is alive. Thanks and Regards, Ramesh. On 9/15/2014 5:31 PM, Hans Feldt wrote: > It seems like when MDS DOWN is received (using TIPC) the process is still > alive: > > Sep 15 13:56:03 uabhafe-Latitude-E7440 osafimmloadd[10552]: NO Load > ending normally > Sep 15 13:56:03 uabhafe-Latitude-E7440 osafimmnd[10532]: NO MDS down, > entry exist for 2010f725be010, id:26 exist but process is alive > > thus a delayed (using timer) approach is needed. > /Hans > > On 15 September 2014 13:23, Hans Feldt <[email protected]> wrote: >> On 12 September 2014 15:08, ramesh betham <[email protected]> wrote: >>>> * down starts a timer >>>> * timeout deletes entry >>>>> [Ramesh]: Is it really required?, atleast to me it is not required. But >>>>> if you have faced any issues/race-conditions as part of your testing and >>>>> this change solves it.. glad to know those observations as well. >>>> [Hans] for processes that exit without finalize or crash it would >>>> otherwise lead to a memory leak in mds (immnd) >>> [Ramesh]: Hmm! any way process_info_db has to be deleted for a >>> down-event, so why to start an additional timer?, Not able to catch your >>> reasoning. >> OK if the process is dead at time of the down event the process info >> can be deleted immediately. >> >> But what if the process is not dead? This is what #1050 is about. The >> DOWN event somehow (using MDS/TIPC) is delayed so that it is delivered >> after a new register has been done. Many IMM clients are not reusing >> their handles the way they could (amfnd and log e.g.) instead they do >> initialize/finalize back to back a couple of times. That could >> (should?) of course be optimized but anyhow it reveals this problem. >> >> The problem in 1050 was that the process info was immediately deleted >> at the DOWN event. So if the process is still alive MDS must either 1) >> forget the DOWN event or 2) delay it and try to understand at a later >> point in time if it should clean the entry. Now I no longer can see >> the problem with ignoring the event when the process is still alive. >> Can you? >> >> Basically suggesting to ignore MDS down if the process is still alive. >> Will test a bit with this. >> >> Thanks, >> Hans ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
