Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
On Thu, Mar 3, 2016 at 2:32 PM, Michael Ulitskiy
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
>
> > 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@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
>
--
_
-- 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
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
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
> 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@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
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
On Wed, Mar 2, 2016 at 12:51 PM, Michael Ulitskiy
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@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
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
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. Thanks, Michael On Wednesday, March 02, 2016 06:04:15 PM Ross Beer wrote: > Hi George, > > I have commented out those lines and it hasn't improved the load times, its > still taking 15 mins. It has improved it a little. > > Regards, > > Ross > > From: george.jos...@fairview5.com > Date: Wed, 2 Mar 2016 08:19:01 -0700 > To: asterisk-dev@lists.digium.com > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > On Wed, Mar 2, 2016 at 2:56 AM, Ross Beer wrote: > > > > Hi George, > > I have re-built the 'c1bf014ea08cf66835a6f000e2bd6c7da588da6b' commit and > PJSIP and Asterisk hasn't crashed after reload. However it did take 25 mins > to load. > > As requested I have opened a ticket for the realtime issue: > > https://issues.asterisk.org/jira/browse/ASTERISK-25826 > Got it, thanks. > > Basically, I think this could be resolved by a configuration option that > stops sourcery/pjsip loading all peers at start-up as this is not needed for > the current setup. This has been discussed before on the mailing list however > it doesn't look like it progresses any further. > > If you're up for trying something, you can comment out the > qualify_and_schedule_all function in lines 1135-1147 of > res/res_pjsip/pjsip_options.c, then comment out its 2 references on lines > 1245 and 1281. If that drops your startup times, then we know we're on the > right track. > > > I would like to thank you for all of your help tying to identify the issue > and hope that we can resolve it soon. > > No worries! > > Kind regards, > > Ross > > From: george.jos...@fairview5.com > Date: Tue, 1 Mar 2016 16:27:06 -0700 > To: asterisk-dev@lists.digium.com > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > On Tue, Mar 1, 2016 at 3:07 PM, Ross Beer wrote: > > > > ok, > > That took 15 mins to load and then crashed. This will be due to the > pjsip_dlg_create_uas_and_inc_lock commit. > It should not have crashed. That commit had the fix for it. If it did > crash with that commit, open a Jira issue and attach a full backtrace. > > However 15 mins to start is a long time and would cause issues in a > production environment. > Would you open a Jira issue on the realtime problem (if one isn't already > open).I'm starting to look at alternatives. > > > > Thank you for your help here, > > Ross > > > From: george.jos...@fairview5.com > Date: Tue, 1 Mar 2016 14:02:38 -0700 > To: asterisk-dev@lists.digium.com > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > On Tue, Mar 1, 2016 at 1:04 PM, Ross Beer wrote: > > > > Hi George, > > Using a development test box for testing!! > > Asterisk 13.7.2 with no cache takes 4:12 to load, that with PJSIP Commit 5240 > > Ok, try this combination..."git checkout > c1bf014ea08cf66835a6f000e2bd6c7da588da6b"pjproject from trunk.with caching. > The commit I referenced is the one that handles the > pjsip_dlg_create_uas_and_inc_lock > > > > Qualify time on the aor is set to zero, I guess a query could be made to > check for a value greater than zero instead of loading all endpoints. > > Ross > > From: george.jos...@fairview5.com > Date: Tue, 1 Mar 2016 12:45:28 -0700 > To: asterisk-dev@lists.digium.com > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > On Tue, Mar 1, 2016 at 12:21 PM, Ross Beer wrote: > > > > Hi George, > > No endpoints are qualified, there are 20,000 endpoi
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
Hi George, I've just rolled back to 13.7.2 and the following modules are in the latest git repository and not in 13.7.2: res_pjproject.so res_odbc_transaction.so res_pjsip_history.so Not sure if any of these would make a difference to the load time? Regards, Ross From: ross.b...@outlook.com To: asterisk-dev@lists.digium.com Date: Wed, 2 Mar 2016 18:04:15 + Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 Hi George, I have commented out those lines and it hasn't improved the load times, its still taking 15 mins. It has improved it a little. Regards, Ross From: george.jos...@fairview5.com Date: Wed, 2 Mar 2016 08:19:01 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Wed, Mar 2, 2016 at 2:56 AM, Ross Beer wrote: Hi George, I have re-built the 'c1bf014ea08cf66835a6f000e2bd6c7da588da6b' commit and PJSIP and Asterisk hasn't crashed after reload. However it did take 25 mins to load. As requested I have opened a ticket for the realtime issue: https://issues.asterisk.org/jira/browse/ASTERISK-25826 Got it, thanks. Basically, I think this could be resolved by a configuration option that stops sourcery/pjsip loading all peers at start-up as this is not needed for the current setup. This has been discussed before on the mailing list however it doesn't look like it progresses any further. If you're up for trying something, you can comment out the qualify_and_schedule_all function in lines 1135-1147 of res/res_pjsip/pjsip_options.c, then comment out its 2 references on lines 1245 and 1281. If that drops your startup times, then we know we're on the right track. I would like to thank you for all of your help tying to identify the issue and hope that we can resolve it soon. No worries! Kind regards, Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 16:27:06 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 3:07 PM, Ross Beer wrote: ok, That took 15 mins to load and then crashed. This will be due to the pjsip_dlg_create_uas_and_inc_lock commit. It should not have crashed. That commit had the fix for it. If it did crash with that commit, open a Jira issue and attach a full backtrace. However 15 mins to start is a long time and would cause issues in a production environment. Would you open a Jira issue on the realtime problem (if one isn't already open).I'm starting to look at alternatives. Thank you for your help here, Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 14:02:38 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 1:04 PM, Ross Beer wrote: Hi George, Using a development test box for testing!! Asterisk 13.7.2 with no cache takes 4:12 to load, that with PJSIP Commit 5240 Ok, try this combination..."git checkout c1bf014ea08cf66835a6f000e2bd6c7da588da6b"pjproject from trunk.with caching. The commit I referenced is the one that handles the pjsip_dlg_create_uas_and_inc_lock Qualify time on the aor is set to zero, I guess a query could be made to check for a value greater than zero instead of loading all endpoints. Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 12:45:28 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 12:21 PM, Ross Beer wrote: Hi George, No endpoints are qualified, there are 20,000 endpoints with only 75 static contacts defined in the aors. The database is a MySQL cluster. With the current Asterisk 13 branch with cache disabled and the latest PJSIP it takes 5 mins and then before finishing it crashes. With Asterisk 13.7.2 with cache it takes around 1 1/2 min to load, however due to the bug with PJSIP Commit 5241 asterisk crashes when using TLS devices. Try 13.7.2 without the cache. I'm trying to understand where the time is being spent. I know it will crash because of that bug. You're not doing this on a production system are you?? The main issue here is that the endpoints are loaded as soon as PJSIP loads, ideally endpoints would only be loaded once a device registers or attempts to make a call. Much in the same way as Asterisk 1.8 chan_sip manages realtime. There is no need to load the endpoints as they are not qualified. How do you know they're not qualified if you don't load them? :) Time to load up a database with 20,000 endpoints I guess. Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 11:58:15 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 11:38 AM, Michael Ulitskiy
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
Hi George, I have commented out those lines and it hasn't improved the load times, its still taking 15 mins. It has improved it a little. Regards, Ross From: george.jos...@fairview5.com Date: Wed, 2 Mar 2016 08:19:01 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Wed, Mar 2, 2016 at 2:56 AM, Ross Beer wrote: Hi George, I have re-built the 'c1bf014ea08cf66835a6f000e2bd6c7da588da6b' commit and PJSIP and Asterisk hasn't crashed after reload. However it did take 25 mins to load. As requested I have opened a ticket for the realtime issue: https://issues.asterisk.org/jira/browse/ASTERISK-25826 Got it, thanks. Basically, I think this could be resolved by a configuration option that stops sourcery/pjsip loading all peers at start-up as this is not needed for the current setup. This has been discussed before on the mailing list however it doesn't look like it progresses any further. If you're up for trying something, you can comment out the qualify_and_schedule_all function in lines 1135-1147 of res/res_pjsip/pjsip_options.c, then comment out its 2 references on lines 1245 and 1281. If that drops your startup times, then we know we're on the right track. I would like to thank you for all of your help tying to identify the issue and hope that we can resolve it soon. No worries! Kind regards, Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 16:27:06 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 3:07 PM, Ross Beer wrote: ok, That took 15 mins to load and then crashed. This will be due to the pjsip_dlg_create_uas_and_inc_lock commit. It should not have crashed. That commit had the fix for it. If it did crash with that commit, open a Jira issue and attach a full backtrace. However 15 mins to start is a long time and would cause issues in a production environment. Would you open a Jira issue on the realtime problem (if one isn't already open).I'm starting to look at alternatives. Thank you for your help here, Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 14:02:38 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 1:04 PM, Ross Beer wrote: Hi George, Using a development test box for testing!! Asterisk 13.7.2 with no cache takes 4:12 to load, that with PJSIP Commit 5240 Ok, try this combination..."git checkout c1bf014ea08cf66835a6f000e2bd6c7da588da6b"pjproject from trunk.with caching. The commit I referenced is the one that handles the pjsip_dlg_create_uas_and_inc_lock Qualify time on the aor is set to zero, I guess a query could be made to check for a value greater than zero instead of loading all endpoints. Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 12:45:28 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 12:21 PM, Ross Beer wrote: Hi George, No endpoints are qualified, there are 20,000 endpoints with only 75 static contacts defined in the aors. The database is a MySQL cluster. With the current Asterisk 13 branch with cache disabled and the latest PJSIP it takes 5 mins and then before finishing it crashes. With Asterisk 13.7.2 with cache it takes around 1 1/2 min to load, however due to the bug with PJSIP Commit 5241 asterisk crashes when using TLS devices. Try 13.7.2 without the cache. I'm trying to understand where the time is being spent. I know it will crash because of that bug. You're not doing this on a production system are you?? The main issue here is that the endpoints are loaded as soon as PJSIP loads, ideally endpoints would only be loaded once a device registers or attempts to make a call. Much in the same way as Asterisk 1.8 chan_sip manages realtime. There is no need to load the endpoints as they are not qualified. How do you know they're not qualified if you don't load them? :) Time to load up a database with 20,000 endpoints I guess. Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 11:58:15 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 11:38 AM, Michael Ulitskiy wrote: Hello, Please see this discussion http://lists.digium.com/pipermail/asterisk-dev/2015-October/075122.html I guess you're talking about the same problem. It's possible. Michael On Tuesday, March 01, 2016 06:26:27 PM Ross Beer wrote: > Hi George, > > We need to store contacts in realtime for our system. However not all > endpoints are registered only about 200, yet asterisk loops through every > endpoint which
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
On Wed, Mar 2, 2016 at 2:56 AM, Ross Beer wrote: > Hi George, > > I have re-built the 'c1bf014ea08cf66835a6f000e2bd6c7da588da6b' commit > and PJSIP and Asterisk hasn't crashed after reload. However it did take 25 > mins to load. > > As requested I have opened a ticket for the realtime issue: > > https://issues.asterisk.org/jira/browse/ASTERISK-25826 > Got it, thanks. > > > Basically, I think this could be resolved by a configuration option that > stops sourcery/pjsip loading all peers at start-up as this is not > needed for the current setup. This has been discussed before on the mailing > list however it doesn't look like it progresses any further. > If you're up for trying something, you can comment out the qualify_and_schedule_all function in line s 1135 -1147 of res/res_pjsip/pjsip_options.c, then comment out its 2 references on lines 1245 and 1281. If that drops your startup times, then we know we're on the right track. > > I would like to thank you for all of your help tying to identify the issue > and hope that we can resolve it soon. > No worries! > > Kind regards, > > Ross > > -- > From: george.jos...@fairview5.com > Date: Tue, 1 Mar 2016 16:27:06 -0700 > > To: asterisk-dev@lists.digium.com > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > On Tue, Mar 1, 2016 at 3:07 PM, Ross Beer wrote: > > ok, > > That took 15 mins to load and then crashed. This will be due to the > pjsip_dlg_create_uas_and_inc_lock commit. > > > It should not have crashed. That commit had the fix for it. If it did > crash with that commit, open a Jira issue and attach a full backtrace. > > > > > However 15 mins to start is a long time and would cause issues in a > production environment. > > > Would you open a Jira issue on the realtime problem (if one isn't already > open). > I'm starting to look at alternatives. > > > > > Thank you for your help here, > > Ross > > > -- > From: george.jos...@fairview5.com > Date: Tue, 1 Mar 2016 14:02:38 -0700 > > To: asterisk-dev@lists.digium.com > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > On Tue, Mar 1, 2016 at 1:04 PM, Ross Beer wrote: > > Hi George, > > Using a development test box for testing!! > > Asterisk 13.7.2 with no cache takes 4:12 to load, that with PJSIP Commit > 5240 > > > Ok, try this combination... > "git checkout c1bf014ea08cf66835a6f000e2bd6c7da588da6b" > pjproject from trunk. > with caching. > > The commit I referenced is the one that handles the > pjsip_dlg_create_uas_and_inc_lock > > > > > > > > Qualify time on the aor is set to zero, I guess a query could be made to > check for a value greater than zero instead of loading all endpoints. > > Ross > > -- > From: george.jos...@fairview5.com > Date: Tue, 1 Mar 2016 12:45:28 -0700 > > To: asterisk-dev@lists.digium.com > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > On Tue, Mar 1, 2016 at 12:21 PM, Ross Beer wrote: > > Hi George, > > No endpoints are qualified, there are 20,000 endpoints with only 75 static > contacts defined in the aors. The database is a MySQL cluster. > > With the current Asterisk 13 branch with cache disabled and the latest > PJSIP it takes 5 mins and then before finishing it crashes. > > With Asterisk 13.7.2 with cache it takes around 1 1/2 min to load, however > due to the bug with PJSIP Commit 5241 asterisk crashes when using TLS > devices. > > > Try 13.7.2 without the cache. I'm trying to understand where the time is > being spent. I know it will crash because of that bug. You're not doing > this on a production system are you?? > > > > The main issue here is that the endpoints are loaded as soon as PJSIP > loads, ideally endpoints would only be loaded once a device registers or > attempts to make a call. Much in the same way as Asterisk 1.8 chan_sip > manages realtime. > > There is no need to load the endpoints as they are not qualified. > > > How do you know they're not qualified if you don't load them? :) > > Time to load up a database with 20,000 endpoints I guess. > > > > Ross > > -- > From: george.jos...@fairview5.com > Date: Tue, 1 Mar 2016 11:58:15 -0700 > To: asterisk-dev@lists.digium.com > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > On Tue, Mar 1, 2016 at 11:38 AM, Michael Uli
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
Hi George, I have re-built the 'c1bf014ea08cf66835a6f000e2bd6c7da588da6b' commit and PJSIP and Asterisk hasn't crashed after reload. However it did take 25 mins to load. As requested I have opened a ticket for the realtime issue: https://issues.asterisk.org/jira/browse/ASTERISK-25826 Basically, I think this could be resolved by a configuration option that stops sourcery/pjsip loading all peers at start-up as this is not needed for the current setup. This has been discussed before on the mailing list however it doesn't look like it progresses any further. I would like to thank you for all of your help tying to identify the issue and hope that we can resolve it soon. Kind regards, Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 16:27:06 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 3:07 PM, Ross Beer wrote: ok, That took 15 mins to load and then crashed. This will be due to the pjsip_dlg_create_uas_and_inc_lock commit. It should not have crashed. That commit had the fix for it. If it did crash with that commit, open a Jira issue and attach a full backtrace. However 15 mins to start is a long time and would cause issues in a production environment. Would you open a Jira issue on the realtime problem (if one isn't already open).I'm starting to look at alternatives. Thank you for your help here, Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 14:02:38 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 1:04 PM, Ross Beer wrote: Hi George, Using a development test box for testing!! Asterisk 13.7.2 with no cache takes 4:12 to load, that with PJSIP Commit 5240 Ok, try this combination..."git checkout c1bf014ea08cf66835a6f000e2bd6c7da588da6b"pjproject from trunk.with caching. The commit I referenced is the one that handles the pjsip_dlg_create_uas_and_inc_lock Qualify time on the aor is set to zero, I guess a query could be made to check for a value greater than zero instead of loading all endpoints. Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 12:45:28 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 12:21 PM, Ross Beer wrote: Hi George, No endpoints are qualified, there are 20,000 endpoints with only 75 static contacts defined in the aors. The database is a MySQL cluster. With the current Asterisk 13 branch with cache disabled and the latest PJSIP it takes 5 mins and then before finishing it crashes. With Asterisk 13.7.2 with cache it takes around 1 1/2 min to load, however due to the bug with PJSIP Commit 5241 asterisk crashes when using TLS devices. Try 13.7.2 without the cache. I'm trying to understand where the time is being spent. I know it will crash because of that bug. You're not doing this on a production system are you?? The main issue here is that the endpoints are loaded as soon as PJSIP loads, ideally endpoints would only be loaded once a device registers or attempts to make a call. Much in the same way as Asterisk 1.8 chan_sip manages realtime. There is no need to load the endpoints as they are not qualified. How do you know they're not qualified if you don't load them? :) Time to load up a database with 20,000 endpoints I guess. Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 11:58:15 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 11:38 AM, Michael Ulitskiy wrote: Hello, Please see this discussion http://lists.digium.com/pipermail/asterisk-dev/2015-October/075122.html I guess you're talking about the same problem. It's possible. Michael On Tuesday, March 01, 2016 06:26:27 PM Ross Beer wrote: > Hi George, > > We need to store contacts in realtime for our system. However not all > endpoints are registered only about 200, yet asterisk loops through every > endpoint which has been defined. It does this if contacts are in realtime or > not. > > Its almost like pjsip is loading them to check if they need to be qualified > etc. > > Asterisk 1.8 only put things into cache once they were accessed, is this an > option for sourcery? Well, in order to initiate qualify of contacts, Asterisk does have to "access" them all so I'm not quite sure what the problem is. Can we reset to a known config and see what happens? pjproject from the published 2.4.5 tarball.Asterisk from the published 13.7.2 tarball.Disable memory_cache altogether in sorcery.conf. See what happens. Give me an estimate of how many endpoints and aors there are in the database, how many of thos
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
On Tue, Mar 1, 2016 at 3:07 PM, Ross Beer wrote: > ok, > > That took 15 mins to load and then crashed. This will be due to the > pjsip_dlg_create_uas_and_inc_lock commit. > It should not have crashed. That commit had the fix for it. If it did crash with that commit, open a Jira issue and attach a full backtrace. > > > However 15 mins to start is a long time and would cause issues in a > production environment. > Would you open a Jira issue on the realtime problem (if one isn't already open). I'm starting to look at alternatives. > > Thank you for your help here, > > Ross > > > -- > From: george.jos...@fairview5.com > Date: Tue, 1 Mar 2016 14:02:38 -0700 > > To: asterisk-dev@lists.digium.com > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > On Tue, Mar 1, 2016 at 1:04 PM, Ross Beer wrote: > > Hi George, > > Using a development test box for testing!! > > Asterisk 13.7.2 with no cache takes 4:12 to load, that with PJSIP Commit > 5240 > > > Ok, try this combination... > "git checkout c1bf014ea08cf66835a6f000e2bd6c7da588da6b" > pjproject from trunk. > with caching. > > The commit I referenced is the one that handles the > pjsip_dlg_create_uas_and_inc_lock > > > > > > > > Qualify time on the aor is set to zero, I guess a query could be made to > check for a value greater than zero instead of loading all endpoints. > > Ross > > ---------- > From: george.jos...@fairview5.com > Date: Tue, 1 Mar 2016 12:45:28 -0700 > > To: asterisk-dev@lists.digium.com > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > On Tue, Mar 1, 2016 at 12:21 PM, Ross Beer wrote: > > Hi George, > > No endpoints are qualified, there are 20,000 endpoints with only 75 static > contacts defined in the aors. The database is a MySQL cluster. > > With the current Asterisk 13 branch with cache disabled and the latest > PJSIP it takes 5 mins and then before finishing it crashes. > > With Asterisk 13.7.2 with cache it takes around 1 1/2 min to load, however > due to the bug with PJSIP Commit 5241 asterisk crashes when using TLS > devices. > > > Try 13.7.2 without the cache. I'm trying to understand where the time is > being spent. I know it will crash because of that bug. You're not doing > this on a production system are you?? > > > > The main issue here is that the endpoints are loaded as soon as PJSIP > loads, ideally endpoints would only be loaded once a device registers or > attempts to make a call. Much in the same way as Asterisk 1.8 chan_sip > manages realtime. > > There is no need to load the endpoints as they are not qualified. > > > How do you know they're not qualified if you don't load them? :) > > Time to load up a database with 20,000 endpoints I guess. > > > > Ross > > -- > From: george.jos...@fairview5.com > Date: Tue, 1 Mar 2016 11:58:15 -0700 > To: asterisk-dev@lists.digium.com > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > On Tue, Mar 1, 2016 at 11:38 AM, Michael Ulitskiy > wrote: > > Hello, > > > > Please see this discussion > http://lists.digium.com/pipermail/asterisk-dev/2015-October/075122.html > > I guess you're talking about the same problem. > > > It's possible. > > > > > > Michael > > > > On Tuesday, March 01, 2016 06:26:27 PM Ross Beer wrote: > > > Hi George, > > > > > > We need to store contacts in realtime for our system. However not all > endpoints are registered only about 200, yet asterisk loops through every > endpoint which has been defined. It does this if contacts are in realtime > or not. > > > > > > Its almost like pjsip is loading them to check if they need to be > qualified etc. > > > > > > Asterisk 1.8 only put things into cache once they were accessed, is this > an option for sourcery? > > > Well, in order to initiate qualify of contacts, Asterisk does have to > "access" them all so I'm not quite sure what the problem is. > > Can we reset to a known config and see what happens? > > pjproject from the published 2.4.5 tarball. > Asterisk from the published 13.7.2 tarball. > Disable memory_cache altogether in sorcery.conf. > > See what happens. > > Give me an estimate of how many endpoints and aors there are in the > database, how many of those aors have static contacts defined, and what's > your qualify interval. > > An idea
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
ok, That took 15 mins to load and then crashed. This will be due to the pjsip_dlg_create_uas_and_inc_lock commit. However 15 mins to start is a long time and would cause issues in a production environment. Thank you for your help here, Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 14:02:38 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 1:04 PM, Ross Beer wrote: Hi George, Using a development test box for testing!! Asterisk 13.7.2 with no cache takes 4:12 to load, that with PJSIP Commit 5240 Ok, try this combination..."git checkout c1bf014ea08cf66835a6f000e2bd6c7da588da6b"pjproject from trunk.with caching. The commit I referenced is the one that handles the pjsip_dlg_create_uas_and_inc_lock Qualify time on the aor is set to zero, I guess a query could be made to check for a value greater than zero instead of loading all endpoints. Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 12:45:28 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 12:21 PM, Ross Beer wrote: Hi George, No endpoints are qualified, there are 20,000 endpoints with only 75 static contacts defined in the aors. The database is a MySQL cluster. With the current Asterisk 13 branch with cache disabled and the latest PJSIP it takes 5 mins and then before finishing it crashes. With Asterisk 13.7.2 with cache it takes around 1 1/2 min to load, however due to the bug with PJSIP Commit 5241 asterisk crashes when using TLS devices. Try 13.7.2 without the cache. I'm trying to understand where the time is being spent. I know it will crash because of that bug. You're not doing this on a production system are you?? The main issue here is that the endpoints are loaded as soon as PJSIP loads, ideally endpoints would only be loaded once a device registers or attempts to make a call. Much in the same way as Asterisk 1.8 chan_sip manages realtime. There is no need to load the endpoints as they are not qualified. How do you know they're not qualified if you don't load them? :) Time to load up a database with 20,000 endpoints I guess. Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 11:58:15 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 11:38 AM, Michael Ulitskiy wrote: Hello, Please see this discussion http://lists.digium.com/pipermail/asterisk-dev/2015-October/075122.html I guess you're talking about the same problem. It's possible. Michael On Tuesday, March 01, 2016 06:26:27 PM Ross Beer wrote: > Hi George, > > We need to store contacts in realtime for our system. However not all > endpoints are registered only about 200, yet asterisk loops through every > endpoint which has been defined. It does this if contacts are in realtime or > not. > > Its almost like pjsip is loading them to check if they need to be qualified > etc. > > Asterisk 1.8 only put things into cache once they were accessed, is this an > option for sourcery? Well, in order to initiate qualify of contacts, Asterisk does have to "access" them all so I'm not quite sure what the problem is. Can we reset to a known config and see what happens? pjproject from the published 2.4.5 tarball.Asterisk from the published 13.7.2 tarball.Disable memory_cache altogether in sorcery.conf. See what happens. Give me an estimate of how many endpoints and aors there are in the database, how many of those aors have static contacts defined, and what's your qualify interval. An idea of your database setup would help as well. Same server, local, remote, etc. Let's solve 1 problem at a time. -- _ -- 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 -- _ -- 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 -- _ -- 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 -- _ -- Bandwidth and Colocation Provided by http://
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
On Tue, Mar 1, 2016 at 1:04 PM, Ross Beer wrote: > Hi George, > > Using a development test box for testing!! > > Asterisk 13.7.2 with no cache takes 4:12 to load, that with PJSIP Commit > 5240 > Ok, try this combination... "git checkout c1bf014ea08cf66835a6f000e2bd6c7da588da6b" pjproject from trunk. with caching. The commit I referenced is the one that handles the pjsip_dlg_create_uas_and_inc_lock > > Qualify time on the aor is set to zero, I guess a query could be made to > check for a value greater than zero instead of loading all endpoints. > > Ross > > -- > From: george.jos...@fairview5.com > Date: Tue, 1 Mar 2016 12:45:28 -0700 > > To: asterisk-dev@lists.digium.com > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > On Tue, Mar 1, 2016 at 12:21 PM, Ross Beer wrote: > > Hi George, > > No endpoints are qualified, there are 20,000 endpoints with only 75 static > contacts defined in the aors. The database is a MySQL cluster. > > With the current Asterisk 13 branch with cache disabled and the latest > PJSIP it takes 5 mins and then before finishing it crashes. > > With Asterisk 13.7.2 with cache it takes around 1 1/2 min to load, however > due to the bug with PJSIP Commit 5241 asterisk crashes when using TLS > devices. > > > Try 13.7.2 without the cache. I'm trying to understand where the time is > being spent. I know it will crash because of that bug. You're not doing > this on a production system are you?? > > > > The main issue here is that the endpoints are loaded as soon as PJSIP > loads, ideally endpoints would only be loaded once a device registers or > attempts to make a call. Much in the same way as Asterisk 1.8 chan_sip > manages realtime. > > There is no need to load the endpoints as they are not qualified. > > > How do you know they're not qualified if you don't load them? :) > > Time to load up a database with 20,000 endpoints I guess. > > > > Ross > > ------ > From: george.jos...@fairview5.com > Date: Tue, 1 Mar 2016 11:58:15 -0700 > To: asterisk-dev@lists.digium.com > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > On Tue, Mar 1, 2016 at 11:38 AM, Michael Ulitskiy > wrote: > > Hello, > > > > Please see this discussion > http://lists.digium.com/pipermail/asterisk-dev/2015-October/075122.html > > I guess you're talking about the same problem. > > > It's possible. > > > > > > Michael > > > > On Tuesday, March 01, 2016 06:26:27 PM Ross Beer wrote: > > > Hi George, > > > > > > We need to store contacts in realtime for our system. However not all > endpoints are registered only about 200, yet asterisk loops through every > endpoint which has been defined. It does this if contacts are in realtime > or not. > > > > > > Its almost like pjsip is loading them to check if they need to be > qualified etc. > > > > > > Asterisk 1.8 only put things into cache once they were accessed, is this > an option for sourcery? > > > Well, in order to initiate qualify of contacts, Asterisk does have to > "access" them all so I'm not quite sure what the problem is. > > Can we reset to a known config and see what happens? > > pjproject from the published 2.4.5 tarball. > Asterisk from the published 13.7.2 tarball. > Disable memory_cache altogether in sorcery.conf. > > See what happens. > > Give me an estimate of how many endpoints and aors there are in the > database, how many of those aors have static contacts defined, and what's > your qualify interval. > > An idea of your database setup would help as well. Same server, local, > remote, etc. > > Let's solve 1 problem at a time. > > > > > > -- _ > -- 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 > > -- > _ > -- 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 > > > > -- _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > asterisk-dev mailing list To UNSUBSCRIBE or update options vi
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
Hi George, Using a development test box for testing!! Asterisk 13.7.2 with no cache takes 4:12 to load, that with PJSIP Commit 5240 Qualify time on the aor is set to zero, I guess a query could be made to check for a value greater than zero instead of loading all endpoints. Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 12:45:28 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 12:21 PM, Ross Beer wrote: Hi George, No endpoints are qualified, there are 20,000 endpoints with only 75 static contacts defined in the aors. The database is a MySQL cluster. With the current Asterisk 13 branch with cache disabled and the latest PJSIP it takes 5 mins and then before finishing it crashes. With Asterisk 13.7.2 with cache it takes around 1 1/2 min to load, however due to the bug with PJSIP Commit 5241 asterisk crashes when using TLS devices. Try 13.7.2 without the cache. I'm trying to understand where the time is being spent. I know it will crash because of that bug. You're not doing this on a production system are you?? The main issue here is that the endpoints are loaded as soon as PJSIP loads, ideally endpoints would only be loaded once a device registers or attempts to make a call. Much in the same way as Asterisk 1.8 chan_sip manages realtime. There is no need to load the endpoints as they are not qualified. How do you know they're not qualified if you don't load them? :) Time to load up a database with 20,000 endpoints I guess. Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 11:58:15 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 11:38 AM, Michael Ulitskiy wrote: Hello, Please see this discussion http://lists.digium.com/pipermail/asterisk-dev/2015-October/075122.html I guess you're talking about the same problem. It's possible. Michael On Tuesday, March 01, 2016 06:26:27 PM Ross Beer wrote: > Hi George, > > We need to store contacts in realtime for our system. However not all > endpoints are registered only about 200, yet asterisk loops through every > endpoint which has been defined. It does this if contacts are in realtime or > not. > > Its almost like pjsip is loading them to check if they need to be qualified > etc. > > Asterisk 1.8 only put things into cache once they were accessed, is this an > option for sourcery? Well, in order to initiate qualify of contacts, Asterisk does have to "access" them all so I'm not quite sure what the problem is. Can we reset to a known config and see what happens? pjproject from the published 2.4.5 tarball.Asterisk from the published 13.7.2 tarball.Disable memory_cache altogether in sorcery.conf. See what happens. Give me an estimate of how many endpoints and aors there are in the database, how many of those aors have static contacts defined, and what's your qualify interval. An idea of your database setup would help as well. Same server, local, remote, etc. Let's solve 1 problem at a time. -- _ -- 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 -- _ -- 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 -- _ -- 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 -- _ -- 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
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
On Tue, Mar 1, 2016 at 12:21 PM, Ross Beer wrote: > Hi George, > > No endpoints are qualified, there are 20,000 endpoints with only 75 static > contacts defined in the aors. The database is a MySQL cluster. > > With the current Asterisk 13 branch with cache disabled and the latest > PJSIP it takes 5 mins and then before finishing it crashes. > > With Asterisk 13.7.2 with cache it takes around 1 1/2 min to load, however > due to the bug with PJSIP Commit 5241 asterisk crashes when using TLS > devices. > Try 13.7.2 without the cache. I'm trying to understand where the time is being spent. I know it will crash because of that bug. You're not doing this on a production system are you?? > > The main issue here is that the endpoints are loaded as soon as PJSIP > loads, ideally endpoints would only be loaded once a device registers or > attempts to make a call. Much in the same way as Asterisk 1.8 chan_sip > manages realtime. > > There is no need to load the endpoints as they are not qualified. > How do you know they're not qualified if you don't load them? :) Time to load up a database with 20,000 endpoints I guess. > > Ross > > -- > From: george.jos...@fairview5.com > Date: Tue, 1 Mar 2016 11:58:15 -0700 > To: asterisk-dev@lists.digium.com > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > On Tue, Mar 1, 2016 at 11:38 AM, Michael Ulitskiy > wrote: > > Hello, > > > > Please see this discussion > http://lists.digium.com/pipermail/asterisk-dev/2015-October/075122.html > > I guess you're talking about the same problem. > > > It's possible. > > > > > > Michael > > > > On Tuesday, March 01, 2016 06:26:27 PM Ross Beer wrote: > > > Hi George, > > > > > > We need to store contacts in realtime for our system. However not all > endpoints are registered only about 200, yet asterisk loops through every > endpoint which has been defined. It does this if contacts are in realtime > or not. > > > > > > Its almost like pjsip is loading them to check if they need to be > qualified etc. > > > > > > Asterisk 1.8 only put things into cache once they were accessed, is this > an option for sourcery? > > > Well, in order to initiate qualify of contacts, Asterisk does have to > "access" them all so I'm not quite sure what the problem is. > > Can we reset to a known config and see what happens? > > pjproject from the published 2.4.5 tarball. > Asterisk from the published 13.7.2 tarball. > Disable memory_cache altogether in sorcery.conf. > > See what happens. > > Give me an estimate of how many endpoints and aors there are in the > database, how many of those aors have static contacts defined, and what's > your qualify interval. > > An idea of your database setup would help as well. Same server, local, > remote, etc. > > Let's solve 1 problem at a time. > > > > > > -- _ > -- 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 > > -- > _ > -- 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 > -- _ -- 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
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
Hi George, No endpoints are qualified, there are 20,000 endpoints with only 75 static contacts defined in the aors. The database is a MySQL cluster. With the current Asterisk 13 branch with cache disabled and the latest PJSIP it takes 5 mins and then before finishing it crashes. With Asterisk 13.7.2 with cache it takes around 1 1/2 min to load, however due to the bug with PJSIP Commit 5241 asterisk crashes when using TLS devices. The main issue here is that the endpoints are loaded as soon as PJSIP loads, ideally endpoints would only be loaded once a device registers or attempts to make a call. Much in the same way as Asterisk 1.8 chan_sip manages realtime. There is no need to load the endpoints as they are not qualified. Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 11:58:15 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 11:38 AM, Michael Ulitskiy wrote: Hello, Please see this discussion http://lists.digium.com/pipermail/asterisk-dev/2015-October/075122.html I guess you're talking about the same problem. It's possible. Michael On Tuesday, March 01, 2016 06:26:27 PM Ross Beer wrote: > Hi George, > > We need to store contacts in realtime for our system. However not all > endpoints are registered only about 200, yet asterisk loops through every > endpoint which has been defined. It does this if contacts are in realtime or > not. > > Its almost like pjsip is loading them to check if they need to be qualified > etc. > > Asterisk 1.8 only put things into cache once they were accessed, is this an > option for sourcery? Well, in order to initiate qualify of contacts, Asterisk does have to "access" them all so I'm not quite sure what the problem is. Can we reset to a known config and see what happens? pjproject from the published 2.4.5 tarball.Asterisk from the published 13.7.2 tarball.Disable memory_cache altogether in sorcery.conf. See what happens. Give me an estimate of how many endpoints and aors there are in the database, how many of those aors have static contacts defined, and what's your qualify interval. An idea of your database setup would help as well. Same server, local, remote, etc. Let's solve 1 problem at a time. -- _ -- 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 -- _ -- 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
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
On Tue, Mar 1, 2016 at 11:38 AM, Michael Ulitskiy wrote: > Hello, > > > > Please see this discussion > http://lists.digium.com/pipermail/asterisk-dev/2015-October/075122.html > > I guess you're talking about the same problem. > It's possible. > > > Michael > > > > On Tuesday, March 01, 2016 06:26:27 PM Ross Beer wrote: > > > Hi George, > > > > > > We need to store contacts in realtime for our system. However not all > endpoints are registered only about 200, yet asterisk loops through every > endpoint which has been defined. It does this if contacts are in realtime > or not. > > > > > > Its almost like pjsip is loading them to check if they need to be > qualified etc. > > > > > > Asterisk 1.8 only put things into cache once they were accessed, is this > an option for sourcery? > Well, in order to initiate qualify of contacts, Asterisk does have to "access" them all so I'm not quite sure what the problem is. Can we reset to a known config and see what happens? pjproject from the published 2.4.5 tarball. Asterisk from the published 13.7.2 tarball. Disable memory_cache altogether in sorcery.conf. See what happens. Give me an estimate of how many endpoints and aors there are in the database, how many of those aors have static contacts defined, and what's your qualify interval. An idea of your database setup would help as well. Same server, local, remote, etc. Let's solve 1 problem at a time. > > -- _ -- 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
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
Hello, Please see this discussion http://lists.digium.com/pipermail/asterisk-dev/2015-October/075122.html I guess you're talking about the same problem. Michael On Tuesday, March 01, 2016 06:26:27 PM Ross Beer wrote: > Hi George, > > We need to store contacts in realtime for our system. However not all > endpoints are registered only about 200, yet asterisk loops through every > endpoint which has been defined. It does this if contacts are in realtime or > not. > > Its almost like pjsip is loading them to check if they need to be qualified > etc. > > Asterisk 1.8 only put things into cache once they were accessed, is this an > option for sourcery? > > Thanks, > > Ross > > From: george.jos...@fairview5.com > Date: Tue, 1 Mar 2016 10:42:58 -0700 > To: asterisk-dev@lists.digium.com > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > On Tue, Mar 1, 2016 at 10:29 AM, Ross Beer wrote: > > > > Hi George, > > I have now got asterisk 13 trunk, however loading is very slow. This is due > to asterisk reading all of the realtime Sorcery peers and marking them all as > 'Unknown'. Is there a way to only cache peers that have tried to register? > > > When you say "Asterisk 13 trunk" you do mean "branch" correct? > Assuming you have contacts coming from realtime, the only was to prevent > them from being qualified is to delete them from the ps_contacts table > before starting Asterisk. You really don't gain anything by using realtime > for contacts anyway. I'd just disable it and let Asterisk use the internal > sqlite3 database to keep track of them. > > So far its taking 20 mins to load!! > > Also asterisk has the following warning: > > taskprocessor.c:803 taskprocessor_push: The > 'subm:ast_device_state_topic-55d0' task processor queue reached 500 > scheduled tasks. > > > Whoa! This makes me think I might have messed something up in the fix for > contacts not being cached correctly. > Don't use realtime for contacts and see what happens. I'm going to re-test. > Neither were issues in the previous release. > > Thank you for your assistance, > > Ross > > From: george.jos...@fairview5.com > Date: Tue, 1 Mar 2016 09:08:37 -0700 > To: asterisk-dev@lists.digium.com > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > On Tue, Mar 1, 2016 at 5:58 AM, Ross Beer wrote: > > > > Further to my previous email it appears this bug won't be easily resolved by > changing the method: > > pjsip_dlg_create_uas() >> pjsip_dlg_create_uas_and_inc_lock(). > > Asterisk starts ok, allows registrations but no calls progress. > > > You have to pull Asterisk from the 13 branch. This should have been fixed > with review 2236 and I've been running with that patch and pjproject trunk. > > > From: ross.b...@outlook.com > To: asterisk-dev@lists.digium.com > Date: Tue, 1 Mar 2016 11:49:55 + > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > > I've just found an open issue for this > https://issues.asterisk.org/jira/browse/ASTERISK-25751 > > > From: ross.b...@outlook.com > To: asterisk-dev@lists.digium.com > Date: Tue, 1 Mar 2016 11:06:09 + > Subject: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > > Hi, > > Since PJSIP Commit 5241 (https://trac.pjsip.org/repos/changeset/5241) > Asterisk crashes when a device registers. > > The commit resolves the following: > > • Crash when endpoint has multiple worker threads and SIP TCP transport is > disconnected during incoming call handling. > • Deprecated pjsip_dlg_create_uas(), replaced by > pjsip_dlg_create_uas_and_inc_lock(). > • Serialized transaction state notifications (of 'terminated' and > 'destroyed') in case of transport error. > > This commit should resolve a previous segfault within Asterisk, however due > to the deprecated method I believe this is causing an additional issue. > > Can this be easily resolved to resolve both segfaults? > > Kind regards, > > Ross > > > > > > > -- _ -- 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
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
Hi George, We need to store contacts in realtime for our system. However not all endpoints are registered only about 200, yet asterisk loops through every endpoint which has been defined. It does this if contacts are in realtime or not. Its almost like pjsip is loading them to check if they need to be qualified etc. Asterisk 1.8 only put things into cache once they were accessed, is this an option for sourcery? Thanks, Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 10:42:58 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 10:29 AM, Ross Beer wrote: Hi George, I have now got asterisk 13 trunk, however loading is very slow. This is due to asterisk reading all of the realtime Sorcery peers and marking them all as 'Unknown'. Is there a way to only cache peers that have tried to register? When you say "Asterisk 13 trunk" you do mean "branch" correct? Assuming you have contacts coming from realtime, the only was to prevent them from being qualified is to delete them from the ps_contacts table before starting Asterisk. You really don't gain anything by using realtime for contacts anyway. I'd just disable it and let Asterisk use the internal sqlite3 database to keep track of them. So far its taking 20 mins to load!! Also asterisk has the following warning: taskprocessor.c:803 taskprocessor_push: The 'subm:ast_device_state_topic-55d0' task processor queue reached 500 scheduled tasks. Whoa! This makes me think I might have messed something up in the fix for contacts not being cached correctly. Don't use realtime for contacts and see what happens. I'm going to re-test. Neither were issues in the previous release. Thank you for your assistance, Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 09:08:37 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 5:58 AM, Ross Beer wrote: Further to my previous email it appears this bug won't be easily resolved by changing the method: pjsip_dlg_create_uas() >> pjsip_dlg_create_uas_and_inc_lock(). Asterisk starts ok, allows registrations but no calls progress. You have to pull Asterisk from the 13 branch. This should have been fixed with review 2236 and I've been running with that patch and pjproject trunk. From: ross.b...@outlook.com To: asterisk-dev@lists.digium.com Date: Tue, 1 Mar 2016 11:49:55 + Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 I've just found an open issue for this https://issues.asterisk.org/jira/browse/ASTERISK-25751 From: ross.b...@outlook.com To: asterisk-dev@lists.digium.com Date: Tue, 1 Mar 2016 11:06:09 + Subject: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 Hi, Since PJSIP Commit 5241 (https://trac.pjsip.org/repos/changeset/5241) Asterisk crashes when a device registers. The commit resolves the following: • Crash when endpoint has multiple worker threads and SIP TCP transport is disconnected during incoming call handling. • Deprecated pjsip_dlg_create_uas(), replaced by pjsip_dlg_create_uas_and_inc_lock(). • Serialized transaction state notifications (of 'terminated' and 'destroyed') in case of transport error. This commit should resolve a previous segfault within Asterisk, however due to the deprecated method I believe this is causing an additional issue. Can this be easily resolved to resolve both segfaults? Kind regards, Ross -- _ -- 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 -- _ -- 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 -- _ -- 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 -- _ -- 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 --
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
On Tue, Mar 1, 2016 at 10:29 AM, Ross Beer wrote: > Hi George, > > I have now got asterisk 13 trunk, however loading is very slow. This is > due to asterisk reading all of the realtime Sorcery peers and marking them > all as 'Unknown'. Is there a way to only cache peers that have tried to > register? > When you say "Asterisk 13 trunk" you do mean "branch" correct? Assuming you have contacts coming from realtime, the only was to prevent them from being qualified is to delete them from the ps_contacts table before starting Asterisk. You really don't gain anything by using realtime for contacts anyway. I'd just disable it and let Asterisk use the internal sqlite3 database to keep track of them. > > So far its taking 20 mins to load!! > > Also asterisk has the following warning: > > taskprocessor.c:803 taskprocessor_push: The > 'subm:ast_device_state_topic-55d0' task processor queue reached 500 > scheduled tasks. > > Whoa! This makes me think I might have messed something up in the fix for contacts not being cached correctly. Don't use realtime for contacts and see what happens. I'm going to re-test. > Neither were issues in the previous release. > > Thank you for your assistance, > > Ross > > -- > From: george.jos...@fairview5.com > Date: Tue, 1 Mar 2016 09:08:37 -0700 > To: asterisk-dev@lists.digium.com > > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > > On Tue, Mar 1, 2016 at 5:58 AM, Ross Beer wrote: > > Further to my previous email it appears this bug won't be easily resolved > by changing the method: > > pjsip_dlg_create_uas() >> pjsip_dlg_create_uas_and_inc_lock(). > > Asterisk starts ok, allows registrations but no calls progress. > > > > You have to pull Asterisk from the 13 branch. This should have been > fixed with review 2236 and I've been running with that patch and pjproject > trunk. > > > > > -- > From: ross.b...@outlook.com > To: asterisk-dev@lists.digium.com > Date: Tue, 1 Mar 2016 11:49:55 + > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > I've just found an open issue for this > https://issues.asterisk.org/jira/browse/ASTERISK-25751 > > > -- > From: ross.b...@outlook.com > To: asterisk-dev@lists.digium.com > Date: Tue, 1 Mar 2016 11:06:09 + > Subject: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > Hi, > > Since PJSIP Commit 5241 (https://trac.pjsip.org/repos/changeset/5241) > Asterisk crashes when a device registers. > > The commit resolves the following: > > • Crash when endpoint has multiple worker threads and SIP TCP transport is > disconnected during incoming call handling. > • Deprecated pjsip_dlg_create_uas(), replaced by > pjsip_dlg_create_uas_and_inc_lock(). > • Serialized transaction state notifications (of 'terminated' and > 'destroyed') in case of transport error. > > This commit should resolve a previous segfault within Asterisk, however > due to the deprecated method I believe this is causing an additional issue. > > Can this be easily resolved to resolve both segfaults? > > Kind regards, > > Ross > > > > > > -- _ > -- 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 > > -- _ > -- 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 > > -- > _ > -- 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 > > > > -- _ > -- 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 > > -- > _ > -- 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 > -- _ -- 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
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
Hi George, I have now got asterisk 13 trunk, however loading is very slow. This is due to asterisk reading all of the realtime Sorcery peers and marking them all as 'Unknown'. Is there a way to only cache peers that have tried to register? So far its taking 20 mins to load!! Also asterisk has the following warning: taskprocessor.c:803 taskprocessor_push: The 'subm:ast_device_state_topic-55d0' task processor queue reached 500 scheduled tasks. Neither were issues in the previous release. Thank you for your assistance, Ross From: george.jos...@fairview5.com Date: Tue, 1 Mar 2016 09:08:37 -0700 To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 On Tue, Mar 1, 2016 at 5:58 AM, Ross Beer wrote: Further to my previous email it appears this bug won't be easily resolved by changing the method: pjsip_dlg_create_uas() >> pjsip_dlg_create_uas_and_inc_lock(). Asterisk starts ok, allows registrations but no calls progress. You have to pull Asterisk from the 13 branch. This should have been fixed with review 2236 and I've been running with that patch and pjproject trunk. From: ross.b...@outlook.com To: asterisk-dev@lists.digium.com Date: Tue, 1 Mar 2016 11:49:55 + Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 I've just found an open issue for this https://issues.asterisk.org/jira/browse/ASTERISK-25751 From: ross.b...@outlook.com To: asterisk-dev@lists.digium.com Date: Tue, 1 Mar 2016 11:06:09 + Subject: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 Hi, Since PJSIP Commit 5241 (https://trac.pjsip.org/repos/changeset/5241) Asterisk crashes when a device registers. The commit resolves the following: • Crash when endpoint has multiple worker threads and SIP TCP transport is disconnected during incoming call handling. • Deprecated pjsip_dlg_create_uas(), replaced by pjsip_dlg_create_uas_and_inc_lock(). • Serialized transaction state notifications (of 'terminated' and 'destroyed') in case of transport error. This commit should resolve a previous segfault within Asterisk, however due to the deprecated method I believe this is causing an additional issue. Can this be easily resolved to resolve both segfaults? Kind regards, Ross -- _ -- 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 -- _ -- 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 -- _ -- 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 -- _ -- 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 -- _ -- 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
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
On Tue, Mar 1, 2016 at 5:58 AM, Ross Beer wrote: > Further to my previous email it appears this bug won't be easily resolved > by changing the method: > > pjsip_dlg_create_uas() >> pjsip_dlg_create_uas_and_inc_lock(). > > Asterisk starts ok, allows registrations but no calls progress. > You have to pull Asterisk from the 13 branch. This should have been fixed with review 2236 and I've been running with that patch and pjproject trunk. > > -- > From: ross.b...@outlook.com > To: asterisk-dev@lists.digium.com > Date: Tue, 1 Mar 2016 11:49:55 +0000 > Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > > I've just found an open issue for this > https://issues.asterisk.org/jira/browse/ASTERISK-25751 > > > -- > From: ross.b...@outlook.com > To: asterisk-dev@lists.digium.com > Date: Tue, 1 Mar 2016 11:06:09 + > Subject: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 > > Hi, > > Since PJSIP Commit 5241 (https://trac.pjsip.org/repos/changeset/5241) > Asterisk crashes when a device registers. > > The commit resolves the following: > > • Crash when endpoint has multiple worker threads and SIP TCP transport is > disconnected during incoming call handling. > • Deprecated pjsip_dlg_create_uas(), replaced by > pjsip_dlg_create_uas_and_inc_lock(). > • Serialized transaction state notifications (of 'terminated' and > 'destroyed') in case of transport error. > > This commit should resolve a previous segfault within Asterisk, however > due to the deprecated method I believe this is causing an additional issue. > > Can this be easily resolved to resolve both segfaults? > > Kind regards, > > Ross > > > > > > -- _ > -- 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 > > -- _ > -- 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 > > -- > _ > -- 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 > -- _ -- 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
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
Further to my previous email it appears this bug won't be easily resolved by changing the method: pjsip_dlg_create_uas() >> pjsip_dlg_create_uas_and_inc_lock(). Asterisk starts ok, allows registrations but no calls progress. From: ross.b...@outlook.com To: asterisk-dev@lists.digium.com Date: Tue, 1 Mar 2016 11:49:55 + Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 I've just found an open issue for this https://issues.asterisk.org/jira/browse/ASTERISK-25751 From: ross.b...@outlook.com To: asterisk-dev@lists.digium.com Date: Tue, 1 Mar 2016 11:06:09 + Subject: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 Hi, Since PJSIP Commit 5241 (https://trac.pjsip.org/repos/changeset/5241) Asterisk crashes when a device registers. The commit resolves the following: • Crash when endpoint has multiple worker threads and SIP TCP transport is disconnected during incoming call handling. • Deprecated pjsip_dlg_create_uas(), replaced by pjsip_dlg_create_uas_and_inc_lock(). • Serialized transaction state notifications (of 'terminated' and 'destroyed') in case of transport error. This commit should resolve a previous segfault within Asterisk, however due to the deprecated method I believe this is causing an additional issue. Can this be easily resolved to resolve both segfaults? Kind regards, Ross -- _ -- 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 -- _ -- 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 -- _ -- 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
Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
I've just found an open issue for this https://issues.asterisk.org/jira/browse/ASTERISK-25751 From: ross.b...@outlook.com To: asterisk-dev@lists.digium.com Date: Tue, 1 Mar 2016 11:06:09 + Subject: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241 Hi, Since PJSIP Commit 5241 (https://trac.pjsip.org/repos/changeset/5241) Asterisk crashes when a device registers. The commit resolves the following: • Crash when endpoint has multiple worker threads and SIP TCP transport is disconnected during incoming call handling. • Deprecated pjsip_dlg_create_uas(), replaced by pjsip_dlg_create_uas_and_inc_lock(). • Serialized transaction state notifications (of 'terminated' and 'destroyed') in case of transport error. This commit should resolve a previous segfault within Asterisk, however due to the deprecated method I believe this is causing an additional issue. Can this be easily resolved to resolve both segfaults? Kind regards, Ross -- _ -- 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 -- _ -- 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
[asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
Hi, Since PJSIP Commit 5241 (https://trac.pjsip.org/repos/changeset/5241) Asterisk crashes when a device registers. The commit resolves the following: • Crash when endpoint has multiple worker threads and SIP TCP transport is disconnected during incoming call handling. • Deprecated pjsip_dlg_create_uas(), replaced by pjsip_dlg_create_uas_and_inc_lock(). • Serialized transaction state notifications (of 'terminated' and 'destroyed') in case of transport error. This commit should resolve a previous segfault within Asterisk, however due to the deprecated method I believe this is causing an additional issue. Can this be easily resolved to resolve both segfaults? Kind regards, Ross -- _ -- 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
