| 00:19.59 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@24-177-86-98.dhcp.nwtn.ct.charter.com) |
| 00:19.59 | *** mode/#asterisk-dev [+o coreyfarrell] by ChanServ |
| 02:33.24 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-138.ph.ph.cox.net) |
| 03:57.54 | *** join/#asterisk-dev elcontrastador (~textual@c-67-181-163-114.hsd1.ca.comcast.net) |
| 05:02.40 | *** join/#asterisk-dev elcontrastador (~textual@c-67-181-163-114.hsd1.ca.comcast.net) |
| 05:57.57 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 06:06.31 | *** join/#asterisk-dev Bordr (~Bordr@c-24-9-55-138.hsd1.co.comcast.net) |
| 06:38.49 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 06:46.42 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:46.42 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 06:51.43 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:13.57 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 07:19.47 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:19.48 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:12.17 | *** join/#asterisk-dev sotoz (~sotoz@095-097-255-066.static.chello.nl) |
| 11:18.31 | *** join/#asterisk-dev jkroon_ (~jkroon@165.16.204.36) |
| 11:32.08 | *** join/#asterisk-dev jkroon_ (~jkroon@154.73.35.201) |
| 12:04.46 | *** join/#asterisk-dev tsearle (~tsearle@217.111.230.156) |
| 12:04.46 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 12:29.41 | *** join/#asterisk-dev jkroon__ (~jkroon@165.16.204.36) |
| 12:33.42 | *** join/#asterisk-dev Bordr_ (~Bordr@c-24-9-55-138.hsd1.co.comcast.net) |
| 12:40.53 | *** join/#asterisk-dev jkroon__ (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 13:59.11 | *** join/#asterisk-dev newtonr (newtonr@nat/digium/x-ganebdjhcjmxwpmn) |
| 13:59.11 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:15.52 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 14:15.52 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:16.41 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-sjlgkjncdxyarvwn) |
| 14:16.42 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:22.45 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 14:22.45 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 14:27.08 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-fmtrwmumrjquowim) |
| 14:27.08 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:17.30 | *** join/#asterisk-dev jkroon_ (~jkroon@165.16.204.36) |
| 15:20.06 | *** join/#asterisk-dev elcontrastador (~textual@70-90-215-98-BusName-ca.sacra.hfc.comcastbusiness.net) |
| 16:09.56 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 16:38.06 | seanbright | o/ |
| 16:38.22 | seanbright | i know we're all busy, but if someone wants to pick up my dtls review and take it over the finish line, feel free |
| 16:38.32 | seanbright | i'm going to be slammed for a couple weeks and probably won't get to it |
| 16:40.37 | file | seanbright: Vegas! |
| 17:10.46 | coreyfarrell | does anyone have an opinion/objection to the addition of cdr_beanstalkd? I was doing coding guidelines and now technical review without really asking if anyone objects to the inclusion. I'm indifferent, never even heard of beanstalkd. |
| 17:11.31 | coreyfarrell | if added should it be 'extended' support level? |
| 17:11.47 | file | yes, it should be extended |
| 17:11.55 | file | and a license check needs to be done on what it links to |
| 17:22.32 | seanbright | hmmm |
| 17:23.10 | seanbright | this is such a thin veneer... why not just tail the cdr.csv file, transform, and put it into beanstalk? |
| 17:24.07 | file | a valid question |
| 17:38.04 | coreyfarrell | I'll ask.. |
| 17:44.36 | coreyfarrell | does REST-API let you listen for CDR events / let you make a CDR backend out of process without using cdr.csv or cdr_manager? |
| 17:45.27 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 17:48.26 | file | not currently, no |
| 17:56.52 | *** join/#asterisk-dev Tim_Toady (~fuzzy@snf-33276.vm.okeanos.grnet.gr) |
| 18:08.34 | seanbright | coreyfarrell: i had an idea that i just haven't gotten around to yet, but i spoke with file, bford, and kharwell a bit about it |
| 18:08.54 | seanbright | new module (res_pipe maybe) that was a CDR, CEL, and realtime backend |
| 18:09.04 | seanbright | it either talking to a domain socket or an IP socket |
| 18:09.12 | seanbright | talked* |
| 18:09.34 | seanbright | in the case of CDR and CEL it would just spit out a binary blob |
| 18:09.43 | seanbright | in the case of realtime it would have to be req/resp |
| 18:09.52 | seanbright | then all of your backends could be out of process |
| 18:12.39 | coreyfarrell | not using the ARI format? Wouldn't a binary protocol make it harder to use (IE from python or node.js)? |
| 18:12.55 | seanbright | python? no |
| 18:12.59 | seanbright | node? probably |
| 18:13.16 | seanbright | it would purely be a middleware for other backends |
| 18:14.23 | DivideBy0 | for what it's worth, an ARI generated call does not generate cdrs, so it might be a little more complicated under the hood for y'all |
| 18:14.38 | seanbright | DivideBy0: that doesn't sound right |
| 18:17.59 | *** join/#asterisk-dev NirS (~nirs@87.69.215.252) |
| 18:18.15 | NirS | hello everybody |
| 18:19.24 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.165) |
| 18:21.34 | coreyfarrell | hello NirS |
| 18:36.36 | NirS | Hey Corey |
| 18:36.52 | NirS | just working on the issues you put into the review |
| 18:39.16 | NirS | @coreyfarrel, mind explaining me something ? |
| 18:40.15 | coreyfarrell | sure |
| 18:41.43 | NirS | I'm not sure I understand the customfield_lock issue you're describing |
| 18:44.46 | coreyfarrell | you need to assume that when someone does a config reload, load_config will run at the same time as another thread runs beanstalk_put. you need to prevent the two threads from conflicting (one writing config while the other reads it). |
| 18:46.46 | coreyfarrell | this is especially important for bs_host / bs_tube as those are string values that will need to be reallocated during a config reload, so you need to use locking to ensure beanstalk_put doesn't read from a pointer after it is freed. |
| 18:48.19 | NirS | oh, that makes sense, didn't think about that one. |
| 18:48.36 | NirS | It is an edge case, but indeed, in a high performance environment, it is possible |
| 18:49.05 | NirS | I guess the customfields_lock example in the module should suffice, no? |
| 18:52.46 | coreyfarrell | I had suggested renaming it to 'config_lock' so it self-documents. |
| 18:52.54 | coreyfarrell | to others: am I correct to assume that ast_rwlock_rdlock + ast_rwlock_unlock is more efficient than grabbing an object from an AO2 global and releasing it? |
| 18:54.18 | rmudgett | coreyfarrell: You mean doing an ao2_global_obj_ref () |
| 18:54.20 | rmudgett | ? |
| 18:54.32 | coreyfarrell | rmudgett: yes.. |
| 18:57.07 | rmudgett | ao2_global_obj_ref() uses a rwlock to protect access to the global object pointer. That way you are guaranteed to get a valid ao2 object with a ref. |
| 18:58.38 | rmudgett | Simply having a plain global ao2 object is not safe. Because another thread could update the object pointer at the same time you are trying to use it.. |
| 19:00.24 | coreyfarrell | rmudgett: the module in question was derived from cdr_manager so it's not using ACO, just using global variables. |
| 19:04.19 | rmudgett | AO2_GLOBAL_OBJ_STATIC can be used outside of ACO. |
| 19:05.44 | rmudgett | but cdr_manager.c predates a lot of stuff. |
| 19:05.49 | coreyfarrell | rmudgett: https://gerrit.asterisk.org/#/c/6819/1/cdr/cdr_beanstalkd.c@297 - I had suggested expanding use of the rwlock to protect all config values. I'm second-guessing my suggesting wondering if the config should just be stored in an AO2_GLOBAL_OBJ_STATIC instead. |
| 19:06.48 | NirS | @rmudgett that is an understatement |
| 19:12.31 | rmudgett | customfields_lock does protect the config option usages in cdr_manager.c. It needs to do the same in the new module. And as Corey suggested, renaming to the better name. |
| 19:15.41 | NirS | so I don't need to add an additional lock in there ? |
| 19:15.50 | NirS | just use the existing one ? |
| 19:16.51 | *** join/#asterisk-dev tzafrir (~tzafrir@212.29.194.37) |
| 19:16.51 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:20.11 | coreyfarrell | NirS: just a single lock to protect the whole config. |
| 19:20.26 | NirS | ok, no problem - just verifying |
| 19:23.46 | NirS | minor question regarding the "updating a review" - if I understand correctly, I should run 'git review -d [my_change_id]' then amend the commit then re-submit again master ? |
| 19:25.52 | file | yes |
| 19:28.54 | NirS | ok, on its way :-) |
| 19:29.25 | NirS | I love my fiber link at home |
| 19:29.35 | NirS | downloading the Gerrit is a snap |
| 19:30.10 | coreyfarrell | in the testsuite can I access the test-config.yaml values from an Asterisk object? I want to add a configurable setting for delayed shutdown of Asterisk that would be used only when running the test under valgrind or with REF_DEBUG enabled. |
| 19:31.00 | coreyfarrell | many tests do not need to delay shutdown of asterisk at all but some need to wait for timer-t1 to pass and release resources. some may need 90 seconds for min_se to pass (I haven't confirmed this yet). |
| 19:32.04 | NirS | ok, updated review is on the board |
| 20:13.26 | NirS | @coreyfarrell - I'm really getting my money's worth from this lesson :-) |
| 20:15.21 | coreyfarrell | NirS: first submission is always the most difficult. especially if it's a new feature, lots of things to be worried about. |
| 20:46.06 | NirS | well, considering my last massive submission was over 6 years ago, much has changed since then |
| 21:14.39 | DivideBy0 | seanbright: sorry, I fell offline |
| 21:17.54 | seanbright | DivideBy0: i forgive you |
| 21:25.14 | NirS | is going to bed, it's well past midnight over here - and C is slowly starting to look like BASH :-( |
| 23:23.34 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-sjlgkjncdxyarvwn) |
| 23:32.00 | *** join/#asterisk-dev tuxd00d (~tuxd00d@172.56.40.210) |