IRC log for #asterisk-dev on 20171018

01:53.51*** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n)
01:53.51*** mode/#asterisk-dev [+o cresl1n] by ChanServ
01:59.36*** join/#asterisk-dev elcontrastador (~textual@206.78.110.8)
02:45.03*** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-138.ph.ph.cox.net)
02:56.40*** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-138.ph.ph.cox.net)
03:08.33*** join/#asterisk-dev praveen_marothu (~praveen@183.83.199.226)
03:09.46*** part/#asterisk-dev praveen_marothu (~praveen@183.83.199.226)
03:25.55*** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-138.ph.ph.cox.net)
06:44.53*** join/#asterisk-dev tsearle (~tsearle@37.19.10.33)
06:44.53*** mode/#asterisk-dev [+o tsearle] by ChanServ
06:48.50*** join/#asterisk-dev pchero_work (~pchero@109.70.54.56)
06:54.09*** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr)
07:01.38*** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com)
07:01.38*** mode/#asterisk-dev [+o tzafrir] by ChanServ
07:12.42*** join/#asterisk-dev jkroon (~jkroon@154.73.35.201)
09:08.22*** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net)
11:50.20*** join/#asterisk-dev newtonr (newtonr@nat/digium/x-zfhhuxziyjefnjlq)
11:50.21*** mode/#asterisk-dev [+o newtonr] by ChanServ
12:39.40*** join/#asterisk-dev Bordr (~Bordr@c-24-9-55-138.hsd1.co.comcast.net)
13:44.02*** join/#asterisk-dev spditner (~simon@45.72.168.56)
13:50.47gtjosephseanbright: if you're looking for something to do... https://gerrit.asterisk.org/#/c/6807/
13:53.15filehe's not, he's busy
13:56.48gtjosephare you his personal assistant now?
13:57.37seanbrightno, he just pays attention when i speak :-)
13:57.42seanbrights/speak/type/
13:57.56gtjoseph:)
13:58.11seanbrightdata center migration
13:58.18seanbright3 servers down, 22 to go
13:58.28seanbrighterr, 18
13:58.29gtjosephew, better you than me
13:59.59filecloud all the things!
14:00.12seanbrightyes. that would be nice.
14:12.53stefan27Don't trust the cloud. Put glue in your ethernet ports and keep your secrets safe.
14:21.56*** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1)
14:21.56*** mode/#asterisk-dev [+o bford] by ChanServ
14:24.49*** join/#asterisk-dev kharwell (kharwell@nat/digium/x-refuohcwswytjbwe)
14:24.49*** mode/#asterisk-dev [+o kharwell] by ChanServ
14:32.27*** join/#asterisk-dev jkroon (~jkroon@165.16.204.165)
15:48.45*** join/#asterisk-dev NirS_ (~nirs@87.69.215.252)
15:51.29*** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n)
15:51.29*** mode/#asterisk-dev [+o cresl1n] by ChanServ
15:57.05NirS_Hello all
15:58.40coreyfarrellNirS: I have never seen that error with vasprintf.  are you not on linux?
15:59.03NirSI'm very much on Linux
15:59.06NirSit's a CentOS 7
15:59.21NirSif I compile not in dev-mode it will only generate a warning
15:59.51coreyfarrellthat's why I told you to enable dev-mode, to turn warnings into errors :)
15:59.51NirSeverything seems to work as it should, but it is a funky error, considering that I didn't even do anything in that file
16:00.11fileI vaguely recall seeing it if included header files aren't quite ordered right, but I haven't seen it in years and do not recall
16:00.58coreyfarrellahh.. NirS please try reordering your includes so "asterisk.h" is first.
16:01.32NirShmmm.... interesting
16:01.35NirSlet's try that
16:02.53NirSBRB, going to get myself a shot of some good stuff to drink, looking at a long night of doc writing and code writing
16:04.01coreyfarrellNirS: asterisk.h includes asterisk/autoconfig.h which has '#define _GNU_SOURCE 1'.  vasprintf is only declared if _GNU_SOURCE is defined before stdio.h is included.
16:06.19NirSyupp, got it
16:06.29NirSchanged the include order and that resolved it
16:06.51NirSI've had my head too much into Python and JAVA lately, these things rarely happen there
16:07.03coreyfarrellNirS: please fix the support level before you update the review.
16:07.39NirSok
16:07.51NirSbtw, any of you ever noticed the following in the compile time:
16:07.59NirS<PROTECTED>
16:08.00NirSinvert.c: In function ‘invert_’:
16:08.01NirSinvert.c:167:24: warning: array subscript is above array bounds [-Warray-bounds]
16:08.01NirS<PROTECTED>
16:08.01NirS<PROTECTED>
16:08.01NirS<PROTECTED>
16:08.04NirSirc2pc.c: In function ‘irc2pc_’:
16:08.06NirSirc2pc.c:145:12: warning: ‘temp[8]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
16:08.09NirS<PROTECTED>
16:08.12NirS<PROTECTED>
16:09.13fileyes, that's a codec implementation - I forget which one, might be lpc10
16:09.45fileit can be ignored
16:11.10NirSok, hopefully, last patch set is not uploading to review board :-)
16:13.03NirSif this done, maybe I'll have enough time to work on cel_beanstalkd.c as well :-)
16:14.45coreyfarrellNirS: have you tested this?  I mean verified that beanstalkd receives usable information from Asterisk with the module?
16:17.41NirSyes
16:17.44NirSit's working nicely
16:18.16NirSI tested inside a VM, and even has sipp run calls to the Asterisk and then a dialplan to answer randomly and disconnect randomly
16:18.55NirSmanaged to get to around 30 concurrent insertions per second, but then my VM died on me :-)
16:19.24coreyfarrellthe whole VM or asterisk?
16:20.06NirSthe whole VM - I racked up to a load average of 8 on a single core machine - SIPP was killing it
16:20.30NirSdied = became unresponsive due to lack of resources
16:20.38NirSAsterisk never died, the machine simply became laggy
16:24.30NirSneeds to lay off the booze, working 18 hours work days is getting to him
16:29.05NirScool
16:29.33NirSso I assume this means that #6819 passed the review correctly ?
16:29.54fileit means that coreyfarrell reviewed it and in his opinion it is okay to go in
16:30.33NirShmmm.... ok.... makes sense
16:30.42coreyfarrellNirS: it'll still need a second set of eye's to give the +1 like I did, then someone will have to +2 it.
16:30.57NirSok, that's reasonable
16:31.10NirSI guess in the mean time I can start working on something else
16:31.35NirSI'm trying to figure out where should I concentrate my effort
16:31.48NirSso, I'd appreciate your intake on this one
16:32.02NirSso, beanstalkd is something I've been using for a few years now
16:32.21NirSit serves really well when you need to scale and shard jobs around a large installation
16:33.04NirSfor example, I can have Asterisk routing servers push CDR records with a priority of 50, while Voicemail servers push CDR records with a priority of 99, indicating lesser importance for billing purposes
16:33.24NirSOne of the things that requires fast processing is normally queue_log
16:33.34NirStill now, everybody is doing it the same
16:33.53NirSconnect to the queue_log and constantly read it
16:34.20NirSmy personal feeling is that this can be done better using a job queue or a message queue
16:34.48NirSwhere a log entry to the queue_log can be regarded as a "Job for processing", and then be moved off-server to somewhere else
16:35.01NirSwhat do you think ?
16:38.48coreyfarrellunlike CDR and CEL, the queue_log doesn't support backends.
16:39.38NirSi know
16:39.43NirSthat's exactly my point
16:40.47NirSmaybe we need something like that in there
16:43.40seanbrightres_pipe... one day
16:44.51NirSnow that's stretching it a bit, now ?
16:45.04seanbrightno?
16:45.10seanbrightit's going to be FUCKING AWESOME
16:45.17seanbrightwhen i can actually get around to it
16:46.28NirSindeed, that would be awesome
16:46.51NirSa resource that can pipe any of Asterisk "external outputs" to a pipe, that would be great
16:47.02seanbrightand realtime too
16:47.07seanbrightand and and
16:47.15NirScoming to thing about it, a func_beanstalk can be useful
16:47.34NirSso you can push and pull jobs directly from the dialplan and later on, ARI
16:47.48seanbrightwell, my long term thought is that we would remove all of the cdr, cel, and realtime backends in favor of res_pipe and external processes
16:47.53NirSdoing it via an http request is fuck'n slow
16:48.13NirSwoof !
16:48.16seanbrightwell, not 'remove' actually... move
16:48.28seanbrightto their own repo which is maintained independently
16:48.34seanbrighti like to dream
16:58.43NirSnope, too many jokes and puns come to mind right now, must resist
17:17.30*** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n)
17:18.12*** join/#asterisk-dev danjenkins (danjenkins@gateway/shell/firrre/x-pustsykjurcabygt)
17:18.12*** mode/#asterisk-dev [+o danjenkins] by ChanServ
17:27.07seanbrightare there? none come to my mind
17:33.39coreyfarrellgtjoseph / file: I've been looking through bugs, came across https://issues.asterisk.org/jira/browse/ASTERISK-26664.  Would it be useful to make the bundled pjproject compile without NDEBUG when --enable-dev-mode is on?
17:34.30gtjosephhmmm. could be
17:34.43filethere's some cases we'd need to un-assert to make it work reliably
17:35.13filesome PJSIP functions are a bit assert heavy for silly legit reasons
17:35.56gtjosephmight be time to get those squashed upstream
17:35.56*** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n)
17:35.56*** mode/#asterisk-dev [+o cresl1n] by ChanServ
17:35.59filewe can do that and figure out what based on failures
17:37.03coreyfarrellare you thinking that we'd be able to get pjproject to remove the excessive asserts or that we'll carry a patch for the bundled to remove the excessive ones?
17:37.04gtjosephI wonder if any would be valid for a client but not for a server
17:37.24gtjosephhopefully them
17:37.51gtjosephwell with us submitting a patch upstream
17:44.36coreyfarrellI created ASTERISK-27359 for that improvement.
18:01.22*** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n)
18:01.22*** mode/#asterisk-dev [+o cresl1n] by ChanServ
18:07.03*** join/#asterisk-dev elcontrastador (~textual@70-90-215-98-BusName-ca.sacra.hfc.comcastbusiness.net)
18:14.42coreyfarrellI'm working on making res_pjsip_pubsub non-unloadable, does anyone know if it's safe to call ast_sip_register_service(&pubsub_module) before calling the other pjsip functions - pjsip_evsub_init_module, pjsip_media_type_init2 and pjsip_endpt_add_capability?
18:15.21coreyfarrellmy goal is to reorder the module_load so that any possible load errors occur before calling the pjsip functions which can't be reversed.
18:22.59*** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0089593f34c0b516a8.ipv6.abo.wanadoo.fr)
18:30.54*** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n)
18:30.55*** mode/#asterisk-dev [+o cresl1n] by ChanServ
19:55.42*** join/#asterisk-dev tzafrir (~tzafrir@212.29.194.37)
19:55.42*** mode/#asterisk-dev [+o tzafrir] by ChanServ
20:02.28tm1000coreyfarrell: doesnt "BETTER_BACKTRACES" also have performance degradation issues?
20:04.30coreyfarrelltm1000: it has no effect unless a backtrace is actually logged (just checked asterisk 13 code).
20:14.25tm1000Qwell: you should just ask coreyfarrell  here directly
20:14.26tm1000lol
20:14.41tm1000https://www.irccloud.com/pastebin/V2dMmORZ/
20:15.00coreyfarrellcresl1n: do you know why BETTER_BACKTRACES is even an option?  maybe we should just use it if we have the required libraries?  is this a licensing issue or something?
20:15.15coreyfarrellyeah I was in the process of asking :)
20:15.19tm1000hahaah :-)
20:15.24Qwell^5
20:19.38coreyfarrelltm1000 / Qwell: looks like libbfd is GPL, so maybe it's a GPL violation to load proprietary modules on an asterisk built with BETTER_BACKTRACES.
21:16.13cresl1ncoreyfarrell: Not sure
21:16.20cresl1nother than maybe the GPL thing
21:16.37cresl1nI looked around where it's used
21:16.45cresl1nso anywhere Asterisk might dump a backtrace
21:16.49cresl1nlike assertion failure
21:16.55cresl1nin the astmm.c code
21:17.10cresl1nso my guess is maybe when MALLOC_DEBUG is enabled
21:17.21cresl1nit might make it worse in performance
21:17.56cresl1nBut I don't think it should be an ongoing performance burden
21:18.02coreyfarrellif MALLOC_DEBUG is enabled performance is already crap.
21:18.06cresl1nUnless you're dumping a lot of backtraces
21:18.10cresl1nyeah
21:20.00coreyfarrellif you're dumping a lot of backtraces then performance is likely the least of your concerns!
22:29.45*** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102)
22:29.45*** mode/#asterisk-dev [+o snuff-work] by ChanServ
23:23.55*** part/#asterisk-dev kharwell (kharwell@nat/digium/x-refuohcwswytjbwe)
23:35.30*** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-138.ph.ph.cox.net)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.