| 00:19.27 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 00:19.27 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 00:43.49 | *** join/#asterisk-dev jgowdy (sid239878@gateway/web/irccloud.com/x-nwgfvbguehxxxjws) |
| 01:22.48 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.169) |
| 01:38.28 | *** join/#asterisk-dev tzafrir (~tzafrir@lemon.tzafrir.org.il) |
| 01:38.28 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 04:42.55 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@24-177-250-191.dhcp.nwtn.ct.charter.com) |
| 04:42.55 | *** mode/#asterisk-dev [+o coreyfarrell] by ChanServ |
| 06:11.58 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.126) |
| 08:09.32 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 12:30.02 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 14:08.02 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-prejbtwdurqdxzdl) |
| 14:08.02 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:34.15 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-vrhjwhpvaokwsowf) |
| 14:34.16 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:49.12 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-wijgyfdujdyzbpjz) |
| 14:49.12 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:05.58 | seanbright | so let's say that i have ephemeral PJSIP endpoints. i name them endpoint1, endpoint2, endpoint3, and so on. and that trailing number increases monotonically forever |
| 15:06.11 | seanbright | these endpoints are defined in realtime |
| 15:06.27 | seanbright | it looks like each of these endpoints gets its own task processor |
| 15:06.38 | seanbright | it also looks like these task processors never go away |
| 15:06.53 | seanbright | does that describe the current behavior as it is commonly understood? |
| 15:18.42 | seanbright | well, let me ask a different way, what is a 'subp' task processor exactly? |
| 15:19.01 | gtjoseph | subscription publish |
| 15:20.31 | seanbright | under what circumstances would that need to be created for a pjsip endpoint that doesn't pubsub? |
| 15:20.47 | seanbright | or put another way, how do i prevent that from occurring for a given endpoint? |
| 15:21.17 | gtjoseph | not sure. does the endpoint use MWI? |
| 15:21.53 | seanbright | no |
| 15:22.17 | gtjoseph | you'd have to look in the code to see where the subp taskprocessor is created. |
| 15:22.31 | seanbright | alrighty |
| 15:22.33 | seanbright | thanks |
| 15:43.54 | seanbright | gtjoseph: looks like it happens in ast_endpoint_create() |
| 15:44.11 | gtjoseph | yeah that makes sense, kinda |
| 15:44.36 | gtjoseph | is there any logic to it or is it always created? |
| 15:45.14 | seanbright | basically always |
| 15:45.16 | gtjoseph | and who who adds tasks to it? |
| 15:45.30 | seanbright | endpoint->router = stasis_message_router_create_pool(ast_endpoint_topic(endpoint)); |
| 15:46.01 | gtjoseph | oh |
| 15:46.33 | gtjoseph | so it's not really pubsub then. it's stasis. |
| 15:47.50 | gtjoseph | is it not cleaned up if the endpoint goes away? |
| 15:48.36 | seanbright | the 66k taskprocessors i am seeing in 'core show taskprocessors' says no |
| 15:49.00 | gtjoseph | yeah so that'd be a bug :) |
| 15:49.25 | file | there would have to be logic added to somehow reconcile it |
| 15:49.52 | gtjoseph | yeah. there should be destructor for that somewhere though |
| 15:49.56 | coreyfarrell | seanbright: could you do a minimal reproduction with refdebug enabled? in 15+ you can enable it from asterisk.conf. |
| 15:50.17 | seanbright | coreyfarrell: i don't think it is refcounting related |
| 15:50.20 | gtjoseph | don't forget, that's the "asterisk" endpoint, not specific to pjsip. |
| 15:50.21 | file | gtjoseph: endpoints come and go, they aren't kept in memory unless you do caching |
| 15:50.22 | seanbright | i think we just don't unlink it |
| 15:50.34 | file | the internal endpoint is the state associated with it |
| 15:50.46 | file | (internal state) |
| 15:50.52 | seanbright | so basically, nothing is telling asterisk that the endpoint is no longer valid |
| 15:50.53 | gtjoseph | yeah |
| 15:51.00 | seanbright | or needed, i guess |
| 15:51.33 | seanbright | the endpoint_deleted_observer unlinks it from persistent_endpoints |
| 15:51.38 | seanbright | which should cause it to be destroyed |
| 15:51.51 | seanbright | but sorcery doesn't know to delete it? |
| 15:51.53 | file | that is if it is deleted through sorcery |
| 15:52.05 | seanbright | ok, so how do you tell sorcery to delete it? |
| 15:52.06 | file | there is no interface between Asterisk and the database to know if it is deleted |
| 15:52.10 | seanbright | roger |
| 15:52.22 | seanbright | can i tell it somehow manually? |
| 15:52.28 | file | not currently afaik |
| 15:52.32 | seanbright | mkay |
| 15:52.58 | gtjoseph | well, i think, depending on caching, if you try to use it it'll flush |
| 15:53.42 | gtjoseph | if you do pjsip list endpoints what happens? |
| 15:54.11 | seanbright | its not listed under endpoints (i presume because of realtime?) |
| 15:54.19 | seanbright | and the task processor stays |
| 15:54.46 | gtjoseph | it it's not listed under endpoints, then the pjsip endpoint destructor did run |
| 15:55.12 | seanbright | it's not listed under endpoints while the call is going on |
| 15:55.31 | gtjoseph | really? is caching enabled? |
| 15:55.45 | seanbright | no |
| 15:55.54 | seanbright | because i don't want it to be |
| 15:56.03 | seanbright | unless enabling it will fix my problem |
| 15:56.04 | seanbright | :-) |
| 15:56.43 | seanbright | gtjoseph: https://pastebin.com/raw/07DxhnSU |
| 15:57.19 | gtjoseph | hmmm. so it's NOT in the db but you can still use it? |
| 15:57.20 | seanbright | i have never seen my ephemeral endpoints when running 'pjsip show endpoints' |
| 15:57.25 | seanbright | it IS in the db |
| 15:57.30 | gtjoseph | ah |
| 15:57.37 | seanbright | well |
| 15:57.52 | gtjoseph | <PROTECTED> |
| 15:57.59 | seanbright | so this is what happens |
| 15:58.48 | seanbright | a user logs in to our application. we create some ephemeral credentials and send them down to the user. the user's application uses those credentials to register/call one of our PBXs |
| 15:59.20 | seanbright | we use res_config_curl to query an API that returns the endpoint, auth, and aor info with the credentials we generated |
| 15:59.49 | seanbright | when the user logs out of our application, we destroy the credentials |
| 16:00.04 | gtjoseph | destroy how? |
| 16:00.40 | gtjoseph | just delete from the db? |
| 16:00.44 | seanbright | we destroy the credentials in our service. so basically if you were to query the API again after the user had logged out you would get a 404. |
| 16:00.47 | seanbright | yes |
| 16:00.49 | seanbright | effectively |
| 16:01.20 | seanbright | when someone says db i think rdbms. we just have an in-memory store in our API service. |
| 16:01.22 | gtjoseph | ok so you know you can use ARI to create and delete sorcery object right? and if the backend is a DB, it'll create and delete them there as well. |
| 16:02.01 | gtjoseph | not sure of that'll help |
| 16:02.14 | seanbright | i was hoping for more of a 'quick fix' |
| 16:02.24 | cresl1n | Ugh |
| 16:02.25 | seanbright | switching to ARI is non-trivial |
| 16:02.26 | cresl1n | jenkins! |
| 16:03.07 | file | there is no quick fix for this, it's not a pattern anyone has tackled afaik |
| 16:03.14 | seanbright | got it |
| 16:03.30 | seanbright | we'll probably just end up changing the format of our ephemeral credentials |
| 16:04.08 | gtjoseph | you could try some messages in the pjsip endpoint destructor to see if it's getting called. |
| 16:04.10 | seanbright | so that they are not perpetually unique |
| 16:04.40 | gtjoseph | if it is getting called, maybe we just need to unref the internal endpoint as coreyfarrell daid. |
| 16:05.03 | seanbright | gtjoseph: but why am i not seeing the endpoints listed under 'pjsip show endpoints?' |
| 16:05.09 | seanbright | even while the call is going on? |
| 16:05.14 | file | because that queries the backend for the endpoints |
| 16:05.19 | seanbright | ah ha |
| 16:05.59 | seanbright | POST: /PJSIPe/multi {id LIKE = "%"} |
| 16:06.01 | seanbright | sure enough |
| 16:06.26 | gtjoseph | i think i did something like "don't query the db" to prevent someone from performing a full database retrieval from the cli |
| 16:07.43 | gtjoseph | see if anything here will help.. https://wiki.asterisk.org/wiki/display/AST/Sorcery+Caching |
| 16:09.50 | seanbright | i really don't want them cached |
| 16:10.10 | seanbright | but i will give your & corey's suggestion about the endpoint destructor |
| 16:10.17 | seanbright | ... a shot |
| 16:10.37 | gtjoseph | caching may help even if you set the lifetime really short. |
| 16:13.16 | seanbright | alrighty. will give it a shot. |
| 16:13.44 | coreyfarrell | seanbright: if you run a call as part of your test make sure you wait for timer_b to expire before shutting down, otherwise you'll get a bunch of leaks for objects held by timer_b. |
| 16:29.33 | seanbright | it comes down to this |
| 16:29.43 | seanbright | the persistent_endpoints container holds on to the ast_endpoint |
| 16:29.58 | seanbright | it is only unlinked when the sorcery observer says that it was deleted |
| 16:30.02 | seanbright | that will never happen |
| 16:31.37 | gtjoseph | the cache _may_ help with that but you'd have to try it. |
| 16:31.50 | seanbright | it doesn't |
| 16:32.00 | gtjoseph | ah well |
| 16:32.01 | seanbright | well, let me rephrase |
| 16:32.04 | seanbright | i don't think it will |
| 16:32.08 | gtjoseph | oh |
| 16:32.09 | seanbright | but i will test it to satisfy you |
| 16:32.21 | gtjoseph | try with and without full backend cache |
| 16:35.11 | seanbright | cache expired, persistent endpoint is still there |
| 16:35.18 | gtjoseph | rats |
| 16:35.33 | seanbright | so i'll hack something in with a CLI command |
| 17:12.48 | seanbright | rmudgett: i think you've convinced me that i'm in the wrong line of work |
| 17:13.19 | rmudgett | The IPv6 [] patch? |
| 17:13.31 | seanbright | well, every patch i've ever submitted |
| 17:13.36 | seanbright | but yes, that one too :-) |
| 17:14.26 | rmudgett | How else am I going to know you are serious about a patch? :D |
| 17:14.32 | seanbright | that's a good point |
| 17:15.08 | *** join/#asterisk-dev jkroon (~jkroon@105.12.0.249) |
| 17:16.00 | seanbright | i'll let those more qualified take it over the finish line |
| 17:24.50 | rmudgett | seanbright: Why'd you abandon the websocket patch? |
| 17:47.06 | seanbright | i abandoned them because i have no desire to continue to work on those issues any longer |
| 17:47.32 | seanbright | oh, he's gone |
| 17:47.41 | file | netsplat |
| 17:47.42 | seanbright | well someone can tell him that when he's back :) |
| 17:48.02 | seanbright | freakin' internet |
| 17:48.08 | seanbright | such a fad |
| 17:49.56 | *** join/#asterisk-dev kg6hum (~kg6hum@protovision.org) |
| 18:22.15 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 18:22.15 | *** mode/#asterisk-dev [+o ChanServ] by wilhelm.freenode.net |
| 18:59.40 | *** join/#asterisk-dev kg6hum (~kg6hum@protovision.org) |
| 19:08.18 | *** join/#asterisk-dev Guest16471 (~gtjoseph@unaffiliated/gtj) |
| 19:08.58 | *** mode/#asterisk-dev [+o Guest16471] by ChanServ |
| 20:12.45 | seanbright | anyone else see this when using git review: |
| 20:12.46 | seanbright | Pushing to refs/publish/* is deprecated, use refs/for/* instead |
| 20:13.53 | file | yes |
| 20:13.57 | file | don't worry about it |
| 20:13.59 | seanbright | k |
| 20:14.02 | seanbright | i am not worried |
| 20:14.04 | seanbright | you're worried |
| 20:14.10 | file | it's because Gerrit changed things, but the git-review tool hasn't been updated |
| 20:25.23 | seanbright | let's go back to reviewboard |
| 20:46.56 | *** join/#asterisk-dev mjordan_ (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 20:46.56 | *** mode/#asterisk-dev [+o mjordan_] by ChanServ |
| 21:03.11 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-advylfdyhgoslzkn) |
| 21:03.11 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 21:04.32 | rmudgett | And I'm back. IRC seems to have put me into a penalty box for awhile. Something about spamming. Not sure how that happened. |
| 21:09.15 | seanbright | i have some ideas... |
| 21:11.18 | file | it could be bunnies |
| 21:30.48 | seanbright | hmmm, some unnecessary whitespace changes in dundi-parser.c... |
| 22:51.29 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-prejbtwdurqdxzdl) |
| 23:03.35 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 23:03.35 | *** mode/#asterisk-dev [+o ChanServ] by wilhelm.freenode.net |
| 23:37.19 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 23:37.19 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |