[asterisk-dev] Asterisk Segfault After PJSIP Commit 5241

[George Joseph]

On Thu, Mar 3, 2016 at 2:32 PM, Michael Ulitskiy <mulitskiy at acedsl.com>
wrote:

> George,
>
> That's really a great news. I guess I should look at pjsip again then.
>
> Just one question though. I tried to google "full_backend_cache" option,
> but all I was able to find
>
> is commit message in asterisk-commits list and that message isn't very
> informative.
>
> Can you please explain how it's supposed to be used and what it suppose to
> do?
>
> If there's any documentation that explains it, please point me there.
>
> Thanks a lot,
>
> Michael
>
>
>

​It's on my list to update the Wiki.

Here's a sorcery.conf example for endpoints...

endpoint/cache=memory_cache,object_lifetime_stale=3600,object_lifetime_maximum=28800,expire_on_reload=yes,full_backend_cache=yes
endpoint=realtime,ps_contacts

In the normal cache scenario, only direct lookups by id are cached.  With
full_backend_cache, all lookups are cached including those that do a 'get
all' like the retrieve all to find qualifyable contacts.



> On Wednesday, March 02, 2016 05:08:51 PM George Joseph wrote:
>
> > On Wed, Mar 2, 2016 at 12:51 PM, Michael Ulitskiy <mulitskiy at acedsl.com>
>
> > wrote:
>
> >
>
> > > Hello,
>
> > >
>
> > >
>
> > >
>
> > > Since you started to look at it again, let me repeat myself.
>
> > >
>
> > > The problem is described in detail here:
>
> > >
> http://lists.digium.com/pipermail/asterisk-dev/2015-October/075128.html
>
> > >
>
> > > It has to do with the fact that at initial load pjsip realtime issues
>
> > > separate db query for each endpoint/aor/etc in the system.
>
> > >
>
> > > In my case of ~10K endpoints it took asterisk ~1.5minutes to load.
>
> > >
>
> > > Further in that discussion I suggested that having the following API
> call
>
> > > to populate sorcery cache would go a long way to
>
> > >
>
> > > reducing the scale of this problem:
>
> > >
>
> > >
>
> > >
>
> > > ast_sorcery_retrieve_by_fields(sip_sorcery,
>
> > > "endpoint",AST_RETRIEVE_FLAG_MULTIPLE | AST_RETRIEVE_FLAG_ALL, NULL);
>
> > >
>
> > >
>
> > >
>
> > > I haven't looked at pjsip since the time of that discussion as that's
>
> > > clearly a show-stopper for me, but I doubt anything changed.
>
> > >
>
> > > Also I haven't received any feedback if that suggestion is viable, so
> I'd
>
> > > love to hear your (and/or other developers) opinion on it.
>
> > >
>
> > > Any other idea on how to deal with it is more than welcome as well.
>
> > >
>
> >
>
> > ​So part of this I just fixed in review 2312. The cache is now populated
>
> > at startup. Together with full_backend_cache there should be *some*
>
> > relief.
>
> >
>
> > One of the base issues however is that we can't use the power of SQL to
>
> > narrow down the result set before shipping them all back to Asterisk
>
> > because not all the backends support SQL. If they did, we could, for
>
> > instance, 'select * from ps_endpoints a, ps_aors b where a.id = b.id and
>
> > b.qualify_frequency > 0' (well almost) to get only the endpoints that
> need
>
> > to be scheduled. Or 'select * from ps_endpoints where id in
>
> > ('user','user at domain')'. We just can't do that right now.
>
> >
>
> > All is not lost however. We've been noodling with some ideas on how to
>
> > make this work more efficiently but it's not something that's going to
>
> > happen this week, :)
>
> >
>
> >
>
> > >
>
> > >
>
> > > Thanks,
>
> > >
>
> > > Michael
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160303/809652ba/attachment-0001.html>