| 00:55.55 | *** join/#asterisk-dev mjordan (~mjordan@user-24-214-136-35.knology.net) |
| 00:55.56 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:10.16 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 01:10.16 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 01:15.19 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-eycknmlnipfwigtq) |
| 01:15.19 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:00.08 | *** join/#asterisk-dev droemel (~droemel@p4FCACFAE.dip.t-dialin.net) |
| 02:16.41 | *** join/#asterisk-dev ChrisInSydney (~Administr@202-129-83-200.perm.iinet.net.au) |
| 04:13.05 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 04:13.06 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 04:43.38 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 05:53.39 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 05:53.54 | Kobaz | looks like asterisk deadlocks pretty nicely when astdb is corrupted |
| 06:43.50 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000::42:1003) |
| 06:43.50 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:16.21 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 07:50.48 | *** join/#asterisk-dev luckman212 (~luckman21@2001:470:8abb:0:211:32ff:fe10:cdc1) |
| 08:40.12 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000::42:1005) |
| 08:40.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:30.05 | *** join/#asterisk-dev frawd (~francois@221.red-80-28-139.adsl.static.ccgg.telefonica.net) |
| 12:16.25 | *** join/#asterisk-dev mjordan (~mjordan@user-24-214-136-35.knology.net) |
| 12:16.25 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:24.36 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 13:50.30 | russellb | file: just read that directrtpsetup test ... awesome that you can do it without writing any code |
| 13:52.05 | file | russellb, yup |
| 13:52.54 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000::42:1003) |
| 13:52.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:00.14 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-uptsgwpideslwbax) |
| 14:00.52 | leifmadsen | o.O |
| 14:04.15 | *** join/#asterisk-dev serafie (~erin@76.73.167.231) |
| 14:16.24 | russellb | leifmadsen: WHAT |
| 14:25.39 | leifmadsen | russellb: tests! |
| 14:28.13 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:28.13 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:37.39 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:37.40 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:40.19 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:40.19 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:46.29 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:46.29 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:50.58 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-spdhnzgaqhrkvxwe) |
| 14:50.58 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:11.54 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-arirxsxeywsjedsc) |
| 15:12.39 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 15:12.39 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 15:19.53 | *** join/#asterisk-dev micols (~t@rlogin.dk) |
| 15:44.11 | jsmith | putnopvut: So far so good on that patch for issue 20226 -- eight hours and 6500 calls without any reported issues |
| 15:46.11 | *** join/#asterisk-dev rbd_ (~rbd@cpe-173-095-178-212.nc.res.rr.com) |
| 15:46.37 | putnopvut | jsmith: would there have likely been issues in that amount of time? |
| 15:47.35 | jsmith | putnopvut: Probably not -- we typically see a crash from that issue approximately every six to eight days |
| 15:48.02 | mjordan | crosses his fingers |
| 15:48.09 | putnopvut | Okay. Well, let's see what happens. And if you do get crashes, be sure to post backtraces so we can see if they're still happening in the same place or if they're elsewhere. |
| 15:48.09 | jsmith | putnopvut: But I'll keep you and mjordan in the loop |
| 15:48.18 | jsmith | putnopvut: Of course... |
| 15:48.22 | file | token ring! |
| 15:49.35 | rbd_ | hey guys, anyone know of a mongoDB callflow function module for asterisk (simiar to the mysql one you have at http://www.voip-info.org/wiki/view/Asterisk+cmd+MYSQL) ? if not...anyone know of something close, that we could write to be for mongo? |
| 15:49.57 | leedm777 | file: 10BASE2! |
| 15:50.35 | jsmith | file: LANtastic! |
| 15:51.12 | Qwell | rbd_: Can you do it through ODBC? I know nothing of mongo |
| 15:51.30 | Qwell | func_odbc is your friend |
| 15:51.32 | mjordan | rbd_: not familiar with one, no. In general, we don't emphasize direct connections to databases, since that results in a lot of technology specific modules that increase the maintenance burden on Asterisk devs |
| 15:51.38 | mjordan | and what Qwell said :-) |
| 15:53.41 | Qwell | If not, you could get a bit cheeky and write something in your language of choice, and use func_curl to access stuff. |
| 15:53.54 | file | Qwell, :D |
| 15:54.08 | Qwell | file: I'm channeling jmls. |
| 15:54.25 | Qwell | (It was him that uses func_curl, right?) |
| 15:54.32 | file | I think so |
| 15:55.08 | leedm777 | There are REST Interfaces for MongoDB, so that might not be entirely insane. |
| 15:55.22 | Qwell | well there you go then |
| 15:58.46 | jsmith | res_config_curl to the rescue |
| 16:02.31 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:02.31 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:03.06 | russellb | there is a cdr_mongodb on github |
| 16:03.24 | russellb | and i know of someone who has written a res_config_mongodb, but hasn't released it |
| 16:05.01 | russellb | they aren't license compatible with Asterisk, though |
| 16:05.17 | russellb | apache license not compatible with gpl v2 |
| 16:17.56 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:41.58 | russellb | mjordan: oh dear @ "Reorder Asterisk startup sequence to prevent mutex errors caused by daemon fork" |
| 16:45.09 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:45.19 | russellb | on a barely related note ... it would be cool to make all of the DEBUG_THREADS stuff a standalone library that could be LD_PRELOADed |
| 16:45.37 | Qwell | I totally gave you that idea. |
| 16:45.44 | russellb | did you? neat |
| 16:45.50 | Qwell | like 2 years ago :p |
| 16:46.08 | Qwell | it'd be...fun? |
| 16:46.11 | russellb | k, well let the record show that it was Qwell's idea |
| 16:46.29 | mjordan | russellb: you have no idea how big of a pain in the ass this issue has been :-P |
| 16:46.50 | russellb | mjordan: well it does occur to me that various references you've made in here lately are all related to that |
| 16:46.55 | russellb | so yeah, i bet |
| 16:47.12 | russellb | fork + threads, kinda evil |
| 16:47.17 | mjordan | yup. |
| 16:47.57 | russellb | so i think your fix makes sense (moving fork up as much as possible, before thread sillyness kicks in) |
| 16:48.08 | mjordan | still scares the willies out of me |
| 16:48.14 | mjordan | there's a lot of implied dependencies in the startup |
| 16:48.31 | russellb | yes, so moving stuff around is a little scary |
| 16:48.32 | mjordan | I banged on the patch pretty good, using different startup options and I think I got the behavior covered |
| 16:48.34 | russellb | but ... gotta do it |
| 16:49.06 | russellb | so, there are other fork() uses in asterisk ... but I suppose they're all ok, because they all exec() immediately after |
| 16:49.25 | russellb | so doesn't matter what state other threads are in, because they're all about to die |
| 16:49.29 | mjordan | russellb: yup. |
| 16:49.35 | russellb | is just analyzing this out loud |
| 16:49.49 | russellb | so anyway, +1 to the patch |
| 16:50.07 | russellb | nice work sir |
| 16:50.24 | mjordan | russellb: gracias (I hope it doesn't cause regressions) |
| 16:50.43 | russellb | might be something to throw into trunk for a while |
| 16:50.44 | russellb | let it simmer |
| 16:50.56 | russellb | let testsuite bang on it for a while ... |
| 16:51.07 | russellb | and backport later |
| 16:51.43 | russellb | shrugs |
| 16:52.09 | mjordan | yeah |
| 16:52.11 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:52.53 | mjordan | patch was written for trunk initially anyway. I've let the testsuite bang on it on the 32-bit system for nearly 20 runs now with no recurrances, but I think what's more likely to cause people problems are 'interesting' ways of starting asterisk up |
| 16:53.12 | mjordan | tested console option, no console, remote, remote execution, and a variety of other combinations |
| 16:53.18 | mjordan | but I'm sure I'm missing something |
| 17:22.43 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-ygaosnwfmkayrixs) |
| 17:24.31 | *** join/#asterisk-dev oej_ (~olle@2001:16d8:cc57:1000::42:1005) |
| 17:24.31 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 17:37.07 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000::42:1005) |
| 17:37.07 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:10.21 | *** join/#asterisk-dev italorossi (~textual@189.124.196.68) |
| 18:44.32 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 18:44.32 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:57.48 | *** join/#asterisk-dev luckman212 (~luckman21@2001:470:8abb:0:211:32ff:fe10:cdc1) |
| 18:58.23 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 19:06.35 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-41-221.user.veloxzone.com.br) |
| 19:20.46 | Corydon76-home | mjordan: there was a similar problem in the stdtime subsystem quite a few months back. There's a cleanup thread for watching symlinks change, and that was getting started before the fork(), which meant that an unrelated thread was getting the same tid. |
| 19:21.17 | Corydon76-home | My fix was to check ast_fullybooted before starting the cleanup thread. |
| 19:22.10 | Corydon76-home | Wasn't a problem until we started using ast_localtime() everywhere we had previously used localtime_r() |
| 19:22.34 | *** join/#asterisk-dev asterisk-Tester (~ramy@80.79.159.124) |
| 19:35.30 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 19:35.30 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 20:48.36 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 20:48.37 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:16.55 | mjordan | Corydon76-home: yup, it was that problem that led me to suspect fork(daemon) being the problem |
| 22:25.12 | wedhorn | mjordan, you got a minute |
| 22:27.51 | mjordan | wedhorn: yup |
| 22:28.38 | wedhorn | just wondering what the current "philosophy" is regarding what goes into various branches, ast11 (skinny of course) for myself and probably 8 for acidfoo |
| 22:29.22 | wedhorn | we generally stopped using 1.8 and 10 because patches were to invasive |
| 22:30.01 | wedhorn | ie, we were in the middle of restructuring skinny when they were branched |
| 22:30.30 | mjordan | wedhorn: so, as you are the module maintainer, part of that is your responsibility to define (imo). At the same time, the general rule that new features go into trunk; bug fixes into version branches should be followed. |
| 22:31.21 | *** join/#asterisk-dev rmeyerriecks (~rmeyerrie@nat/digium/x-dnzhdxoobhqyxpeu) |
| 22:31.34 | wedhorn | okay, should it maybe be defined somewhere, or is it defined for other areas of asterisk? |
| 22:32.03 | mjordan | it is defined |
| 22:32.12 | mjordan | ah |
| 22:32.16 | mjordan | do you mean for chan_skinny specifically? |
| 22:32.41 | wedhorn | no, but maybe for other chans/apps (to get some ideas) |
| 22:33.02 | mjordan | here's how I would phrase it - and I'd reply to the Software Configuration Management page discussion - for extended support modules, should the module maintainers be allowed to define their own configuration management policy with respect to new features? |
| 22:33.31 | russellb | seems like something that should be a project wide policy IMO |
| 22:34.10 | wedhorn | russellb, ah, the old sage who used to say no... |
| 22:34.31 | russellb | regardless if digium is maintaining the module or not, it's still the single asterisk project |
| 22:34.41 | russellb | just my $0.02 |
| 22:35.22 | mjordan | Its worth having a discussion on. I think the side to err on is russellb's, but I think you should at least make your case. |
| 22:35.38 | russellb | sure, discussions goooood |
| 22:36.05 | wedhorn | generally (up until now anyway) I was operating on new features (regardless how small) and too invasive into trunk |
| 22:36.30 | wedhorn | this of course would basically preclude anything acidfoo would come up with for 1.8 |
| 22:36.44 | mjordan | wedhorn: it was presumed that their channel driver would be for trunk |
| 22:37.02 | wedhorn | mjordan, the devcon notes indicated 1.8 |
| 22:37.09 | mjordan | they wrote it against 1.8 |
| 22:37.17 | mjordan | that doesn't mean it goes into that version :-) |
| 22:37.29 | mjordan | which is why they need to coordinate the feature set with you, and determine what the merge path should be. Ideally there should not be two channel drivers that serve the same protocol |
| 22:37.36 | wedhorn | skinny in trunk is a completely different beast to 1.8 (theirs or ast) |
| 22:37.41 | mjordan | agreed |
| 22:38.05 | wedhorn | okay, we'll cross that bridge when we come to it |
| 22:39.16 | wedhorn | the other side is ast11, I have some fixes that are invasive for skinny but no new features (such as the simpleswitch and locking/refcounting) |
| 22:39.59 | wedhorn | both have a reasonable possibility of having regressions, but will make the whole thing significantly more stable in the longer run |
| 22:40.18 | wedhorn | given it's a LTS release, I'm torn between trunk and 11 |
| 22:40.31 | mjordan | one way of justifying a large bug fix is to write automated tests |
| 22:40.46 | mjordan | if you're worried about regressions, its a suitable way of verifying functionality |
| 22:41.47 | wedhorn | it's an idea, I'll have to delve into the testing framework |
| 22:42.13 | mjordan | ...and speaking of which zomg a ship it on my patch! Going to be hard to wait 24 hours to *finally* fix this for the test suite |
| 23:06.49 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-spdhnzgaqhrkvxwe) |