RE: [reSIProcate] Purging expired registrations
For repro the registration database is trimmed in LocationServer.cxx
after getContact is called - each one is checked for expiry, if any have
expired it calls removeContact. But I think this functionality maybe
more better implemented as you have suggested - in the getContacts call
itself. Another approach would be to start timers - but I think that
will be overhead we don't really need.
Also - I can't think of a current need for a callback.
Scott
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Daniel Pocock
> Sent: Wednesday, June 28, 2006 6:22 PM
> To: resiprocate-devel
> Subject: [reSIProcate] Purging expired registrations
>
>
>
>
> I notice the following code in InMemoryRegistrationDatabase.cxx,
> getContacts() is similar, it appears that the aor and/or contacts are
> returned without checking for expiry.
>
> I am happy to write patches for InMemoryRegistrationDatabase to purge
> the expired registrations whenever the relevent aor is queried.
>
> Furthermore, if a class implementing RegistrationPersistenceManager is
> modified to purge expired registrations in this way, will it need to
> initiate (possibly through the stack) some callback to the
> ServerRegistrationHandler?
>
> bool
> InMemoryRegistrationDatabase::aorIsRegistered(const Uri& aor) {
> database_map_t::iterator i;
>
> Lock g(mDatabaseMutex);
> i = mDatabase.find(aor);
> if (i == mDatabase.end() || i->second == 0)
> {
> return false;
> }
> return true;
> }
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel