| 01:14.04 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 01:52.38 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-beapcdcynuryobro) |
| 02:52.07 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 03:19.57 | *** join/#asterisk-dev otherwiseguy (~otherwise@23.228.175.118) |
| 04:25.01 | *** join/#asterisk-dev jagruti_ (~root@122.179.148.42) |
| 04:27.40 | *** part/#asterisk-dev jagruti_ (~root@122.179.148.42) |
| 05:25.05 | *** join/#asterisk-dev fahmad (~fahmad@unaffiliated/fahmad) |
| 05:31.55 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 05:31.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:59.21 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 05:59.21 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 06:27.31 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:27.31 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:46.17 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:46.17 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:19.21 | oej | Hello folks |
| 07:22.25 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:25ac:9f94:9853:89f) |
| 08:11.21 | *** join/#asterisk-dev michael_work (~michael@bzq-112-168-31-118.red.bezeqint.net) |
| 08:12.27 | michael_work | oej, btw wanted your optinion about my yesterday proposal |
| 08:13.55 | michael_work | as far as it works now the queuerules file is loaded only if file is changed. but the problem is if i turn realtime i still need reload. so basically what i did is if the realtime is on - always read from file and if relatime is off - act as it acted |
| 08:16.53 | oej | I don't follow. Try again… |
| 08:23.14 | michael_work | you remember the talk about queue rules |
| 08:23.39 | michael_work | and that i wanted to make patch to be able to load/update them from realtime |
| 08:26.12 | oej | yes |
| 08:26.40 | oej | Do you know the difference between static realtime and dynamic realtime? |
| 08:31.22 | michael_work | nope |
| 08:33.01 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 08:34.28 | oej | Ok, you need to know this. |
| 08:34.42 | oej | ALL config files can be loaded from realtime at start or a reload |
| 08:34.51 | oej | You do not ned to code anything for that. |
| 08:34.56 | oej | This is what we call static realtime. |
| 08:35.25 | oej | If you have objects that change a lot during runtime that you need to load and forget about, that's when we code realtime stuff into a module - that's dynamic realtime |
| 08:35.38 | michael_work | and dynamic realtime is like SIP when it loads without reload if needed? |
| 08:36.19 | michael_work | can you give the exmples of usage of both? |
| 08:42.14 | oej | extconfig.conf is static realtime - loading configurations from databases using realtime drivers |
| 08:42.34 | oej | I can use it for anything |
| 08:42.44 | oej | As long as you define a config file I can load it from there. |
| 08:43.10 | oej | So the question is - does your rules really change a lot , like many times an hour, during runtime? |
| 08:51.04 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:51f1:a5a8:c01a:37e2) |
| 08:55.49 | michael_work | oej, exactly i use the ones from extconfig |
| 08:56.45 | michael_work | and not sure how much they change, but on other hand how much you change Q and it's in realtime |
| 08:56.59 | michael_work | and rule would change same as Q |
| 08:59.12 | michael_work | it's easier for me to have single API to have everything in one place to update in one place |
| 09:00.59 | oej | IF rule only change when queue config change then you still need to issue a reload |
| 09:01.25 | michael_work | i'm not good at self explanation :( |
| 09:01.42 | oej | We only need dynamic realtime for objects that change all the time. |
| 09:01.48 | michael_work | the old option is like that - it checks if file is changes and then reloads it |
| 09:01.48 | oej | People use realtime for stuff they should not. |
| 09:01.58 | oej | Which is fine. |
| 09:02.50 | michael_work | it depends - if you have a lot of people and everyone want his own rule and you give them api for that - it's better to keep it in realtime in my opinion |
| 09:03.22 | michael_work | as well as i have few more patches where i have more options in queue rules tro change with time and not only penalty :) |
| 09:03.40 | michael_work | which make it used more and changed more |
| 09:04.30 | michael_work | and finally my feature comes as optional and if is off it would not change the current behaivor |
| 09:04.54 | michael_work | only thing i added is [general] for config file where i can save future options to queuerules |
| 09:05.01 | oej | The question is not whether or not to use database, Michael |
| 09:05.08 | oej | The question is how often it changes |
| 09:05.59 | oej | I understand that everyone wants their own config, that can still be done in static realtime mode. |
| 09:06.20 | oej | But do they change their config when they take a coffee break, go for a pee, change their mood? |
| 09:06.37 | oej | Or is the config for an agent pretty static week in and out when you got it right? |
| 09:07.49 | michael_work | i'm not vconfigurating the config and there are different people who does |
| 09:08.27 | oej | Right. and? |
| 09:11.42 | michael_work | on one hand they might not change it, than it's okay as no reload command would run and than it would not read from db (so the rules are loaded in memory) |
| 09:11.57 | michael_work | the rules are loaded to memory after all |
| 09:12.18 | michael_work | so basically it does not query db everytime |
| 09:12.24 | michael_work | it queries on reload only |
| 09:12.38 | michael_work | so i do not see the difference between to keep in file or db |
| 09:12.41 | michael_work | as it's same io |
| 09:13.02 | michael_work | it's just easier to maintain for me in DB |
| 09:13.07 | michael_work | than in file |
| 09:13.59 | michael_work | as for example to have single db for few servers with rules so if someone have few Q's different servers i do not need to update them in fil;es at all servers but only one place |
| 09:14.08 | michael_work | everything has use cases |
| 09:14.18 | michael_work | and optional and modular thing is good |
| 09:14.21 | michael_work | as it's not instead |
| 09:19.47 | *** join/#asterisk-dev fahmad (~fahmad@unaffiliated/fahmad) |
| 09:23.11 | oej | If they just read DB on reload, use the config subsystem, do not develop with th realtime api |
| 09:23.36 | oej | That means that other users can easily select betwen DB, HTTP, text files and all other drivers |
| 09:23.54 | oej | the realtime API should *NOT* be used for something that stays in memory. |
| 09:24.05 | oej | That's static realtime, whcih is handled by the config api. |
| 09:27.19 | michael_work | i use the one that is used in extconfigs.conf |
| 09:27.55 | michael_work | queue_rules => mysql,starkey_asterisk,queue_rules |
| 09:27.57 | oej | Ok, then we're in agreement. That's static realtime, which is what I want you to use :-) |
| 09:28.39 | michael_work | that's why you got me confused as i call it realtime |
| 09:28.57 | michael_work | it's not real realtime as it's not goes there everytime but on reload only |
| 09:29.00 | oej | That's static realtime. Most people don't know that. |
| 09:29.09 | michael_work | i learned now too |
| 09:29.10 | oej | What we call "realtime" is normally something else. |
| 09:29.26 | oej | You simply use the config subsystem, which where everyone should start. |
| 09:29.26 | michael_work | i thought to look into cache option |
| 09:29.59 | michael_work | like in moh or otheres there is cache opton - but too early for me :P |
| 09:30.23 | michael_work | oej, btw thanks for advices and being patient with me :) |
| 09:31.25 | oej | You're welcome, Michael |
| 09:45.51 | michael_work | oej, can i ask noob question? what is AST_DATA_STRUCTURE used for and as well i see there is DATA_EXPORT_CALL_QUEUE |
| 10:43.53 | *** join/#asterisk-dev bhavikpatel6842 (~root@122.179.148.42) |
| 10:44.46 | *** part/#asterisk-dev bhavikpatel6842 (~root@122.179.148.42) |
| 10:54.55 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 10:54.55 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:55.04 | file | michael_work, it was an API that was supposed to be for data retrieval of things - but it never really took off |
| 10:55.05 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 11:20.13 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 11:30.13 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 11:30.13 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:52.28 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 12:18.36 | *** join/#asterisk-dev sliske_- (~sliske_@2001:4800:780e:510:6c33:9987:ff05:245f) |
| 12:18.36 | *** join/#asterisk-dev Sjors (~sgielen@foo.kassala.de) |
| 12:32.19 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 12:40.21 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 12:40.21 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 12:57.50 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 12:57.50 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:07.53 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:07.54 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:19.20 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-kcywvkixxqaagaze) |
| 14:00.27 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 14:02.40 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-crrfawvmpdnazjfw) |
| 14:02.40 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:03.29 | *** join/#asterisk-dev terryw (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 14:05.11 | jameswf | I think the guy in #asterisk had a coming to jesus moment ;) |
| 14:07.05 | fahmad | hehe |
| 14:12.14 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-emqkbdgoeqwuljwq) |
| 14:20.54 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-sqeyfswunnurypqb) |
| 14:36.40 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 14:51.16 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 14:57.38 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 15:18.13 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:26.53 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 15:30.53 | *** join/#asterisk-dev terryw (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 15:38.28 | *** join/#asterisk-dev mjordan (~mjordan@173.227.23.10) |
| 15:38.28 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:52.11 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 15:58.13 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:51f1:a5a8:c01a:37e2) |
| 16:34.57 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 16:54.20 | *** join/#asterisk-dev scouture (~scouture@unaffiliated/scouture) |
| 16:56.55 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 16:56.55 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 16:58.28 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 17:06.12 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-codsnjzyveuauunw) |
| 17:06.12 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 17:18.00 | file | hrm |
| 17:18.08 | newtonr | file, these QLOOG guys really want their language patch in, more reviews on that could be helpful https://reviewboard.asterisk.org/r/3477 |
| 17:18.23 | file | kharwell, I wonder what impact the change you made for moving setting stuff to newpvt would have in main branches... |
| 17:19.37 | kharwell | file: have something in mind problem wise? or has the code been changed there in main? |
| 17:19.45 | file | it hasn't, I was just thinking performance impact on transcoding |
| 17:21.15 | file | newtonr, ack ack |
| 17:24.17 | kharwell | file: hopefully in a good way |
| 17:24.25 | file | kharwell, well... yes |
| 19:12.00 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 19:56.03 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.153.51) |
| 20:06.31 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 20:10.35 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 20:10.35 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:15.34 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-gkdrgczsjohgfqot) |
| 20:15.34 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 21:14.43 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 21:35.33 | tm1000 | newtonr: file getting those changes in for qloog would be awesome :-) |
| 21:35.35 | tm1000 | good guys |
| 21:36.50 | newtonr | yeah, having Japanese prompts will be neat |
| 21:37.55 | tm1000 | file: you have an excellent eye sir |
| 21:38.02 | file | do I? |
| 21:38.41 | tm1000 | you noticed that change when no one else did |
| 21:38.48 | file | I like my eyes, they allow me to see |
| 21:38.52 | file | and if I wear glasses I can see even better! |
| 21:41.52 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 21:41.53 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 21:48.59 | tm1000 | sgriepentrog: you dont have to review that code |
| 21:49.05 | tm1000 | you get included in all |
| 21:49.06 | tm1000 | lol |
| 21:49.39 | sgriepentrog | no worries. I kinda figured that, not having much experience with dahdi... |
| 21:58.30 | *** join/#asterisk-dev terryw (~otherwise@69.76.153.51) |
| 22:18.32 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 22:18.32 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 22:25.17 | gtjoseph | rmudgett: got a sec for an astobj2 question? |
| 22:25.59 | rmudgett | gtjoseph: sure |
| 22:27.44 | gtjoseph | today's code... in internal_a02_ref it looks like there's a period of time between when the refcount is 0 and magic gets set to 0 that the obj could be interted inito a container again. |
| 22:27.54 | gtjoseph | inserted |
| 22:28.33 | gtjoseph | since INTERNAL_OBJ only checks magic and not refcount, link could get a valid handle again. |
| 22:28.45 | gtjoseph | yes? |
| 22:29.14 | rmudgett | Where in the container code is this happening? When a ref goes to zero the destructor is called and the object is no longer valid. |
| 22:29.35 | rmudgett | When it goes to zero no one else is supposed to have a pointer to the object anymore. |
| 22:29.47 | gtjoseph | hmmm. |
| 22:30.03 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-emqkbdgoeqwuljwq) |
| 22:30.25 | gtjoseph | "supposed to" i guess is the question. |
| 22:30.59 | rmudgett | It is definitely a bug if someone else still has a pointer. |
| 22:31.16 | sgriepentrog | gtjoseph: what are you trying to prevent? |
| 22:32.49 | gtjoseph | in my quest for weak ref containers, rmudgett pointed out some locking issues so i'm just trying to get straight what the situation is currently |
| 22:33.03 | sgriepentrog | Ah. |
| 22:33.49 | gtjoseph | I.E. How much badness do you code for and how much to you rely on the user-developer to be smart. :) |
| 22:34.09 | file | you can only enforce to an extent |
| 22:34.48 | gtjoseph | yep. remember that when I submit the review again. :) |
| 22:34.52 | rmudgett | The rest is up to the programmer knowing what he is doing. Although, that isn't always the case. :) |
| 22:38.21 | gtjoseph | rmudgett: I'm thinking that INTERNAL_OBJ should return NULL if an object is being destroyed just as it does if the magic is 0. I think maybe that'll help. |
| 22:38.41 | gtjoseph | with some of my locking anyway |
| 22:40.44 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 22:46.56 | rmudgett | gtjoseph: That should be fine. The object is effectively destroyed at that point. |
| 23:18.29 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 23:47.50 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:47.50 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |