On Wed, 2009-08-19 at 10:03 -0400, Beeton, Carolyn (CAR:9D60) wrote: > > If I recall correctly (and if I'm not remembering something > > that I meant to do and never got around to), we solved this > > in the registrar by having it always persist the registration > > data during the server shutdown. > > > It's subscription data that is at issue here... is that the same as > registration data? (or would the solution you mention cover subscription > data also) > > I can definitely reproduce this by restarting sipxecs immediately after > causing a NOTIFY to be sent. Adding logs in the destructor of > SipPersistentSubscriptionMgr shows that the timer was running, but the > store() fn was not called (for obsolete reasons). Adding back the call > to store() then causes proper operation. > > Can I go ahead with the obvious fix (remove the comments that say > "Unfortunately, the signal handler has usually closed the IMDB by the > time this destructor is called, so this store() cannot be executed.", > and uncomment the call to mSubscriptionDBInstance->store())?
Got for it _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
