| 01:59.39 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 02:21.16 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:5c83:d394:5190:d43a) |
| 02:21.16 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 03:00.45 | *** join/#asterisk-dev joshelson (~joshelson@wsip-72-214-229-210.ph.ph.cox.net) |
| 05:09.44 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 06:14.25 | *** join/#asterisk-dev joshelson (~joshelson@wsip-72-214-229-210.ph.ph.cox.net) |
| 06:41.15 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:41.15 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 06:50.19 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:50.19 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:04.53 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:04.53 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:17.30 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 07:33.11 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 08:23.50 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 09:04.54 | *** join/#asterisk-dev oej (~oej@host-95-195-197-75.mobileonline.telia.com) |
| 09:04.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:27.14 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 12:36.53 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 12:56.19 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 12:56.19 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 12:58.46 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-xjevkjblsabsmskk) |
| 12:58.46 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:19.34 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 13:19.41 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 13:28.33 | *** join/#asterisk-dev jkroon_ (~jkroon@165.16.204.41) |
| 13:34.44 | *** join/#asterisk-dev newtonr (newtonr@nat/digium/x-zqdoysldawnwlpkd) |
| 13:34.45 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:38.13 | *** join/#asterisk-dev jkroon_ (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 13:41.34 | *** join/#asterisk-dev jkroon__ (~jkroon@165.16.204.41) |
| 13:52.03 | *** join/#asterisk-dev jkroon__ (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 13:57.22 | *** join/#asterisk-dev zerohalo (~zerohalo@c-73-123-44-170.hsd1.ma.comcast.net) |
| 14:04.23 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-omlfswdcrwdcrssl) |
| 14:04.40 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:08.07 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 14:08.07 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:24.46 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-stcmsrjrqijiiwhn) |
| 14:24.46 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:41.14 | file | seanbright: if that doesn't break the release script for some reason I'll be uber-surprised |
| 14:41.21 | seanbright | heh |
| 14:41.34 | seanbright | it can't handle utf-8? so lamesies |
| 14:41.47 | seanbright | what is the litmus test as to what gets merged to 15.0? |
| 14:41.50 | file | it can handle it better than it did before |
| 14:42.04 | file | any regressions found as a result of 15 testing goes into 15.0 |
| 14:42.08 | seanbright | gotcha |
| 14:42.11 | file | fixes, that is |
| 14:42.14 | seanbright | right |
| 14:42.14 | file | not placing new regressions in |
| 14:42.18 | seanbright | got it |
| 15:15.26 | *** join/#asterisk-dev ggo (~quassel@37.19.10.33) |
| 15:18.57 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 15:29.20 | bford | gtjoseph_: for the issue you're working on, when is it crashing? when joining the confbridge or at registration? i saw a confbridge exec in the backtrace |
| 15:29.59 | gtjoseph_ | confbridge. file thinks it's not the same crash so i'll work it separately. |
| 15:30.32 | file | bford: for the topology - if it's audio or video and the result is such that there are no compatible formats... I think it can be skipped |
| 15:32.45 | bford | file: that's actually where the crash is happening (on my issue), it checks for compatible formats and crashes because the format passed in is null, if i understand you right |
| 15:34.00 | bford | unless you mean the bridge topology and when the formats for that is being constructed |
| 15:35.59 | file | right right |
| 15:36.41 | file | so two questions: 1. Is it bridge_softmix who is making that NULL? 2. What is the state of the stream? |
| 15:40.01 | bford | figuring out why it is NULL was my next step :) as for state of stream, I'm unsure, I was looking at ast_sip_session_refresh when I realized that the endpoints without video capabilities had video streams with the NULL formats |
| 15:40.38 | file | yeah, I'm intrigued why they'd be NULL there... I can see them being non-NULL... but NULL is odd |
| 15:40.56 | file | unless the stream is removed, then it'd be okay |
| 15:43.09 | bford | yeah, it's strange - is set_caps what handles those stream formats? i was looking at that as well, and i could see that both streams on channel were audio streams, neither NULL, i never saw a video stream being passed into that function |
| 15:44.02 | file | set_caps is for when negotiation is/has occurred |
| 15:44.34 | file | in this case that hasn't happened yet, as bridge_softmix is asking the PJSIP channel to renegotiate to do that |
| 15:45.24 | file | huh, delayed |
| 15:45.40 | ggo | Hi! |
| 15:45.44 | ggo | I have a question about pjsip. I'm on asterisk 13 and I have folowing scenario: |
| 15:46.12 | ggo | A party sends an INVITE to ast, ast sends the invite to the B party. The B party then sends an 100, 180 and then a BYE message. Problem is that the BYE might get processed before the 100 and the 180 messages. This means that there is no dialog when the BYE is processed and pjsip sends a 481 Call/Transaction Does Not Exist. |
| 15:46.19 | ggo | Is this a bug? Any chance I can somehow delay this untill the 100 and 180 are processed? |
| 15:47.21 | file | bford: I think keep on that path - if the stream state is removed then a NULL formats should be okay and the code should handle it, if the stream state is not that... then yeah, need to figure out what the heck made it NULL... |
| 15:48.26 | bford | gotcha, I'll look into it |
| 15:49.17 | file | ggo: er - a BYE before the INVITE is accepted? |
| 15:49.28 | file | that is, before that transaction is completed |
| 15:50.27 | bford | also, on a side note, why does max_video_streams default to 1? are there scenarios where it would make sense to have that at a value other than 0 when things like webrtc aren't enabled? i'm kinda curious about that |
| 15:50.57 | file | bford: non-WebRTC video phones, it mirrors previous behavior |
| 15:51.18 | bford | gotcha, thanks |
| 15:55.09 | ggo | file: Thanks for responding! What do you mean by INVITE is accepted? When does asterisk considers an INVITE accepted? sipp sends the by after the 100 and 180. Somehow the order is not the same when the messges are processed and the BYE get treated first |
| 15:55.35 | file | ggo: is the called party sending the BYE after it sends the 100 and 180? |
| 15:55.46 | gtjoseph_ | sipp sends a bye whenever the scenario ends whether it's a valid time ot send the bye or not |
| 15:55.50 | file | if so, I believe that's against RFC |
| 15:56.21 | gtjoseph_ | you should use the -nd option to sipp to prevent the extra bye at the end |
| 15:56.51 | ggo | file: yes |
| 15:57.05 | file | yeah, that's against RFC, which is why it doesn't work |
| 15:58.37 | ggo | gtjoseph The BYE is not generated by sipp. It's the scenario sending it |
| 15:58.37 | *** join/#asterisk-dev dakudos (~dakudos@c-73-153-12-13.hsd1.co.comcast.net) |
| 15:58.55 | gtjoseph_ | ok, just checking |
| 15:59.37 | file | https://www.irccloud.com/pastebin/D970maNV/ |
| 15:59.44 | ggo | file: This sometimes works... if it's againt the RFC that it should never work, right? |
| 15:59.51 | file | depends on how tolerant PJSIP is |
| 16:00.17 | file | and I can't guarantee proper ordering on it, it's not a scenario that has been tested or confirmed |
| 16:00.26 | bford | stream state is removed :) |
| 16:01.20 | file | bford: k so making it tolerant of no formats when stream state is removed is good(tm) |
| 16:01.26 | file | bford: but can you also determine why it is removed? |
| 16:02.21 | bford | I can look into that now! |
| 16:02.30 | ggo | Thanks you for your answers |
| 16:51.40 | *** join/#asterisk-dev joshelson (~joshelson@wsip-72-214-229-210.ph.ph.cox.net) |
| 16:52.05 | *** join/#asterisk-dev dakudos (~dakudos@c-73-153-12-13.hsd1.co.comcast.net) |
| 17:06.13 | *** join/#asterisk-dev joshelson (~joshelson@198.232.219.254) |
| 17:06.48 | *** join/#asterisk-dev joshelson (~joshelson@198.232.219.254) |
| 17:16.12 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@24-177-86-98.dhcp.nwtn.ct.charter.com) |
| 17:16.12 | *** mode/#asterisk-dev [+o coreyfarrell] by ChanServ |
| 17:33.45 | tm1000 | is there a flag I am missing to turn on blindtransfer and attendedtransfer events? |
| 17:45.39 | tm1000 | nevermind |
| 18:02.42 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-vuouddagfskggpmq) |
| 18:02.42 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 18:07.05 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00d45129efddb00890.ipv6.abo.wanadoo.fr) |
| 18:28.41 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 18:43.04 | *** join/#asterisk-dev acidfoo-_ (~nbouliane@modemcable002.114-70-69.static.videotron.ca) |
| 18:43.28 | gtjoseph_ | Information leakage question... What are the prevailing opinions on returning detailed information in SIP error responses vs just returning say a 404. The specific case I'm looking at is if someone sends asterisk a request with a uri scheme we don't support in the from/to/contact headers, what should asterisk return? |
| 18:46.14 | acidfoo-_ | I'm trying to find where in chan_sip.c (Asterisk 11) the state of the channel is set to AST_STATE_UP when an outgoing call made is answered, I do not seep to find it , or I might find it and doesn't realize it :) I'm looking for the place where a 200 OK is received and the state is updated ast_setstate(c, AST_STATE_UP);... maybe I should look for something else :| |
| 18:46.57 | acidfoo-_ | in sip_answer() the state is updated, but it seems it's for the case were we answer an incoming call |
| 18:50.12 | file | gtjoseph_: I vaguely recall there being a response for that |
| 18:50.25 | gtjoseph_ | there are several possible |
| 18:50.34 | file | I don't think that really leaks any info though |
| 18:51.01 | gtjoseph_ | 606 Not Acceptable is defined partly as "addressing scheme not acceptable" |
| 18:51.33 | file | I think having a more specific response if one exists is fine, I'll put it that way :P |
| 18:52.17 | gtjoseph_ | so you're taking the rfc "MAY" position??? |
| 18:52.51 | file | MAYBe |
| 18:54.53 | file | acidfoo-_: it happens in handle_response_invite, an answer frame is queued and then in the core when reading the frame the channel state is changed |
| 18:55.12 | acidfoo-_ | awesome thanks, I'll follow that ! |
| 18:57.40 | gtjoseph_ | heh... "416 Unsupported URI Scheme". i forgot about that one. |
| 18:57.59 | file | also an area code of Toronto |
| 20:14.23 | joshelson | So just to revisit this distributor issue again... seeing lots and lots of lockups with the pjsip/distributor queues backing up. Any thoughts on a good way to troubleshoot this? |
| 20:14.35 | joshelson | Latest version Asterisk 14 |
| 20:15.18 | gtjoseph_ | i'd start with a detailed look at what's going on on the system at the time. |
| 20:15.33 | gtjoseph_ | even if it's just to rule out cpu and memory constraints |
| 20:15.50 | file | and define lockups |
| 20:16.00 | gtjoseph_ | what's the thread pool set to in pjsip.conf? |
| 20:16.08 | joshelson | Lockup for me means the PJSIP stack stops processing all invites and registrations |
| 20:16.12 | joshelson | Thread pool is default sizez |
| 20:16.36 | gtjoseph_ | but then continues after a certain period of time right? |
| 20:16.51 | joshelson | Well... so we have production traffic dying, so it usually gets restarted |
| 20:16.58 | joshelson | So, not 100% sure on that |
| 20:17.24 | gtjoseph_ | ok. well another quick test would to be to determine if the requests are dropped or if the responses are just delayed. |
| 20:18.28 | joshelson | OK.. so when we get into this state, all the distributor taskprocessors just accumulate in queue tasks.. they don't ever seem to release themselves |
| 20:18.41 | gtjoseph_ | https://wiki.asterisk.org/wiki/display/AST/Performance+Tuning |
| 20:19.22 | file | you can also get a backtrace at the time https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace#GettingaBacktrace-GettingInformationForADeadlock which can show what everything is doing, DEBUG_THREADS isn't needed |
| 20:19.24 | gtjoseph_ | it'd help to kinow if they ever free |
| 20:19.48 | gtjoseph_ | that was going to be my next link :) |
| 20:19.57 | joshelson | Yep.... I think we might have one of those |
| 20:20.35 | gtjoseph_ | Was DONT_OPTIMIZE and BETTER_BACKTRACES enabled? |
| 20:21.25 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-170.cust.bezeqint.net) |
| 20:21.25 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:22.37 | joshelson | Yes |
| 20:22.41 | joshelson | We run everywhere with that |
| 20:22.44 | joshelson | Just had cdr lock up again |
| 20:22.51 | joshelson | with it over queue |
| 20:22.55 | joshelson | Let me grab |
| 20:23.19 | file | are you using a database at all? |
| 20:23.22 | seanbright | yes |
| 20:23.24 | seanbright | he is |
| 20:23.27 | joshelson | Yeah |
| 20:23.28 | seanbright | we did this yesterday |
| 20:23.34 | seanbright | COME ON FILE |
| 20:23.41 | file | seanbright: I'M INVOLVED IN A LOT OF THINGS |
| 20:23.45 | seanbright | heh |
| 20:23.54 | seanbright | and i'm just sitting here doing NOTHING |
| 20:23.56 | file | database performance will impact Asterisk performance |
| 20:24.08 | seanbright | his databases aren't doing shit |
| 20:24.14 | seanbright | beefy machine - low load |
| 20:24.23 | file | just sayin' |
| 20:24.25 | joshelson | Hahah. Same story as everyone, I'm sure. :) |
| 20:25.47 | gtjoseph_ | Well, it'll be easier to troubleshoot CDRs than SIP. |
| 20:26.24 | gtjoseph_ | what database tech? |
| 20:26.50 | joshelson | mariadb, it appears |
| 20:27.47 | gtjoseph_ | via odbc or the highly unsupported cdr_mysql? |
| 20:28.45 | joshelson | ODBC |
| 20:28.47 | joshelson | https://pastebin.com/3zuBwg93 |
| 20:28.50 | joshelson | This is the CDR backup |
| 20:28.59 | joshelson | This appears to be one of two different issues we're dealing. |
| 20:29.01 | joshelson | *with |
| 20:29.16 | joshelson | We make heavy use of adaptive_cdr as well. |
| 20:29.50 | joshelson | CDR backup = backtrace "lockup", rather |
| 20:30.06 | gtjoseph_ | it may be 2 issues, or cdr causing sip to back up. |
| 20:31.28 | joshelson | Yeah.. I have two different cluster nodes here. One seems to more or less always lock on the cdr... the other has been the distributor, when I've looked at it. |
| 20:31.48 | gtjoseph_ | do they both write cdrs to the same database? |
| 20:32.56 | joshelson | So we use a asynchronous geo-distributed Maria cluster replicated by tungsten... so the data does end up in both places, but the nodes are different. |
| 20:34.39 | jameswf | weird I heart the rcp thing was so easy a Lawyer could do it ¯\_(ã)_/¯ |
| 20:34.44 | jameswf | runs away |
| 20:35.20 | jameswf | jokes fall on their face when there is atypo |
| 20:35.26 | joshelson | :)) |
| 20:35.33 | jameswf | feels ashamed |
| 20:35.58 | joshelson | We generally write to a node very close to the Asterisk boxes... and then tungsten picks the CDRs up and replicates them around the environment |
| 20:37.32 | joshelson | It just operates on the binary logs at some point in time.. the write are generally completed very quickly. |
| 20:39.41 | gtjoseph_ | look at thread 68 |
| 20:41.27 | gtjoseph_ | we're trying to detemine if the connection is dead but it's waiting on something deep down in mysql. |
| 20:41.50 | seanbright | must be looking at the wrong backtrace |
| 20:41.58 | gtjoseph_ | it's holding class->lock though so nothing else is going to proceeed while we're waiting on mysql to respond |
| 20:42.35 | seanbright | gtjoseph_: you're looking at https://pastebin.com/3zuBwg93 |
| 20:42.36 | seanbright | ? |
| 20:42.41 | gtjoseph_ | i'm looking at the pastebin from above |
| 20:42.47 | gtjoseph_ | yep |
| 20:42.56 | seanbright | thread 68 is a threadpool thread |
| 20:43.02 | seanbright | an idle one |
| 20:43.03 | gtjoseph_ | ew, 88 not 68, sorry |
| 20:43.20 | gtjoseph_ | i'm due for my nap |
| 20:44.00 | gtjoseph_ | frame 12 is our connection_dead function |
| 20:44.47 | gtjoseph_ | frame 11 starts ODBC SQLGetConnectAttr |
| 20:45.40 | seanbright | what is FC_CDR_UPDATE_EXTENSION()? |
| 20:45.56 | joshelson | Custom func_odbc we use |
| 20:46.12 | joshelson | Runs in a hangup handler, I believe |
| 20:46.24 | seanbright | looks that way, yes. |
| 20:47.57 | seanbright | gtjoseph_: what are you seeing indicating that connection_dead is holding things up? |
| 20:49.09 | gtjoseph_ | well, at the exact time this dump was generated, that's where thread 88 was. connection_dead is called by _ast_odbc_request_obj2 while holding class->lock |
| 20:49.28 | gtjoseph_ | the other threads are waiting on some class->lock but it's hard to tell if it's the same one |
| 20:50.04 | gtjoseph_ | oh, yes it is |
| 20:50.12 | gtjoseph_ | thread 62 is waiting on it |
| 20:50.26 | gtjoseph_ | and thread 15 |
| 20:51.30 | seanbright | god... realtime is a fucking disaster |
| 20:52.26 | gtjoseph_ | orly? :) |
| 20:53.06 | gtjoseph_ | it it was a cake it'd be delicious. it so many layers. |
| 20:54.15 | joshelson | If you've got an alternative.... would love to know. :) Between 11 and 14, I have 25k endpoints in RT. |
| 20:54.28 | file | seanbright: we do have connection pooling... |
| 21:04.31 | seanbright | file: blech |
| 21:04.46 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 21:04.46 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 21:05.16 | seanbright | joshelson: generate static config and reload |
| 21:06.27 | joshelson | seanbright: Haha. Oh I wish. That'd be a full rearchitect now. Has anyone done 25k peers non-realtime? |
| 21:07.08 | gtjoseph_ | all in memory? probably be pretty quick |
| 21:07.29 | gtjoseph_ | just hard to manage |
| 21:07.32 | file | the swap is atomic, usage isn't held off while parsing/creating/etc |
| 21:08.15 | joshelson | Yeah... we had issues way back in the 1.6/1.8 era with dropping traffic during reloads. Our dialplan was 5 or 6 mb. And we do tons of add/subtract/update of peers daily. |
| 21:08.49 | joshelson | gtjoseph_ any thoughts for things we could try there? |
| 21:08.52 | gtjoseph_ | you could also use ari to create your objects :) |
| 21:09.00 | gtjoseph_ | well, |
| 21:09.05 | joshelson | This is the goal eventually :) |
| 21:09.24 | seanbright | do you really need the queue_log? |
| 21:09.27 | gtjoseph_ | i'm still thinking that something's holding up the cdrs |
| 21:09.36 | gtjoseph_ | are you using the odbc connection pooling? |
| 21:09.57 | seanbright | i need a job at fluentstream |
| 21:09.59 | seanbright | do you do remote? |
| 21:10.38 | seanbright | salary requirements are meager. i only need $225k/yr |
| 21:10.48 | joshelson | Hahah. I wish ;) |
| 21:10.55 | joshelson | pre-connect => yes |
| 21:10.55 | joshelson | sanitysql => select 1 |
| 21:10.55 | joshelson | connect_timeout => 2 |
| 21:10.57 | joshelson | max_connections => 20 |
| 21:10.59 | joshelson | forcecommit => no |
| 21:11.01 | joshelson | isolation => read_committed |
| 21:11.08 | joshelson | These are our settings for the CDR DB |
| 21:12.53 | gtjoseph_ | "odbs show all" |
| 21:12.57 | gtjoseph_ | odbc |
| 21:13.44 | joshelson | <PROTECTED> |
| 21:13.55 | joshelson | This is on a box after reset, unfortunately |
| 21:14.33 | gtjoseph_ | yeah, so what does that dialplan function do? that's what was holding up the other 2 cdr writes |
| 21:15.10 | joshelson | It makes an unfortunate legacy linkage between cdr and queue_log |
| 21:15.26 | gtjoseph_ | i have just one word for you... |
| 21:15.29 | gtjoseph_ | ew |
| 21:16.20 | gtjoseph_ | would it be possible to disable that in the hangup handler and post process it for a time as a test? |
| 21:16.25 | joshelson | It's not great... on the list to remove. But the lookup is indexed and generally runs pretty quickly. |
| 21:16.29 | joshelson | Yeah... we can probably make that happen |
| 21:17.12 | gtjoseph_ | that'd be great and if it does happen again, getting another coredump at the time would be great |
| 21:17.24 | joshelson | OK... we can do that |
| 21:18.10 | gtjoseph_ | does it attempt to update that channel's cdr? |
| 21:18.32 | joshelson | It's either its own, or in some cases a predecessor channel |
| 21:18.45 | joshelson | Depends a bit on the flow |
| 21:19.04 | gtjoseph_ | hmmm. that could be tricky in a hangup handler |
| 21:19.27 | gtjoseph_ | let's see what doing that outside asterisk does. |
| 21:20.05 | joshelson | Cool. We'll do that and report back. |
| 21:20.34 | joshelson | I *think* this is a separate issue from the distributor itself locking up... :) But we can track down this one first and see. |
| 21:21.22 | gtjoseph_ | cool. they could still be related. dont forget that if the cdr taskprocessor overloads, new incoming requests get discarded |
| 21:21.55 | gtjoseph_ | as a separate line of inquiry, you could look at increasing the pjsip thread pool. |
| 21:24.10 | joshelson | So do they get discarded or do they queue in other queues? |
| 21:24.28 | joshelson | We will definitely optimize the threadpool as well... we are running totally stock |
| 21:26.20 | gtjoseph_ | discarded. we don't even respond to the client. |
| 21:26.30 | gtjoseph_ | we let them retransmit if they wish |
| 21:30.04 | joshelson | Hmm.. yeah. So we may have a separate issue of some sort then. I had another node that has nothing in queue anywhere (including cdr_engine) - but all of the distributor nodes have hundreds of messages in them, though they were not over the high water mark. No invite or registers were being processed. |
| 21:37.59 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 22:39.02 | *** join/#asterisk-dev joshelson (~joshelson@198.232.219.254) |
| 22:52.15 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:6daf:9004:80bc:7f0e) |
| 22:52.15 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 22:56.52 | joshelson | gtjoseph_: Got a backtrace on the system with the distributor lock. Was quite large so opened as: https://issues.asterisk.org/jira/browse/ASTERISK-27268 |
| 22:57.13 | gtjoseph_ | ok, i'll look in a bit |
| 22:57.40 | joshelson | You're awesome... thanks so much |
| 23:08.43 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-omlfswdcrwdcrssl) |
| 23:23.59 | *** join/#asterisk-dev joshelson (~joshelson@198.232.219.254) |
| 23:31.22 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:7944:1a56:9fd0:4168) |
| 23:31.22 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 23:55.01 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:648e:d576:6750:6874) |
| 23:55.01 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |