Re: [reSIProcate] asynchronous registration handling

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

Ah - I see.  We have asynchronous access to db for authentication but not for registration storage/query.  Sounds like a good thing to add to me.  : )

Scott

On Tue, Mar 10, 2009 at 10:39 AM, Justin Matthews <jmatthewsr@xxxxxxxxx> wrote:

Sorry, it probably wasn’t clear that I am looking for asynchronous database access for registrations.  Maybe I was clear and am just missing it J.  In ServerRegistration calls are made directly to the RegistrationPersistenceManager (the database).  What I am looking for is a way to send the database queries off to a worker thread and then continue processing the REGISTER asynchronously.

 

I am thinking of sending an asynchronous request to a database thread when the REGISTER is received to retrieve all the current records, then process the REGISTER as it is done now once the db query is complete. The ServerRegistration would then use a local RegistrationPersistenceManager (similar to the inmemory store).  Once the REGISTER processing is complete the database can be updated with another asynchronous request.  This method would allow keeping the majority of the current logic intact. It would also reduce some trips to the database.

 

Thanks,

 

-justin 

 

From: slgodin@xxxxxxxxx [mailto:slgodin@xxxxxxxxx] On Behalf Of Scott Godin
Sent: Tuesday, March 10, 2009 10:21 AM
To: Justin Matthews
Cc: resiprocate-devel
Subject: Re: [reSIProcate] asynchronous registration handling

 

This is already implemented in DUM for Server side registrations - or are you referring to something different?  I'm pretty sure repro uses dum's asynchronous db lookups as well.

2009/3/9 Justin Matthews <jmatthewsr@xxxxxxxxx>

Hi,

 

I am looking at adding asynchronous REGISTER handling in DUM. Has anyone thought about or actually implemented this?  There are some notes in DialogSet.cxx about moving REGISTER handling to DialogUsageManager, would these mean converting REGISTER handling to be a DumFeature?  Would this makes things easier to post back responses to a DUM feature as opposed to implementing some kind of postback to a ServerRegistration?    

 

Basically I need to send the DB queries off to another thread to avoid blocking.

 

Also, is anyone else interested in this?

 

Thanks,

justin

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel