| 02:17.42 | *** join/#asterisk-dev chazzam (~chazz@vps.roguewerks.com) |
| 05:58.52 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 06:51.08 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 06:59.51 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:27.54 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:31.01 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:58.29 | *** join/#asterisk-dev WIMPy (~wimpy@85.183.95.26) |
| 10:09.38 | *** join/#asterisk-dev etienne_ (~etienne@cap69-3-88-178-123-58.fbx.proxad.net) |
| 10:22.17 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 10:57.38 | *** join/#asterisk-dev Marquis42 (~Marquis42@d14-69-130-192.try.wideopenwest.com) |
| 11:48.00 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 12:06.15 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 12:55.06 | *** join/#asterisk-dev etienne_ (~etienne@cap69-3-88-178-123-58.fbx.proxad.net) |
| 13:02.59 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:02.59 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:05.07 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-czzezeapjlyzzmoz) |
| 13:07.00 | *** join/#asterisk-dev libardi (~kvirc@187.64.231.35) |
| 13:16.25 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-drbtxxubeusqckhs) |
| 13:16.25 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:47.09 | *** join/#asterisk-dev sh_smith (~smuxi@cpe-76-174-26-91.socal.res.rr.com) |
| 13:52.59 | file | gtjoseph, https://issues.asterisk.org/jira/browse/ASTERISK-26472 looks... familiar |
| 13:54.15 | gtjoseph | yes it does. iirc one of alexei's patches addressed that but it should have already been in 14.0.2 |
| 13:54.29 | file | I think it was a PJSIP thing, actually |
| 13:55.00 | gtjoseph | out pjsip or pjproject? |
| 13:55.02 | gtjoseph | our |
| 13:55.11 | gtjoseph | and it was freepbx so maybe not using bundlked |
| 13:55.15 | file | got it |
| 13:55.30 | file | https://trac.pjsip.org/repos/ticket/1946 |
| 13:55.55 | file | I think |
| 13:56.00 | file | yup |
| 13:58.37 | putnopvut | I'm having a bit of a python brainfart |
| 13:58.39 | putnopvut | https://paste.fedoraproject.org/453915/12681147/ |
| 13:58.49 | putnopvut | Can anyone see what I've done to get the NameError being reported? |
| 13:59.45 | file | you have two on_channel_events? one before on_start is defined? |
| 14:00.23 | putnopvut | aha! |
| 14:00.30 | putnopvut | Thanks I knew it would probably be something dumb |
| 14:01.48 | file | yw |
| 14:03.04 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 14:06.12 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-gskgmjyidnuvgrxw) |
| 14:07.23 | coreyfarrell | file: damn, the version of gcc/lcov/genhtml all the agents have the bug that screws up the way it handles sources in sub-folders. |
| 14:07.38 | coreyfarrell | genhtml: ERROR: cannot open /srv/jenkins/workspace/periodic-asterisk-13/asterisk/apps/confbridge/confbridge/conf_chan_record.c for reading! |
| 14:08.58 | coreyfarrell | that's what I get for thinking it was good enough to test coverage reports in centos7 |
| 14:11.00 | file | dun dun dunnnnnnnn |
| 14:11.24 | *** join/#asterisk-dev jkroon (~jkroon@154.73.32.14) |
| 14:15.12 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-ldrdqkzndxxwsria) |
| 14:15.42 | file | coreyfarrell, what can we do? |
| 14:19.07 | coreyfarrell | bamboo had some fixup it did on the output of lcov, i'm hoping it still works for old versions but doesn't break new versions. also going to try a trick with lcovrc settings. |
| 14:20.21 | coreyfarrell | not sure which will work better, hopefully one of the fixes will be compatible with both old and current versions |
| 14:21.07 | coreyfarrell | your call if you want to revert my coverage change for now or not |
| 14:21.53 | file | I'd like to keep periodics stable and useful if we can so we can uncover stuff faster |
| 14:21.59 | file | right now it's hit/miss with that change in |
| 14:22.47 | coreyfarrell | really? my changes have no effect on the tests being run (only processing done after all testing completes) |
| 14:23.00 | file | it interrupts the processing |
| 14:23.09 | file | so that you have to manually go look at the results of the console log |
| 14:23.36 | coreyfarrell | ah so we're missing some artifacts.. yes revert it |
| 14:24.07 | file | done. |
| 14:25.59 | coreyfarrell | when I resubmit I need a new change-id? |
| 14:26.09 | file | I dunno! :D |
| 14:26.18 | file | probably |
| 14:26.22 | file | or we can revert the revert |
| 14:35.47 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:35.47 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:42.15 | file | A wild cresl1n appears. |
| 14:44.42 | cresl1n | waves |
| 14:45.15 | *** join/#asterisk-dev Qwell (~north@asterisk/developer/Qwell) |
| 14:45.15 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 14:54.18 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 15:08.42 | putnopvut | So, I have a patch written that will prevent a channel from being created if the unique ID for that channel already is assigned to an existing channel. |
| 15:08.46 | putnopvut | I've tested it. It works. |
| 15:08.55 | putnopvut | But there's one thing about it I don't like. |
| 15:09.28 | putnopvut | In ARI, if you hit this error, because I'm doing the check way down in the internals of channel allocation, it results in a 500 error being sent by ARI, making it look like an allocation failure. |
| 15:09.46 | putnopvut | I'd rather get a 409 or something similar sent back so that it's more clear that the client is the one screwing up. |
| 15:09.48 | file | hum |
| 15:09.48 | file | yeah |
| 15:10.00 | putnopvut | So, I could move the unique ID check to the ARI code to do that. |
| 15:10.11 | putnopvut | But then you don't get the benefit of the check happening for all channel allocations. |
| 15:10.21 | file | yeah... |
| 15:10.22 | putnopvut | On the other hand, does anything else have the ability to specify a unique ID when creating a channel? |
| 15:10.47 | gtjoseph | can you pass a return code back up the stack to ARI? |
| 15:10.56 | file | gtjoseph, AHAHAHAHAHA |
| 15:11.10 | file | putnopvut, do we allow it in AMI on originate? |
| 15:11.44 | putnopvut | gtjoseph: unfortunately, no. And file, not sure. I can check. |
| 15:12.12 | putnopvut | file: yes, we do. |
| 15:12.13 | gtjoseph | how expensive is the check? Can you just do it twice? |
| 15:12.33 | file | race. |
| 15:12.41 | putnopvut | Expense is based on the number of channels (It's O(n) where n is number of channels in channel container) |
| 15:12.51 | putnopvut | Channel container isn't hashed on uniqueid, so you have to walk the whole container. |
| 15:13.19 | gtjoseph | figures |
| 15:13.37 | putnopvut | And you have to do it twice potentially, since you can specify two unique IDs (for when you are creating local channels) |
| 15:13.41 | gtjoseph | so "unique" isn't really unique. |
| 15:13.55 | putnopvut | Nope, and that's what I'm fixing :) |
| 15:14.26 | putnopvut | This is what happens when you blindly accept IDs as being "unique" from outside. |
| 15:14.58 | putnopvut | The fix here is to not be blindly accepting. The issue is just where to place the check. I'm more concerned about correctness and user experience now than computational expense. |
| 15:15.05 | gtjoseph | is it worth creating a secondary container that is really unique in uniqueid? |
| 15:15.07 | putnopvut | There are lots of good changes we could make |
| 15:15.17 | putnopvut | Hash on unique ID, pass error codes from channel allocation |
| 15:15.35 | putnopvut | Hard question to answer. |
| 15:15.57 | putnopvut | Because, and you'll like this, ast_channel_get_by_name() allows for you to specify either the channel name or unique ID when retrieving a channel. |
| 15:16.09 | gtjoseph | :) |
| 15:16.14 | file | yeah. |
| 15:16.16 | putnopvut | So if we're optimizing to allow searching by unique ID, we'd also need to add a new API call to get a channel by unique ID |
| 15:16.26 | putnopvut | And that *may* cause restrictions where there previously were not. |
| 15:16.52 | putnopvut | Since there were places where we'd accept a name or unique ID and it'd just work out. |
| 15:17.40 | gtjoseph | is the channels container hashed by anything or is it just a list. i forget. |
| 15:17.47 | putnopvut | It's hashed on channel name |
| 15:18.24 | gtjoseph | ah, ok. so if you added the secondary container hashed by unique id, the naor or id lookup would still be pretty fast |
| 15:18.35 | gtjoseph | name or id |
| 15:18.52 | putnopvut | Yep |
| 15:19.11 | putnopvut | In fact, I bet you'd get an across-the-board speedup on ARI applications |
| 15:19.16 | gtjoseph | it's be faster than today even |
| 15:19.18 | putnopvut | Since it uses channel unique IDs. |
| 15:19.22 | gtjoseph | exactly |
| 15:19.52 | putnopvut | The one thing I have to look into is what happens with unique ID on a masquerade. |
| 15:20.21 | gtjoseph | might it change you mean? |
| 15:20.39 | putnopvut | Yeah, I don't know if one channel inherits the unique ID of the channel that ends up being zombified. |
| 15:20.50 | putnopvut | Since they're supposed to be "the same channel" |
| 15:21.05 | gtjoseph | ew |
| 15:21.08 | putnopvut | The end of all this is that I'm going to create an internal issue for us to hash by unique ID. |
| 15:21.23 | putnopvut | For the time being, I just want to make sure that people can't specify an existing unique ID |
| 15:21.23 | gtjoseph | makes sense. |
| 15:21.34 | stefan27 | What's the maximum number of channels allowed to exist at any time? None of our installations ever had more than 200; do you know of any production environments which may have 10 000+ channels? (just curious) |
| 15:21.58 | putnopvut | There's no hard-coded maximum. It's based on what your hardware can handle. |
| 15:22.15 | putnopvut | There's a theoretical limit you'd reach based on the number of file descriptors used. |
| 15:22.21 | stefan27 | what's the highest number you got covered by any test suite? |
| 15:22.23 | coreyfarrell | putnopvut: can you create a function to check for duplicate channel uniqueid that is called from AMI and ARI? |
| 15:22.36 | putnopvut | That's what I was thinking about doing. |
| 15:22.51 | putnopvut | That way, you can get better error returns. |
| 15:22.53 | file | stefan27, not that many - it's not the purpose of the testsuite to test that currently |
| 15:23.06 | putnopvut | It just kind of sucks that they have to know to do that themselves. |
| 15:23.26 | coreyfarrell | I'd guess the masquerade test is probably the one that hits the highest channel count |
| 15:23.26 | putnopvut | But no biggie. I'll just do it that way. |
| 15:23.36 | gtjoseph | i'd opt for the self protection even if they get a 500 for now |
| 15:23.37 | file | my only concern about checking is the race condition between checking and creation again |
| 15:23.55 | stefan27 | Ah okay |
| 15:25.13 | putnopvut | file: I'm not sure I follow. Can you explain the race a bit further? |
| 15:25.57 | file | putnopvut, if you do a check if a channel exists with a specific uniqueid outside the scope of allocation - can you guarantee that by the time allocation is done that something else hasn't created a channel with the same uniqueid? |
| 15:27.25 | putnopvut | Ah I see. |
| 15:27.59 | putnopvut | It'd take a real asshole ARI program to do that, where they're purposely trying to mimic the unique ID style that Asterisk uses internally |
| 15:28.08 | file | sure |
| 15:29.15 | gtjoseph | could also be an ARI client that steps on itself |
| 15:29.38 | gtjoseph | i.e uses a unique id pattern that may have inherent conflicts |
| 15:30.40 | putnopvut | But if it's within ARI, then we'd catch the duplicates |
| 15:30.50 | putnopvut | Oh wait I see |
| 15:30.58 | file | pushes putnopvut out of the narrow window |
| 15:31.00 | putnopvut | Yeah, they both could pass the test and then both allocate with the same unique ID |
| 15:31.08 | gtjoseph | yeppers |
| 15:31.53 | coreyfarrell | putnopvut: crazy idea - __ast_channel_alloc could do: errno = EEXIST; return NULL; :) |
| 15:32.03 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-pgwwtwoqigvpgqgi) |
| 15:32.18 | gtjoseph | file: laughed at me when i suggested that |
| 15:32.32 | file | I did? |
| 15:32.39 | gtjoseph | well, maybe not the errno |
| 15:32.46 | putnopvut | Nah, he laughed if you asked if there were error codes |
| 15:32.56 | putnopvut | Which, there definitely aren't right now. |
| 15:33.00 | cresl1n | Don't touch errno |
| 15:33.11 | cresl1n | (IMHO) |
| 15:33.14 | putnopvut | ast_channel_errno() :) |
| 15:33.15 | gtjoseph | You could do like what we do with ast_config_load |
| 15:33.16 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 15:33.23 | file | ugh |
| 15:33.26 | cresl1n | gtjoseph nasty |
| 15:33.31 | gtjoseph | i know |
| 15:33.42 | cresl1n | I will wretch on that code review |
| 15:33.56 | gtjoseph | honestly, i think the 500 is ok for now. |
| 15:34.15 | file | if we really didn't want to change the API (which we shouldn't), the cleanest way would be to use thread local storage and make a construct for errno from that |
| 15:34.21 | gtjoseph | self protection is priority over nice error megssage |
| 15:34.25 | coreyfarrell | putnopvut: ast_channel_errno() isn't actually a bad idea, you could use AST_THREADSTORAGE_RAW to store an integer.. |
| 15:34.30 | file | coreyfarrell, yup! |
| 15:36.10 | file | gtjoseph, I... disagree. If there's one thing I've heard loud and clear with ARI too it's error responses - 500 is too broad. |
| 15:36.45 | gtjoseph | not saying that's the final solution |
| 15:37.00 | gtjoseph | 500 for now, then add container hashed by unique id |
| 15:37.02 | putnopvut | I'll explore the channel errno possibility. |
| 15:37.26 | file | container is an optimization that can definitely go for later, fix for this should include prevention + useful error response |
| 15:37.31 | file | putnopvut, ack |
| 15:37.38 | gtjoseph | you can do the uniqueid test in resource_channels with a lock |
| 15:38.20 | putnopvut | There's still the theoretical clash between ARI/AMI or ARI and Asterisk internally-generated IDs. That is soooo remote though |
| 15:39.09 | file | if the cost of trying to handle that for such a remote case is high, then so be it... but I think with what coreyfarrell and I have said it's not bad and would work for both |
| 15:39.21 | putnopvut | Channel errno seems like a nicer idea in that it could be used for all channel functions (create, read, write, etc.). |
| 15:39.30 | file | putnopvut, sure could |
| 15:39.31 | putnopvut | I'd just be starting the ball rolling with an AST_CHANNEL_EEXISTS |
| 15:40.32 | gtjoseph | as long as the error is generated by the thread making the first call |
| 15:40.44 | gtjoseph | does any work get pushed to a taskprocessor? |
| 15:41.00 | gtjoseph | the exists check probably not |
| 15:41.01 | file | not for that stuff |
| 15:41.24 | coreyfarrell | file: agreed about 500 (really 5xx). they should never be the response to invalid HTTP client request. at minimum it should be 400 (generic rejection of user input) |
| 15:47.05 | file | gtjoseph, merci pour le electronique mail dans liste de PJSIP |
| 15:47.52 | gtjoseph | file Pas de problème |
| 16:52.03 | *** join/#asterisk-dev piling (~piling@unaffiliated/piling) |
| 17:23.48 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 17:33.39 | *** join/#asterisk-dev bof22 (~Thunderbi@ARennes-650-1-9-74.w90-32.abo.wanadoo.fr) |
| 18:03.27 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 18:25.59 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 18:26.03 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 18:38.40 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 18:54.22 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00a946fcbff129bb41.ipv6.abo.wanadoo.fr) |
| 19:02.25 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 19:30.22 | putnopvut | btw, I have a pretty nice channel errno implementation for the duplicate unique ID problem working now. But I'm not going to put it up for review without also having something in the testsuite for it. |
| 19:31.00 | file | nifty |
| 20:18.32 | *** join/#asterisk-dev dandann00dle (uid120491@gateway/web/irccloud.com/x-khwqpqfqzeptdkmx) |
| 20:30.15 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 21:07.25 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 23:02.18 | *** join/#asterisk-dev tuxd00d_ (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 23:26.39 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-gskgmjyidnuvgrxw) |