On 16 September 2014 08:30, Anders Björnerstedt <[email protected]> wrote: > Sorry for laboring the point but.. > > I was not saying that you where saying that there was a problem with > immloader. > I was saying that in this concrete case I dont understand why you got an MDS > UP event after > You (the IMMND side) got an MDS DOWN. Ok so the process could linger after > MDS DOWNM is > generated as part of the outdrawn termination of immloader. But why do you > get an MDS-UP > again from the process while it is going down ?
A misunderstanding, I did not get any MDS-UP again for immloader. I used it as an example that at the point in time when MDS DOWN is received in the server, the client process might still appear to be alive although it has exited since long. > > To me it seems as if there is some "over eager" reconnect mechanism in MDS > that needs to be > contained better. I say "seems like" since I dont understand any details of > how MDS works in > this area. > > /AndersBj > > > -----Original Message----- > From: Hans Feldt [mailto:[email protected]] > Sent: den 16 september 2014 08:15 > To: Anders Björnerstedt > Cc: ramesh betham; [email protected] > Subject: Re: [devel] [PATCH 0 of 2] Review Request for MDS/IMMA #1050 > > Yes there is nothing wrong with immloader (except perhaps that it does not > finalize its handles). I just took it as an example that when the MDS Down is > received on the server side, the process may still be alive from an operating > system perspective. Yes it is dying but it takes some time for the cleanup > activities (init should call wait e.g.). > > My point here was just that MDS down cannot immediately trigger cleanup of > the process_info entry. That takes us back to the #1050 problem. Again > immloader is not guilty but amfnd and log and possibly other (stupid?) > processes doing finalize/initialize back to back in a loop. > Thanks, > Hans > > > On 15 September 2014 17:04, Anders Björnerstedt > <[email protected]> wrote: >> I dont follow this. >> >> If the process is (a) still alive and (b) has not closed its handles, >> Why would there be an MDS down received in the server ? >> >> Furthermore, the immloder does its thing and then terminates/exits. >> It does not open handles again. >> >> /AndersBj >> >> -----Original Message----- >> From: Hans Feldt [mailto:[email protected]] >> Sent: den 15 september 2014 15:36 >> To: ramesh betham >> Cc: [email protected] >> Subject: Re: [devel] [PATCH 0 of 2] Review Request for MDS/IMMA #1050 >> >> The example log I included was for an IMM process (imm loader) that does not >> finalize its handles thus there is no MDS unregister. When the MDS DOWN >> event is received in the server process (immnd), the client process is still >> alive (checked using kill(pid, 0)). Thus it is not possible to immediately >> delete the process info entry because then we have the race described by >> #1050. >> Thanks, >> Hans >> >> On 15 September 2014 14:39, ramesh betham <[email protected]> wrote: >>> 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 ------------------------------------------------------------------------------ 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
