Summary:	ASTERISK-22787: Call file RetryTime not respected after several retries
Reporter:	Jeremy Kister (jkister)	Labels:
Date Opened:	2013-10-28 18:02:03	Date Closed:	2013-11-13 09:13:20.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	PBX/pbx_spool
Versions:	11.6.0 11.7.0	Frequency of Occurrence	Constant
Related Issues:	duplicates ASTERISK-17069 Callfile retries behave erratically as file size grows
Environment:	Debian 6	Attachments:
Description:	call file retry times are broken possibly because of 'safe_append' function. [Edit by Rusty Newton - adding comment info to description] When the file is larger than 512 bytes, Asterisk gets all confused and retries immediately/randomly instead of at the specified RetryTime. I believe this is because files written in the pbx spool must be done atomically.
Comments:	By: Jeremy Kister (jkister) 2013-10-28 18:09:49.393-0500 to reproduce: {noformat} cat <<__EOC__ > /var/spool/asterisk/tmp/mycall.tmp Channel: Local/9999@extensions Callerid: 1234 MaxRetries: 25 RetryTime: 60 WaitTime: 60 Context: alarm-ack Extension: s Priority: 1 __EOC__ mv /var/spool/asterisk/tmp/mycall.tmp /var/spool/asterisk/outgoing/mycall {noformat} Do not answer the call when it comes in. Instead, use 'ls -l /var/spool/asterisk/outgoing/mycall' after Asterisk stops ringing the extension. Asterisk will use pbx/pbx_spool:safe_append to append to the file (in place).  Let this repeat for a few times.  When the file is larger than 512 bytes, Asterisk gets all confused and retries immediately/randomly instead of at the specified RetryTime. I believe this is because files written in the pbx spool must be done atomically.   By: Rusty Newton (rnewton) 2013-11-12 19:11:03.345-0600 In my test, I had several retries work on time, 60 seconds apart, as in *Nov 12 18:56:39* to *Nov 12 18:57:39*, but then after the file was 1019 bytes the issue did occur with call attempts happening on times of *Nov 12 18:58:39*, then *Nov 12 18:58:44*  and then *Nov 12 18:59:39* and  *Nov 12 18:59:49*. Basically, several were 60 seconds apart, and then they became erratic. For testing I was just using the following dialplan with your callfile example {noformat} [extensions] exten => 9999,1,Wait(5) [alarm-ack] exten => s,1,Dial(SIP/6001) {noformat} Sounds pretty similar to your results. By: Jeremy Kister (jkister) 2013-11-12 19:58:09.049-0600 might want to set this related-to (or possibly duplicates) ASTERISK-17069 which i made three years ago and don't remember very much about.  honestly not sure if it's the same core issue or not. By: Rusty Newton (rnewton) 2013-11-13 09:12:47.760-0600 Yeah, these look similar enough to say it's a duplicate.  I'll close this one out as a duplicate of ASTERISK-17069 By: Jeremy Kister (jkister) 2013-11-13 20:37:32.694-0600 on closer inspection, ASTERISK-17069 seems to be caused by some kind of caching issue because changing the filename fixes the problem.  not sure how important that detail is.