< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

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