[asterisk-bugs] [Asterisk 0018544]: [patch] On Darwin, pbx_spool stops looking for work after 20-30 minutes of idle time

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18544 
====================================================================== 
Reported By:                jcovert
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18544
Category:                   PBX/pbx_spool
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.8.1.1 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-12-28 11:57 CST
Last Modified:              2010-12-28 12:59 CST
====================================================================== 
Summary:                    [patch] On Darwin, pbx_spool stops looking for work
after 20-30 minutes of idle time
Description: 
after a while, call files sit unprocessed in the outgoing spool directory.

upon restart, they are processed, and new files are processed for a
while.

this problem seems to be suppressed by having a call file execute once a
minute

core show threads attached, but it doesn't look any different before or
after the failure.
====================================================================== 

---------------------------------------------------------------------- 
 (0130010) tilghman (manager) - 2010-12-28 12:59
 https://issues.asterisk.org/view.php?id=18544#c130010 
---------------------------------------------------------------------- 
See if this patch solves the problem.  From your description, I would think
that the kqueue() API is having trouble with a spectacularly long timeout,
so this patch shortens the timeout to 60 seconds (whereupon it should note
the timeout, then try again). 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-12-28 12:59 tilghman       Note Added: 0130010                          
======================================================================