Re: [reSIProcate] asynchronous registration handling
Support for asynchronous database queries during registration has been
checked in.
-justin
-----Original Message-----
From: Justin Matthews [mailto:jmatthewsr@xxxxxxxxx]
Sent: Friday, March 20, 2009 12:44 PM
To: 'resiprocate-devel'; 'Robert Backhouse'
Subject: RE: [reSIProcate] asynchronous registration handling
Attached is the mod for asynchronous database handling.
There is a sequence/state diagram documented at
ServerRegistration::AsyncState.
If there are no objections, I will add this to the main branch as it keeps
the existing logic intact.
Please have a look and send back any comments.
Thanks,
-justin
-----Original Message-----
From: Robert Backhouse [mailto:robertb@xxxxxxxxxxxxx]
Sent: Thursday, March 12, 2009 1:36 PM
To: Justin Matthews
Cc: 'resiprocate-devel'
Subject: Re: [reSIProcate] asynchronous registration handling
Hi Justin,
Thanks for your reply. I've still got a couple of questions (sorry if I'm
missing something):
1. I presume you're suggesting that we reject the registration in
RegistrationHandler::onXxx(). How does the information that the
RegistrationPersistenceManager has failed reach the handler? The only way I
can see is to keep a map from aor to status, provide a public interface to
get at it, and cast the persistence manager to the appropriate subclass in
order to decide whether to accept or reject the registration.
2. What happens if, say, there is a connection problem when we try to roll
back to the previous registration details, or if we fail to take out the
lock even (since the database is shared)?
It sounds as though your new implementation will make this a lot easier and
clearer.
Thanks again,
Rob.
Justin Matthews wrote:
> Hi Rob,
>
> Currently you would handle this by trapping all database failures in
> your persistence manager and then call ServerRegistration::reject().
> All the db operations are performance before the calls to
onRefresh,onRemove,onAdd,etc.
> If you reject() the registration, then ServerRegistration tries to
> roll back the changes by removing the registration (via removeAor())
> and then re-applying the original list that it saved (via addAor).
>
> The implementation I am working on will allow more flexible error
> handling without blocking the DUM thread, will not require roll back
> if the registration is rejected and will require fewer DB calls. I
> should have more details in a few days.
>
> Thanks,
>
> -justin
>
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Robert
> Backhouse
> Sent: Thursday, March 12, 2009 9:53 AM
> To: 'resiprocate-devel'
> Subject: Re: [reSIProcate] asynchronous registration handling
>
> Hi,
>
> I have a separate but related question. In the last few days I have
> also been having trouble in this area while trying to implement a
> database-based RegistrationPersistenceManager.
>
> My problem is that there doesn't seem to be any mechanism to cope with
> an action/query failing - if there is a problem with the database
> connection, the SQL syntax, or just a random deadlock or transaction
> timeout then I can't see a way to fail the registration.
>
> I presume some people must have successfully written database backed
> RegistrationPersistenceManager implementations - can anyone explain
> how they dealt with SQL exceptions without a response to signify
> failure or a suitable exception to throw?
>
> Otherwise, if the ServerRegistration logic is being rewritten, do you
> think this would be a sensible opportunity to support failures from
> the RegistrationPersistenceManager in some way?
>
> Thanks,
>
> Rob.
>
>
>> 2009/3/9 Justin Matthews <jmatthewsr@xxxxxxxxx
>> <mailto: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
>
--
Robert Backhouse <robertb@xxxxxxxxxxxxx> Software Developer
Tel: +44 (0) 845 666 7778
Fax: +44 (0) 870 163 4694
http://www.mxtelecom.com