[sr-dev] UAC registrations - notes for the archive

[Daniel-Constantin Mierla]

Some remarks and eventual corrections.

On 25/02/15 08:50, Olle E. Johansson wrote:
> Yesterday I used the UAC module to register 10.000 accounts while testing a platform. I guess this is something it wasn't built for. I just wanted to add some notes to the archives about this:
>
> - The module seems to read all 10.000 entries from the database in one go and then add them to shared memory.
>   It may be good for the future to limit the amounts of records for each read and take it in multiple batches (other modules
>   have this functionality).

This should be in place already, fetching 1000 records (not 10 000).
Maybe that should be made a module parameter -- I guess it was intended
so because is defined as a variable, just not exported to module params.

>
> - The module registers all at once, it's very fast. I think we could add a throttle and register in batches in the future.

I thought at some point about it, an option would be to just add it in
memory and 'plant' it there as registered for a short random interval,
so the timer will pick it up when appears a 'just to expire'.

On the other hand, it means some records won't be actually registered
during that interval. So this sounds like a parameter based option to be
added.

>
> - The error handling seems very simple. If something goes bad, we disable the account. I am not sure if the
>   TM module will handle failover and retries if we get a 503 with retry-after. There's no code in uac_reg.c for it.

I don't think it does it now, it would be a good addition.

>
> - There's no different handling of local timeouts and remote 408s. Again, maybe the TM module handles some
>   of that. 

Would it be a difference here?

>
> - Maybe we need an event route for disabling/enabling registrations.
>
> I created a branch and added counter support for all database entries, disabled entries and active entries (working registrations). Pull request will come :-)
Nice, those will be useful, indeed.

Cheers,
Daniel
>
> All in all, while this is not a normal use of it, I think it is a very good tool for testing of new platforms. As usual - Kamailio rocks!
>
> /O
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com