We store transports in realtime. Outsourcing the transport to .conf should be possible to test. I can't tell how reproducible this issue is since it depends on load factors. It has to be mentioned that some heavy webrtc load days everything was fine but we got the Error "Unknown Error (PJ_EUNKNOWN)" on its maximum load peeks. This error also occurred just before it started to freeze some other day.
On 2/5/21 4:08 PM, Joshua C. Colp wrote: > On Fri, Feb 5, 2021 at 11:05 AM Silvan Nagl <m...@53c70r.de > <mailto:m...@53c70r.de>> wrote: > > Hi, > > on larger webrtc setup we noticed that Asterisk 16.13.0 will start to > (deadlock)? > Asterisk keeps running without crashing but will not response to any new > connections. > Full logs attached. > > It seams like 91 threads are in state "__lll_lock_wait" the mutex of > these point to thread 80 which does the webrtc stuff. > For some reason thread 80 gets a "get_write_timeout" which now starts to > destroy the transports while the other 91 threads still have a lock on > thread 80. Thread 80 has no other mutex locks. > > The strace does not belong to the core dump. > > We will test against 16.16 soon. > > > Are you storing transports in realtime? If so and you switch to using > .conf file, does the issue resolve itself? > > -- > Joshua C. Colp > Asterisk Technical Lead > Sangoma Technologies > Check us out at www.sangoma.com > <http://www.sangoma.com/> and www.asterisk.org <http://www.asterisk.org/> >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
