[Asterisk-Dev] Unlocking the unlocked...

[mattf]

Hello,

Happens to us every day for the last year and a half. It's a hard disk
read/write speed issue for the recordings. We've keep our recording drives
on separate physical disks from everything else and we try to keep that
partition as defragged as possible and that does help reduce the
channel_walk_locked warnings and the associated periodic recording audio
skips.

I'm very interested in your experience with changing the number of retries
and your results as we have not tried that yet. 

What audio format do you record in(wav or gsm)?
What do you usually change the number of retries to and how are the results?

If this can help significantly, maybe a config variable in features.conf
would be in order?

Thanks,

MATT---

-----Original Message-----
From: Guillermo Winkler [mailto:gwinkler at inconcertcc.com]
Sent: Tuesday, June 28, 2005 6:13 PM
To: asterisk-dev at lists.digium.com
Subject: [Asterisk-Dev] Unlocking the unlocked...


Hi,
    Under the following scenario:

6000 outgoing calls/hour(SIP-->ZAP)
75% connected (25% is busy or no answer)
100% of connected calls beign recorded, when LINK event occurs.
P4 2.8 HT.
Krnl 2.4.21

We are having some "Avoid deadlock" issues(This is not happening without 
recording)

As you can see in channel_walk_locked

if (retries < 10)
     ast_log(LOG_DEBUG, "Avoiding initial deadlock for '%s'\n", l->name);
    else
     ast_log(LOG_WARNING, "Avoided initial deadlock for '%s', %d 
retries!\n", l->name, retries);
    ast_mutex_unlock(&chlock);

Ten 1ms retries are done to avoid deadlocks. But when recording is enabled, 
the channel gets locked on start:
 if (ast_monitor_start(c, format, fname, 1)) {
  if (ast_monitor_change_fname(c, fname, 1)) {

Those ten retries are not enough in that case, using lock instead of 
try_lock, or increasing the number of retries, solves the problem 
temporarily.

I wanted to know if someone else is experimenting something similar?

I think ast_channel_walk_locked and ast_get_channel_by_name_locked could be 
rewritten or a new set of functions be added , faster and more reliable (now

you don't know if the channel you're looking for is not there at all or a 
deadlock(not so dead) issue on ANOTHER channel was the failure).

If you feel the same I would be glad to help.

Regards,
Guillermo




_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev