[asterisk-dev] Asterisk Segfault After PJSIP Commit 5241

[Michael Ulitskiy]

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

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
> >
> >
> >
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160303/b3e4d5d4/attachment.html>