| 00:24.27 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-qatqwbdlpuritron) |
| 00:40.56 | opticron | snuff-work, pong |
| 00:41.32 | opticron | snuff-work, those snapshots are supposed to be immutable |
| 00:41.48 | opticron | depending on how you get the snapshot, you may have to ref it yourself |
| 00:42.02 | opticron | the doxygen in the headers should tell you |
| 00:43.56 | opticron | if you're using the cache dump, you should be fine, though, since it returns a container of the current messages in the cache with them all ref bumped |
| 00:44.07 | snuff-work | mm.. ok.. that's what i'm doing :( |
| 00:44.33 | opticron | I'd have to look at the offending code to see what's going on |
| 00:44.43 | snuff-work | so i'm trying to work out why stuff is 'disappearing' |
| 00:45.06 | snuff-work | let me paste my 'updated slightly' version of nice crashy core show channels cli cmd |
| 00:46.50 | snuff-work | mm.. trying a dcc.. lol |
| 00:47.09 | snuff-work | u got a email addr or something where i can send my new rev of code ? |
| 00:58.03 | *** join/#asterisk-dev suneye (~atcmmi@119.139.63.101) |
| 01:25.46 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-fblvhfzbfvogutsk) |
| 01:25.46 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:02.34 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-fblvhfzbfvogutsk) |
| 03:52.56 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 03:52.56 | *** join/#asterisk-dev GameGamer43 (uid5533@gateway/web/irccloud.com/x-ocsdfjhftjkqsqee) |
| 03:53.48 | *** join/#asterisk-dev flapjacks (~flapjacks@wsip-184-183-148-253.ph.ph.cox.net) |
| 03:55.46 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 03:55.46 | *** join/#asterisk-dev GameGamer43 (uid5533@gateway/web/irccloud.com/x-ocsdfjhftjkqsqee) |
| 06:10.20 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 06:11.04 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 06:58.00 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 07:27.43 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:304c:9306:778c:fb0f) |
| 07:35.40 | *** join/#asterisk-dev suneye (~atcmmi@119.139.63.101) |
| 08:03.29 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:03.30 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:39.46 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 08:39.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:01.13 | oej | Hello folks |
| 11:27.08 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 11:59.34 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 11:59.34 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:07.08 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 12:32.00 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-lvvaulqzqnhuhoze) |
| 12:32.00 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:42.16 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-lvvaulqzqnhuhoze) |
| 12:56.49 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 13:44.59 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:44.59 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:57.54 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 13:57.54 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:11.52 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-pmynoywvvamryjtu) |
| 14:11.56 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:24.36 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-uavnejrmdwjiiwkf) |
| 14:25.22 | pabelanger | morning! |
| 14:27.55 | pabelanger | If I said autoservice_run() was sucking up CPU resources, would that make any sense? Meaning, would there be anything it does that would be CPU intense? |
| 14:27.56 | leifmadsen | merg! |
| 14:34.16 | *** join/#asterisk-dev flapjacks (~flapjacks@wsip-184-183-148-253.ph.ph.cox.net) |
| 14:44.22 | pabelanger | next question: A developer I am working with is proposing setting ast_set_priority(80), with in and application (app_fax.c in this case) to give its thread the highest priority within asterisk. Since we are having load issues, he wants to guarantee this thread gets first shot at CPU resources for an incoming fax. I think we are playing with fire |
| 14:45.06 | snuff-home | couldn't u just divert fax handling to another server instead? |
| 14:45.38 | pabelanger | no, we don't have the hardware for it. Embedded system |
| 14:45.45 | snuff-home | ah |
| 14:45.46 | pabelanger | plus, this is a selling feature |
| 14:45.49 | pabelanger | apparently |
| 14:47.19 | snuff-home | mm.. but fax processing is cpu intensive if i recall.. |
| 14:47.22 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-zjgrsimqppmouloi) |
| 14:47.41 | snuff-home | i mean it can't hurt to 'play with fire'.. doesn't mean that you wont get burned :) |
| 14:49.50 | pabelanger | snuff-home: true. We are at the point of two solutions, decrease load (which I've done) or increase the thread priority. I like my solutions better, since that are just asterisk configuration options. But the developer is standing is ground on his patch. Figured I'd get some input from people here |
| 14:50.55 | snuff-home | well i'm someone that is of no authority on the matter as * is a play thing for me.. aside from the company i work for uses it for our office.. (not a call center) |
| 14:53.04 | pabelanger | <PROTECTED> |
| 14:53.39 | pabelanger | I see no other module that does this either, so that is almost a reason in itself for me |
| 14:54.41 | snuff-home | mm time for some zz's then to play with my stasis version of 'core show channels' on the trian tomorrow |
| 14:54.48 | snuff-home | *train even |
| 14:55.04 | snuff-home | hopefully patch up by friday |
| 15:07.50 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:07.51 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:53.02 | JunK-Y | mooo! |
| 15:55.18 | Juggie | JunK-Y! |
| 15:59.41 | Qwell | opticron: What was the reason for making res_stasis_bridge_add a separate module? |
| 16:11.15 | opticron | Qwell, the new functionality for res_stasis tends to be moving in that direction |
| 16:11.32 | opticron | there is also a playback module there and another I can't remember atm |
| 16:12.06 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:12.13 | Qwell | answer |
| 16:12.31 | Qwell | but, there's a bridge remove function, in another location |
| 16:12.39 | opticron | the remove-from-bridge functionality couldn't go into a module because it doesn't follow the control queue and acts immediately (since the channel is blocking control queue execution) |
| 16:17.27 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:11e2:4d71:4f08:5110) |
| 16:21.47 | Qwell | So, if I remove res_stasis_answer.so, is it supposed to cause the /channels resource to not work at all? |
| 16:22.37 | Qwell | [Jun 19 11:21:53] WARNING[16086]: loader.c:510 load_dynamic_module: Error loading module 'res_stasis_http_channels.so': /usr/lib/asterisk/modules/res_stasis_http_channels.so: undefined symbol: stasis_app_control_answer |
| 16:23.40 | leedm777 | Qwell: hm. res_stasis_http_channels should bump the use count on res_stasis_answer. |
| 16:23.54 | Qwell | leedm777: I removed res_stasis_answer.so |
| 16:24.32 | leedm777 | since it's not an optional API, you shouldn't be able to do that. hence bumping the use count. |
| 16:24.32 | Qwell | If it still worked, it might be a good argument of being separate modules, but... |
| 16:25.13 | leedm777 | you make a valid point. |
| 16:25.56 | opticron | I assumed it was to keep things clean |
| 16:25.58 | leedm777 | That code belongs in a separate file, but not necessarily a sepeaate module. |
| 16:26.02 | Qwell | It's just really confusing to figure out where you need to change things. Some things are in res_stasis_http_channels, some appear to be in res_stasis, removing from a bridge is one place, adding to a bridge is a separate module entirely |
| 16:27.01 | leedm777 | The res_stasis_http_* could should be just HTTP specific code. |
| 16:27.47 | leedm777 | Unpacking arguments so it can call the appropriate res_stasis_* API. Packing the response into the appropriate HTTP response. |
| 16:30.50 | leedm777 | Splitting the res_stasis API into separate modules instead of just separate files may be been a bit overkill on my part :-) |
| 16:31.09 | file | use more XML!!! |
| 16:32.28 | leedm777 | "XML is like violence: if it doesn't solve your problem, you aren't using enough of it" |
| 17:39.04 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-todjjlipbddqhljd) |
| 17:46.55 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 17:46.57 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 18:00.42 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 18:08.39 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 18:25.04 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-xpwkheqwfzfrxlpz) |
| 18:36.35 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 18:38.22 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 18:50.19 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:50.19 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:54.39 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 18:54.39 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:56.14 | *** join/#asterisk-dev tilt_ (~tilt@173-13-180-97-sfba.hfc.comcastbusiness.net) |
| 19:01.20 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 19:01.20 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 19:58.30 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 20:52.05 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:10.05 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 22:48.42 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 23:00.00 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 23:06.05 | *** join/#asterisk-dev GameGamer43 (uid5533@gateway/web/irccloud.com/x-qqhbpeqdgdkofsep) |
| 23:06.48 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 23:48.27 | *** join/#asterisk-dev snuff-work (~snuffy@110.140.148.146) |
| 23:48.27 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:49.40 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:49.40 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |