| 00:40.56 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@68-118-182-198.dhcp.asfd.ct.charter.com) |
| 00:55.46 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@68-118-182-198.dhcp.asfd.ct.charter.com) |
| 03:23.06 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-ltxozmrhrdwosuma) |
| 05:55.20 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 05:59.15 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-14.wall.uls.co.za) |
| 06:33.20 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 06:33.20 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:49.38 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:12.41 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:18.07 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:18.07 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:27.37 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 07:27.38 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:41.06 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:05.34 | *** join/#asterisk-dev CELYA_ (~Thunderbi@lcy44-2-88-161-121-174.fbx.proxad.net) |
| 09:41.34 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 10:12.55 | *** join/#asterisk-dev oej (~oej@195.149.146.45) |
| 10:12.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:34.30 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 11:58.42 | *** join/#asterisk-dev acidfu_ (~acidfoo@modemcable002.114-70-69.static.videotron.ca) |
| 12:28.46 | *** join/#asterisk-dev pc-m (~user@modemcable094.94-70-69.static.videotron.ca) |
| 12:44.57 | *** join/#asterisk-dev WIMPy (~wimpy@85.183.95.26) |
| 13:10.33 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-lxegpxoqtnfiogju) |
| 13:26.51 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-jwxlbmjvolnrvjgb) |
| 13:28.08 | *** join/#asterisk-dev mschadt (uid6028@gateway/web/irccloud.com/x-bpsadlzivyuloxcr) |
| 13:57.42 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-gvuiajptzzzwfwdw) |
| 14:08.07 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-vpwebvlpdjzioxsr) |
| 14:11.36 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-wnzrvxgmnsfqwlov) |
| 14:12.22 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:12.22 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:24.15 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:24.15 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:24.23 | cresl1n | waves |
| 14:36.16 | file | Moo |
| 14:38.19 | cresl1n | file! |
| 14:38.21 | cresl1n | Good morning |
| 14:38.31 | cresl1n | Or rather, happy lunch? |
| 14:39.06 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-pcdnrrckobrkkbfi) |
| 14:39.25 | cresl1n | pins leedm777 to the channel |
| 14:39.59 | leedm777 | squirms |
| 14:40.15 | file | cresl1n, yes! lunch! |
| 14:40.17 | file | cresl1n, get my email of needful? |
| 14:40.42 | cresl1n | I will - I'm trying to give gerrit some love before I go over the weekend backlog of emails |
| 14:40.59 | file | cresl1n, it was just a "I'm extending my vacation" email :P |
| 14:41.16 | file | putnopvut, your SIP device state notification change broke it against 11 |
| 14:41.27 | putnopvut | barrrf |
| 14:41.36 | putnopvut | I take it there's a different event I need to listen for in 11 |
| 14:41.44 | cresl1n | file: unapproved. There shall be no vacations! |
| 14:41.47 | file | https://jenkins.asterisk.org/jenkins/job/periodic-asterisk-11/271/testReport/ |
| 14:41.48 | cresl1n | NO VACATIONS |
| 14:41.54 | cresl1n | Just joking of course :-) |
| 14:42.01 | file | smirks at cresl1n |
| 14:42.05 | cresl1n | Have a great vacation |
| 14:46.16 | file | gtjoseph, can you give eyes on Improve realtime performance #2? |
| 14:46.35 | gtjoseph | yep, i have time set aside this morning to do it. |
| 14:51.26 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-yijnhyhtovsnnwxp) |
| 14:51.33 | *** join/#asterisk-dev bof23 (~Thunderbi@185.13.183.107) |
| 14:55.08 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-dxawoilnssqjfzqp) |
| 15:18.40 | file | oh good lord I almost said "Alexa, skip" out loud in Wendy's |
| 15:19.08 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-14.wall.uls.co.za) |
| 15:26.45 | rmudgett | file: Duct tape will work for that problem as well. :) |
| 15:27.03 | file | duct tapes rmudgett to his desk |
| 15:27.29 | rmudgett | Ineffictive as I am already glued to it. |
| 15:35.27 | file | rmudgett, https://issues.asterisk.org/jira/browse/ASTERISK-26101 seems like something we'd... run... across... |
| 15:43.39 | rmudgett | file: As A has hung up there is no real need for B to unhold A. |
| 16:03.06 | gtjoseph | Looking at the "improve realtime performance #2" patch: https://gerrit.asterisk.org/2906 ... |
| 16:03.21 | gtjoseph | it's premise is that a contact won't belong to more that 1 endpoint |
| 16:03.56 | *** join/#asterisk-dev F2Knight (~F2Knight@c-50-139-85-237.hsd1.or.comcast.net) |
| 16:03.57 | gtjoseph | although the data model allows more than 1 aor per endpoint, is there any real-life scenario that needs this? |
| 16:04.40 | file | so - I said I don't think such a substantial change should go into 13 and it should be discussed elsewhere to see |
| 16:05.10 | gtjoseph | and i agree. |
| 16:05.24 | file | I'M NOT CRAZY |
| 16:05.37 | cresl1n | Too soon to determine, IMHO |
| 16:05.38 | gtjoseph | i just wanted to know if anyone actually had a scenario they could think of. |
| 16:06.02 | file | putnopvut can think of some, but we don't have visibility into actual deployments |
| 16:07.38 | gtjoseph | ok, i'm going to -1 for now and post something to the mailing lists asking for feedback. |
| 16:09.27 | putnopvut | Yeah, a single contact corresponding to more than one AOR works in a situation where you have the contact registered to an individual AOR plus maybe an AOR that corresponds to a group of like contacts. The thing is, there are other ways you can accomplish the same thing |
| 16:11.29 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 16:11.43 | gtjoseph | wouldn't this result in 2 contact objects? |
| 16:11.51 | putnopvut | Yeah, it would |
| 16:12.26 | gtjoseph | hmmm. |
| 16:12.56 | gtjoseph | so in what situation could we have the same dynamic contact object belong to more than 1 endpoint? |
| 16:13.39 | file | couldn't you specify the same AOR on two endpoints, have a registration or permanent on it, and dial them through each endpoint? |
| 16:14.37 | cresl1n | maybe with different codecs? |
| 16:14.49 | cresl1n | e.g. tsearle? |
| 16:15.27 | putnopvut | file: yep, you could. That's why I said you can accomplish the same thing in multiple ways. |
| 16:15.47 | cresl1n | hopes he didn't misunderstand |
| 16:16.10 | file | cresl1n, you could! |
| 16:17.45 | gtjoseph | what would the identify process do with that though? |
| 16:18.23 | file | you'll have to be more specific... |
| 16:19.01 | gtjoseph | i'm thinking. |
| 16:48.22 | file | rain, rain, rain |
| 17:03.04 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 17:03.04 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 17:36.20 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 17:56.25 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 18:22.03 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 18:22.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:08.33 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 19:08.34 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:08.37 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00a1bbfea274372e90.ipv6.abo.wanadoo.fr) |
| 19:59.34 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 20:35.22 | rmudgett | gtjoseph: That pubsub review is giving me a headache. Have you ever seen sub_tree->last_notify > 1? |
| 20:36.13 | gtjoseph | don't worrk. i'm abandoning i t. |
| 20:36.33 | rmudgett | *worry? |
| 20:37.03 | gtjoseph | after looking at the dlg lock sequence in pjproject itself i'm convinced that the issue is in evsub.c |
| 20:37.41 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 20:37.41 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 20:37.50 | cresl1n | malcolmd! |
| 20:37.55 | gtjoseph | they're assuming that all of their callbacks are run synchronously and of course, we throw things on a serializer then return. |
| 20:37.56 | malcolmd | aloha |
| 20:39.21 | rmudgett | gtjoseph: The threading is confusing |
| 20:39.58 | gtjoseph | i know. |
| 20:40.10 | rmudgett | Two threads could stop the subscription. If we're backed up we could wind up with both on the serializer. |
| 20:40.44 | gtjoseph | yes but after re-looking twice, i think res_pjsip_pubsub is ok. |
| 20:42.32 | gtjoseph | the problem is that when evsub.c gets an event to process, it dispatches it to our on_evsub_state code, we return after pushing to the taskprocessor but evsub.c immediately checks if a transation is in progress and if not, destroys the sub |
| 20:43.03 | rmudgett | We could even get a delayed subscription refresh in the queue and a timeout right after because the refresh wasn't serviced in time. |
| 20:43.18 | gtjoseph | yep all true |
| 20:44.13 | gtjoseph | but... if the distributor did it's job, then all but the timeout should be processed on the same serializer |
| 20:44.43 | gtjoseph | but again... a notify might also go out because of a extension state change |
| 20:45.21 | rmudgett | Shouldn't that notify go out on the subscription's serializer? |
| 20:45.47 | gtjoseph | yep, it should |
| 20:46.05 | gtjoseph | and the dialog is locked by ast_sip_subscription_notify anyway |
| 20:46.42 | gtjoseph | the only thing that's not locked is the destroy by pjproject itself |
| 20:49.02 | gtjoseph | if you want to see where i'm thinking the issue is, look at pjsip/src/pjsip-simple/evsub.c at the very bottom mod_evsub_on_tsx_state |
| 20:53.09 | rmudgett | The state change notifies don't go out over the subscritption serializer. |
| 20:53.30 | gtjoseph | eh? |
| 20:53.31 | rmudgett | They only go out using the subscription serizliaer if they are batched |
| 20:53.44 | gtjoseph | oh, true. but the dialog is locked |
| 20:53.46 | rmudgett | Following calls to send_notify() |
| 20:54.28 | rmudgett | They should go out synchronized with the subscription life. |
| 20:54.49 | rmudgett | Considering that they are part of the dialog. |
| 20:55.51 | gtjoseph | true but since the dialog is locked and ast_sip_subscription_notify checks sub->tree->evsub after getting th elock, it should be effectively serilaized |
| 20:57.49 | rmudgett | Good thing then we don't care about the on_tsx_state callback because that would happen under a bunch of different threads |
| 20:58.16 | rmudgett | Subscription and notify transactions associated with the subscription |
| 20:59.29 | gtjoseph | how? wouldn't the distributor make sure any incoming requests go onn the same serializer |
| 20:59.57 | rmudgett | It does. But the notifies can go out on any serializer. |
| 21:00.07 | gtjoseph | yeah, true |
| 21:00.10 | rmudgett | *could |
| 21:00.36 | rmudgett | Any replies would come back in on the same serializer that sent the request |
| 21:01.13 | gtjoseph | the issue i think is that the dialog isn't locked when evsub.c/mod_evsub_on_tsx_state is run |
| 21:03.32 | rmudgett | Are pjsip's locks reentrant? |
| 21:03.42 | gtjoseph | oh yeah |
| 21:03.55 | gtjoseph | same thread is a no-op |
| 21:04.24 | gtjoseph | well, the counter goes up but it doesn't block |
| 21:05.22 | gtjoseph | i'm testing now with a dialog lock/unlock in mod_evsub_on_tsx_state and have run about 200k transactions without a segv, with no changes in asterisk at allo. |
| 21:05.30 | rmudgett | Ok That makes the locks reentrant |
| 21:05.53 | rmudgett | \o/ |
| 21:06.28 | gtjoseph | normally i get the segv about 45 seconds into the test. about 15 seconds after the contact taskprocessor reaches 1500 |
| 21:14.32 | gtjoseph | damn. damn damn. just got the segv. |
| 21:15.02 | gtjoseph | but i now think i know why |
| 21:15.20 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 21:15.20 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:32.28 | *** join/#asterisk-dev klow (~textual@96.81.150.137) |
| 22:02.01 | file | https://github.com/monsieurh/rfc_reader |
| 22:02.47 | cresl1n | welp |
| 22:02.55 | cresl1n | My RFC reader is a browser most of the time |
| 23:12.28 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-dxawoilnssqjfzqp) |
| 23:48.08 | *** join/#asterisk-dev klow (~textual@96.81.150.137) |