| 02:29.14 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:828e:6c48:6d00:ad9b:3d13) |
| 02:29.14 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 07:44.50 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:44.50 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:48.54 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 07:54.57 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:1dd7:b42:3b85:c2f5) |
| 07:58.14 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:58.14 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:02.28 | *** join/#asterisk-dev hehol (~Adium@ip-109-90-164-163.hsi11.unitymediagroup.de) |
| 08:19.06 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:22.08 | *** join/#asterisk-dev hehol (~Adium@ip-109-90-164-163.hsi11.unitymediagroup.de) |
| 09:09.41 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 13:57.22 | coreyfarrell | file: do you have any opinion on cherry-picking https://gerrit.asterisk.org/7182 (constructor attribute mandatory) to 13/15? |
| 13:57.44 | file | I think it'd be fine? |
| 14:05.14 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-rigdukcimbayewlc) |
| 14:05.14 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 14:33.10 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-suranhivdmpbqmsz) |
| 14:33.10 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 15:14.34 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-gskcbmyqttttpjcn) |
| 15:14.34 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:23.58 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:23.58 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:25.21 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 15:25.21 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:31.00 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-hqzuivueciishfxc) |
| 15:31.00 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:47.52 | cresl1n | Anybody taken a look at tsearle's python converter script yet? |
| 15:48.53 | file | negative |
| 15:49.03 | cresl1n | starts poking at it |
| 15:50.23 | tsearle | I think it's explained in the command line help, but it takes 2 inputs, the sip.conf (for the globals) and the mysql db config |
| 15:50.48 | tsearle | then it outputs a .sql file that you can run on your prod |
| 15:51.00 | cresl1n | cool |
| 15:51.21 | tsearle | so you can use the script for realtime sip to pjsip migration |
| 15:51.47 | tsearle | it sources the mapings from the original script |
| 15:52.03 | tsearle | so no extra maintenance required |
| 16:36.35 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.163) |
| 17:24.34 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-hldreftgqbwmkmsq) |
| 17:24.35 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 17:29.38 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00b17961f9326a0ecf.ipv6.abo.wanadoo.fr) |
| 17:34.17 | rmudgett | coreyfarrell: Replied to your comment. |
| 17:55.24 | coreyfarrell | if anyone has time can I get eyes on https://gerrit.asterisk.org/7165 and cherry-picks (the vector.h additions)? it's required by two series of patches, I haven't posted the 2nd series yet to avoid rebase of one forcing rebase of the other. |
| 18:09.02 | *** join/#asterisk-dev joshelson (~joshelson@2601:282:782:4b79:5c5d:40d8:ef04:f91d) |
| 18:35.31 | coreyfarrell | rmudgett: "\note The stolen vector must eventually be released using ast_free."? I'm only unsure "vector" is the word we want since it's not the AST_VECTOR. |
| 18:36.23 | rmudgett | You could use array instead since that is what is stolen. |
| 18:38.14 | coreyfarrell | that works thanks |
| 19:18.15 | *** join/#asterisk-dev joshelson (~joshelson@2601:282:782:4b79:798d:a914:2d8:8e57) |
| 20:01.56 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 20:10.02 | *** join/#asterisk-dev joshelson (~joshelson@2601:282:782:4b79:8993:8df0:5716:5ab8) |
| 20:29.30 | *** join/#asterisk-dev philipp64 (~chatzilla@66-232-81-197.ctcweb.net) |
| 20:56.46 | *** join/#asterisk-dev joshelson (~joshelson@2601:282:782:4b79:e865:cc0:529f:4c05) |
| 21:03.45 | seanbright | bford: i'm not 100% sure how the CI is configured, but it looks like you need 2.7.1 on the build slaves themselves |
| 21:04.05 | seanbright | /srv/cache/externals/pjproject-2.7.1.tar.bz2 |
| 21:05.36 | bford | seanbright: yeah i'm looking into it now, i think the issue was i didn't have my changes in the third-party repo yet, so it didn't know where to get pjproject from |
| 21:05.43 | seanbright | gotcha |
| 21:06.04 | bford | gonna let it run again and hopefully that's the case :) |
| 21:06.23 | gtjoseph | jenkins will download it automatically if it's in the github repo. which it is now. |
| 21:28.44 | gtjoseph | seanbright: insanity is defined as doing the same thing over and over with no changes but expecting a different result. :) WRT https://gerrit.asterisk.org/#/c/7163/ |
| 21:31.19 | seanbright | agreed |
| 21:31.24 | seanbright | it will eventually pass |
| 21:32.34 | file | those do use sorcery underneath... |
| 21:32.34 | file | fyi |
| 21:32.49 | seanbright | ok |
| 21:33.04 | file | bucket is a layer on top of sorcery, and the media cache is a user of buckets |
| 21:33.18 | gtjoseph | i was going to wait and see how many times he did a recheck before the light dawned. :) |
| 21:33.22 | seanbright | ah... fixed it! |
| 21:33.47 | seanbright | someone should add something like that to asterisk |
| 21:33.51 | seanbright | err, sorcery |
| 21:34.26 | seanbright | it makes contact lookups faster (assuming you aren't using res_sorcery_astdb) |
| 21:34.44 | coreyfarrell | it's weird that it was only failing on 15. |
| 21:36.58 | seanbright | with that patch + a patch to res/res_pjsip/location.c to switch to using it, i went from ~300 registrations per second to around 850 |
| 21:37.20 | seanbright | assuming you use res_sorcery_memory for the contacts db |
| 21:37.41 | seanbright | so it's worthwhile for someone smarter than me to take a crack at it |
| 21:37.56 | file | astdb or realtime would be the more common use case for that >_> |
| 21:38.14 | coreyfarrell | seanbright: you missed the .is_stale callback on 15 (__ast_sorcery_wizard_register is used directly by bucket.c) |
| 21:38.15 | seanbright | right, there is no improvement with astdb |
| 21:38.33 | seanbright | astdb is probably the biggest bottleneck in asterisk |
| 21:38.42 | seanbright | based on my testing, at least |
| 21:38.53 | file | good to know |
| 21:38.54 | seanbright | switching to sqlite3 was a mistake |
| 21:39.01 | seanbright | but it is what it is |
| 21:39.16 | seanbright | coreyfarrell: k |
| 21:40.17 | seanbright | the best thing to do is to just add a res_pjsip_sorcery module that uses sqlite directly |
| 21:40.27 | seanbright | with reasonable tables and indexes |
| 21:40.36 | seanbright | you might be able to get decent performance that way |
| 21:41.25 | seanbright | but the lock-the-world approach in astdb won't really scale |
| 21:43.11 | seanbright | you _can_ open multiple handles to the same sqlite3 database file, so some kind of pooling or maybe TLS would have an appreciable impact |
| 21:43.41 | gtjoseph | sqlite sorcery module is on my list and has been for a long time |
| 21:44.16 | seanbright | do yourself a favor and don't name the database file ending with '.sqlite3' |
| 21:44.20 | seanbright | just do .dat |
| 21:44.41 | gtjoseph | as is using sqlite as the backend for the config file provider instead of an ao2 container. |
| 21:44.53 | seanbright | then it becomes an implementation detail and people won't feel compelled to derive some kind of reporting out of it |
| 21:45.08 | gtjoseph | that way you could have full sql query capability for sorcery objects |
| 21:45.16 | gtjoseph | heh |
| 21:46.02 | seanbright | res_sorcery_bdb would be a nice addition too |
| 21:46.18 | seanbright | and res_sorcery_{redis,memcached} would probably be the best |
| 21:46.29 | gtjoseph | how about .vsam ? |
| 21:47.34 | seanbright | as long as it's clear that it is an internal data file, i don't really think that it matters |
| 21:47.45 | seanbright | .jpe |
| 21:47.46 | seanbright | err |
| 21:47.48 | seanbright | .jpg |
| 21:48.33 | seanbright | in pjsip (not in asterisk), can an endpoint be associated with multiple UDP transports? |
| 21:48.39 | *** join/#asterisk-dev sotoz (~sotoz@p5B258229.dip0.t-ipconnect.de) |
| 21:48.40 | gtjoseph | how about .dontfuckwithmeyouasshole |
| 21:48.44 | seanbright | perfect |
| 21:49.04 | file | define endpoint |
| 21:49.09 | seanbright | endpt |
| 21:49.17 | seanbright | pjsip_endpt_t |
| 21:49.20 | file | you can have multiple UDP transports on it |
| 21:49.20 | seanbright | or whatever it is |
| 21:49.36 | seanbright | cool |
| 21:50.10 | seanbright | alright, let me try to fix this |
| 21:50.20 | seanbright | i look forward to this never getting merged |
| 21:51.25 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:828e:3c88:b24d:e1b9:1973) |
| 21:51.25 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 21:51.30 | file | I look forward to bacon |
| 21:51.31 | file | as should you |
| 21:53.23 | *** join/#asterisk-dev sotoz_ (~sotoz@m90-142-108-211.cust.tele2.nl) |
| 21:53.33 | seanbright | nah |
| 21:54.47 | file | cookies? |
| 21:56.08 | seanbright | blah blah blah blah? |
| 21:57.23 | cresl1n | Yes? |
| 22:07.29 | *** join/#asterisk-dev tzafrir (~tzafrir@62-90-199-170.barak.net.il) |
| 22:07.29 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:34.02 | *** join/#asterisk-dev joshelson (~joshelson@2601:282:782:4b79:bd05:8c51:a69a:5caf) |
| 23:01.39 | coreyfarrell | kharwell: the changes to asterisk.c I posted match how ast_alertpipe_write actually works. the code doesn't return what the header says it should. |
| 23:03.18 | kharwell | oh! I had to go back and look at the alertpipe_write code again. Indeed you are quite correct. I totally missed the "!= sizeof(tmp);" on the end |
| 23:03.57 | kharwell | Now I see what you mean that the docs are incorrect. hrm good question as to which should change |
| 23:05.09 | kharwell | I lean toward the docs as it seems like that is how it has always worked, but could there be a case where someone wants the result of number of bytes written? Like if you have it in a loop and it wrote 7/10 bytes you might want to try and write those last 3 again? |
| 23:06.48 | coreyfarrell | actually I think the docs should be changed. the number of bytes are determined by 'uint64_t tmp = 1;' inside the function, so it's an implementation detail. |
| 23:07.59 | kharwell | ah yeah +1 |
| 23:11.22 | kharwell | looks like all the pipe writes in asterisk.c were writing to size int? Would this matter in those cases changing it to uint64_t? |
| 23:17.12 | coreyfarrell | the read got switched too so it's fine. |
| 23:18.28 | coreyfarrell | we're not actually dealing with the data, it's just a wake-up signal. |
| 23:42.32 | *** join/#asterisk-dev joshelson (~joshelson@2601:282:782:4b79:6849:7d56:916d:f5cd) |
| 23:43.52 | *** join/#asterisk-dev dan_j (sid21651@gateway/web/irccloud.com/x-axzurmuxibdfpzom) |
| 23:47.28 | *** join/#asterisk-dev joshelson (~joshelson@2601:282:782:4b79:6849:7d56:916d:f5cd) |