henningw left a comment (kamailio/kamailio#4809)
> > > Since AFAICT the only thing writing to the permissions and the dispatcher
> > > tables is the reload function, which always constructs a brand new table
> > > and then switches them out, I would suggest to add a reference count to
> > > the tables in question. That would allow arbitrary concurrent read access
> > > while also making simultaneous reloads safe, with minimal added overhead.
> > > It would also make the current (unsafe) double-buffering and
> > > rate-limiting approach obsolete. Willing to implement if acceptable.
> >
> >
> > Reference counters could be a good option, but having only a single table
> > can lead to (rather long) blocking, in the way that when a reload is
> > triggered, SIP workers that already started have to finish their walk
> > through records to dereference the table, while other SIP workers that want
> > to start have to be stopped and wait for the reload to finish.
> > Keeping two (or even more) tables can be good for many reloads triggered in
> > short time, having an active table and a list of old tables that are kept
> > till reference counter gets to 0.
>
> There would still be two (or more) tables during a reload, but globally
> visible would ever be only a single pointer to one. The reload function would
> construct a new table in local scope, fill it with data, and once finished
> will swap out the global pointer, dropping a reference to the old table. Any
> workers still reading the old table would hold a reference to it (in their
> local scope) and would be safe, and the old table would be freed only once
> the refcount drops to zero.
>
> The only downside in such a simple approach would be that if a concurrent
> reload happens, the freeing of the old table would happen in a worker process
> and not in the RPC process. (If that's a concern, then the freeing of an
> orphaned table could also be delegated to an RPC process with some additional
> instrumentation, whenever the next reload happens.)
>
> Edit: Alternatively a read/write lock would also do the job, if blocking
> simultaneous reloads is acceptable
I like the approach with the load in background, copy and then remove the old
data when not in use anymore. A similar approach is used e.g. for the
carrierroute module since many years:
[link](https://github.com/kamailio/kamailio/blob/c71db9dfd384c4c6dabcee70168627c782144b6e/src/modules/carrierroute/cr_data.c#L175)
It works reliable in high load situation with a much larger data set.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4809#issuecomment-4915925539
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4809/[email protected]>
_______________________________________________
Kamailio - Development Mailing List -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
