[asterisk-bugs] [Asterisk 0009042]: DUNDi ignoring incoming replies when system is busy

[noreply at bugs.digium.com]

The following issue has been CLOSED 
====================================================================== 
http://bugs.digium.com/view.php?id=9042 
====================================================================== 
Reported By:                gdhgdh
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   9042
Category:                   PBX/pbx_dundi
Reproducibility:            sometimes
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:            1.2.14  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        No 
Request Review:              
Resolution:                 suspended
Fixed in Version:           
====================================================================== 
Date Submitted:             02-12-2007 05:59 CST
Last Modified:              12-05-2007 09:43 CST
====================================================================== 
Summary:                    DUNDi ignoring incoming replies when system is busy
Description: 
I have two machines, star (10.0.0.239) and hash (10.0.0.235), both with one
E1 telco uplink. star is almost idle, whilst hash is quite busy
(http://bugs.digium.com/view.php?id=14#25 Zap
channels + MixMonitor + 30 SIP clients). I do DUNDi lookups between them to
find an available Zap channel.

Lookups originating from star complete almost instantly ( < 10ms).
Lookups originating from hash may take several seconds or fail completely.
tcpdump shows star is responding to the request immediately, but hash is
not processing the incoming reply. star then retries once per second for up
to 4 seconds before giving up.

I've annotated the tcpdump output (as run on hash!) for completeness:

ENCRYPT + DPDISCOVER request to star:
10:22:58.768384 IP 10.0.0.235.4520 > 10.0.0.239.4520: UDP, length 88

ACK to hash
10:22:58.768773 IP 10.0.0.239.4520 > 10.0.0.235.4520: UDP, length 8

ENCRYPT to hash:
10:22:58.769921 IP 10.0.0.239.4520 > 10.0.0.235.4520: UDP, length 90

ENCRYPT to hash:
10:22:59.769966 IP 10.0.0.239.4520 > 10.0.0.235.4520: UDP, length 90

ENCRYPT to hash:
10:23:00.770025 IP 10.0.0.239.4520 > 10.0.0.235.4520: UDP, length 90

(then finally after 3 seconds) ACK to star:
10:23:01.651028 IP 10.0.0.235.4520 > 10.0.0.239.4520: UDP, length 8
10:23:01.651446 IP 10.0.0.235.4520 > 10.0.0.239.4520: UDP, length 8
10:23:01.651518 IP 10.0.0.235.4520 > 10.0.0.239.4520: UDP, length 8
10:23:01.651593 IP 10.0.0.235.4520 > 10.0.0.239.4520: UDP, length 8
10:23:01.651716 IP 10.0.0.239.4520 > 10.0.0.235.4520: UDP, length 8
10:23:01.651783 IP 10.0.0.239.4520 > 10.0.0.235.4520: UDP, length 8
10:23:01.651808 IP 10.0.0.235.4520 > 10.0.0.239.4520: UDP, length 8
10:23:01.651841 IP 10.0.0.239.4520 > 10.0.0.235.4520: UDP, length 8
10:23:01.651868 IP 10.0.0.235.4520 > 10.0.0.239.4520: UDP, length 8
10:23:01.652041 IP 10.0.0.239.4520 > 10.0.0.235.4520: UDP, length 8
10:23:01.652074 IP 10.0.0.239.4520 > 10.0.0.235.4520: UDP, length 8

The rest are an assortment of ACKs, NULLs, INVALIDs and ENCREJ presumably
as hash is processing the backlog (possibly out of order ?)

The problem is, /why/ is hash waiting so long? Are other asterisk threads
too busy with other work? How can I determine this? I'm using 1.2.14 on
both machines. Load average on hash is typically only 0.2.

On hash, I notice other small indications like typing 'show chan' and
pressing TAB... the commandline may wait for several seconds before
completing 'show channel'.

Neither machine is doing anything exotic like MeetMe, queueing/agents or
IVR. hash is new - an HP DL145 G2 (Opteron 246 with HyperTransport) and is
dedicated to Asterisk. There is a single Sangoma A104 installed.


====================================================================== 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-05-07 09:43  Corydon76      Status                   feedback => closed  
12-05-07 09:43  Corydon76      Resolution               open => suspended   
======================================================================