| 00:42.56 | *** join/#asterisk-dev suneye (~atcmmi@119.123.221.36) |
| 01:05.36 | *** join/#asterisk-dev atcmmi (~atcmmi@119.122.155.145) |
| 01:05.54 | *** join/#asterisk-dev oej (~Adium@67.217.137.66) |
| 01:06.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 01:42.17 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 06:56.24 | *** join/#asterisk-dev atcmmi (~atcmmi@119.122.155.145) |
| 07:55.08 | *** join/#asterisk-dev danjenkins (~danjenkin@80.1.94.250) |
| 08:03.28 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 08:03.28 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 08:34.47 | *** join/#asterisk-dev danjenkins (~danjenkin@80.1.94.250) |
| 08:43.26 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 10:30.35 | *** join/#asterisk-dev oej (~Adium@67.217.137.66) |
| 10:30.35 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:46.32 | *** join/#asterisk-dev oej (~Adium@67.217.137.66) |
| 11:46.33 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:55.52 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 11:58.36 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ilhwjiuvqcwjqjhr) |
| 11:58.36 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:13.31 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 12:13.32 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 12:40.55 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ilhwjiuvqcwjqjhr) |
| 12:42.37 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-ornbwyvoeoosrblr) |
| 12:42.37 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 12:56.39 | pgrace | Is anyone here particularly familiar with features.c? I'm wondering if there was a "Good Reason" why variable substitution doesn't work when you trigger a feature before considering whether I want to spend time trying to create a patch to make it work. |
| 13:42.22 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-nggznpxedvxdhbvo) |
| 13:42.22 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:14.39 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:14.39 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:27.07 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-xgqvhhcokrmphfie) |
| 14:27.45 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-111-87.user.veloxzone.com.br) |
| 16:00.00 | *** join/#asterisk-dev oej (~Adium@edc-67-134-110-176.njit-edc.net) |
| 16:00.00 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:05.12 | *** join/#asterisk-dev datachomper (~datachomp@nat/digium/x-jmdrezozhlauttan) |
| 17:03.19 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 18:20.47 | *** join/#asterisk-dev oej (~Adium@edc-67-134-110-176.njit-edc.net) |
| 18:20.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:25.55 | *** join/#asterisk-dev oej (~Adium@edc-67-134-110-176.njit-edc.net) |
| 18:26.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:40.37 | mjordan | file: PING |
| 18:40.43 | file | PONG |
| 18:40.47 | mjordan | ICMP shouts. |
| 18:41.12 | mjordan | Anywho. Are the reduction in channel stasis message patches ready for review? |
| 18:41.34 | file | I would say so |
| 18:41.51 | mjordan | nifty. |
| 18:41.55 | mjordan | How was the schnitzel? |
| 18:42.07 | file | I was planning on throwing them up for review tomorrow |
| 18:42.11 | file | and good |
| 18:44.43 | mjordan | cool - tomorrow works. |
| 18:44.51 | mjordan | senses a Sunday commit |
| 18:45.04 | file | Sunday commit will be hard for me due to travel :P |
| 18:46.54 | mjordan | You should commit at 30000 ft. |
| 18:46.58 | mjordan | I'm not sure that's been done yet. |
| 18:47.02 | mjordan | (on Asterisk, anyway) |
| 18:47.05 | file | it has. |
| 18:47.11 | file | did it |
| 18:47.22 | mjordan | I missed that commit message |
| 18:47.31 | file | WAIT A SECOND! if I commit a change does that mean I can expense the gogo fee?!? |
| 18:47.41 | mjordan | you can expense it anyway |
| 18:47.57 | file | I'm lazy when it comes to expensing stuff |
| 18:53.06 | mjordan | leedm777: I can't recall, and I'm seeing different patterns between CEL/CDRs. When disposing of subscriptions/message routers/topics, is the order subscriptions, then router, then topic? Or is it router, topic, subscriptions? |
| 18:58.07 | jgowdy | So far I've only done bug fixes, not new code, so forgive my noob question, but can anyone tell me why dialplan Set(Channel(MY_VAR="blah")) doesn't get picked up by pbx_builtin_getvar_helper(chan,"MY_VAR") from my res_blah.c module? |
| 18:59.00 | leedm777 | mjordan: dispose of messages last. router/topic order doesn't matter. |
| 19:01.20 | leedm777 | mjordan: BTW, mind including my AMI patch (r399886 on the performance branch) with your CDR/CEL patch? Seems like logically they should go together. |
| 19:02.24 | mjordan | sure |
| 19:03.19 | mjordan | leedm777: when you say messages, do you mean message types? Or subscriptions? |
| 19:03.30 | leedm777 | sorry, yeah, message types |
| 19:03.44 | mjordan | what about subscriptions? |
| 19:04.19 | leedm777 | order doesn't/shouldn't matter. |
| 19:04.28 | mjordan | jgowdy: Set(CHANNEL(MY_VAR="blah")) is using the CHANNEL function |
| 19:04.31 | mjordan | kk |
| 19:05.08 | mjordan | Unless what you meant was Set(MY_VAR="blah") |
| 19:07.17 | jgowdy | Oh, I was just trying to set it with channel scope, thought that's what that was doing. My C is better than my dialplan ;) |
| 19:07.49 | mjordan | Set(MY_VAR="BLAH") only applies to the channel it is set on |
| 19:08.12 | mjordan | The various "_" or "__" propagate the variable to children channels |
| 19:08.54 | mjordan | Globals are explicitly declared and accessed using the GLOBAL function |
| 19:09.03 | jgowdy | thanks, that helps |
| 19:24.49 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 19:30.29 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 19:48.17 | anonymouz666 | I think it should have a way to disable some useless device state cache. |
| 19:51.34 | mjordan | huh? |
| 19:51.50 | mjordan | what's the context of that statement? |
| 20:02.29 | anonymouz666 | I've found some problems about caching a lot of device states under heavy load |
| 20:02.34 | anonymouz666 | using corosync |
| 20:03.18 | mjordan | what version? |
| 20:03.29 | anonymouz666 | 1.8 |
| 20:03.37 | mjordan | what version of 1.8? |
| 20:03.44 | anonymouz666 | 1.8.16-rc1 |
| 20:03.59 | mjordan | k. I'll need to go back and look at what version the event cache patches went in |
| 20:04.23 | mjordan | but there were changes that were done to that, as a number of temporary devices were being left in the cache |
| 20:04.29 | mjordan | (FYI: this was a security vulnerability) |
| 20:04.31 | anonymouz666 | the workaround for that version was to avoid caches like "DAHDI", "AsyncGoto", "Transfered" and "Local". |
| 20:05.00 | mjordan | well, not all of them, but yes |
| 20:05.18 | mjordan | channels that don't actually map to a physical device |
| 20:06.45 | mjordan | right. That went in 1.8.19.1. |
| 20:07.05 | mjordan | So if you aren't at least on that version, than you're using a feature with a known vulnerability that was exploited in situations with high system load. |
| 20:07.30 | mjordan | As for "useless device state cache", it isn't useless. A lot of things query the cache to get the state |
| 20:08.25 | mjordan | If you removed the entire cache, a number of systems wouldn't work (or would work "differently", where "differently" is undesirable behavior). The security fix that went in for 1.8.19.1 fixed the caching of things that didn't map to a physical device, so that things like Local channels (for example) don't ever end up in the cache in the first place. |
| 20:08.56 | anonymouz666 | that is great, I think I have very good reason to update. |
| 20:10.00 | anonymouz666 | thanks for the information, mjordan! |
| 20:10.06 | mjordan | np |
| 20:21.08 | *** join/#asterisk-dev oej (~Adium@edc-67-134-110-176.njit-edc.net) |
| 20:21.08 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:15.26 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:20.17 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.249) |
| 21:27.58 | *** join/#asterisk-dev w9sh (~Steven@adsl-69-208-131-6.dsl.ipltin.ameritech.net) |
| 21:37.42 | newtonr | wdoekes, pinged you on ASTERISK-22236, as it looks like elguero was talking to you there. |
| 21:37.56 | newtonr | no particular rush, it just popped up in my queue of things |
| 21:56.37 | mjordan | heh. Updated an old trunk checkout. 389 files updated. |
| 22:09.52 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-nggznpxedvxdhbvo) |
| 22:40.29 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 22:46.21 | putnopvut | Ugh. I think there may be an fd leak somewhere in Asterisk 12. Using team/group/performance, I did an sipp->Asterisk->sipp at 25 cps. Calls immediately hang up upon being answered. After 2500 calls, Asterisk is unable to allocate RTP ports for new calls. If I stop the calls and wait for the SIP dialogs to clear, and then start calls up again, the problem immediately presents itself. BTW, this is using chan_sip, not chan_pj |
| 22:46.21 | putnopvut | sip. |
| 23:31.21 | jsmith | putnopvut: If it makes you feel any better, the Asterisk 12 branch takes 100% of the CPU on my machine when I try to use it |
| 23:31.26 | jsmith | Ugh... missed him |
| 23:36.03 | pabelanger | jsmith, woah |
| 23:36.11 | jsmith | Yeah :-( |
| 23:36.50 | pabelanger | I added it to a review, but I think it would be beneficial to add some of the numbers to the wiki. Especially if we are adding the ability to toggle the performance hit |
| 23:37.04 | jsmith | On the bright side, I'm not too worried about it today, because it's my birthday and this was my birthday present to myself: http://www.flickr.com/photos/websmith/9957220526/in/pool-2336958@N21 |
| 23:37.45 | pabelanger | Nice |
| 23:38.00 | pabelanger | that from a plane? |
| 23:42.20 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:42.20 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:45.52 | jsmith | pabelanger: No, that's from a hike on a neighboring hill |
| 23:46.20 | *** join/#asterisk-dev w9sh (~Steven@adsl-69-208-131-6.dsl.ipltin.ameritech.net) |
| 23:48.43 | leifmadsen | jsmith: wow |
| 23:48.58 | leifmadsen | jsmith: doesn't even look real |
| 23:49.27 | jsmith | leifmadsen: That was a stitch of 10 photos :-) |
| 23:49.34 | leifmadsen | nice |
| 23:49.36 | leifmadsen | nice! |
| 23:49.47 | leifmadsen | stitching came out pretty good |
| 23:50.15 | leifmadsen | runs away |
| 23:54.18 | pabelanger | jsmith, impressive |
| 23:55.40 | jsmith | pabelanger: Thanks :-) |
| 23:55.40 | jsmith | is pretty happy with how the photos turned out |
| 23:58.44 | *** join/#asterisk-dev oej (~Adium@67.217.137.66) |
| 23:58.45 | *** mode/#asterisk-dev [+o oej] by ChanServ |