[asterisk-bugs] [JIRA] (ASTERISK-17069) RetryTime in callfiles is confused

[Jeremy Kister (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-17069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=211895#comment-211895 ] 

Jeremy Kister edited comment on ASTERISK-17069 at 11/16/13 10:52 PM:
---------------------------------------------------------------------

another similar/related issue:

{noformat}
cat <<__EOC__ > /var/spool/asterisk/tmp/timetest.tmp
Channel: Local/9999 at extensions
Context: alarm-ack
Extension: s
Priority: 1
__EOC__

touch -cm -t `date --date="5min" +'%Y%m%d%H%S'` /var/spool/asterisk/tmp/timetest.tmp
mv /var/spool/asterisk/tmp/timetest.tmp /var/spool/asterisk/outgoing/timetest
sleep 5
touch -cm -t `date +'%Y%m%d%H%S'` /var/spool/asterisk/outgoing/timetest
{noformat}

I would expect the call to come in rather immediately.  But after Asterisk knows something about the callfile (in this case, to schedule it for 5 min in the future), it doesn't seem to respect changes to the mtime.
                
      was (Author: jkister):
    another similar/related issue:

{noformat}
cat <<__EOC__ > /var/spool/asterisk/tmp/timetest.tmp
Channel: Local/9999 at extensions
Callerid: 1234
MaxRetries: 25
RetryTime: 60
WaitTime: 60
Context: alarm-ack
Extension: s
Priority: 1
__EOC__

touch -cm -t `date --date="5min" +'%Y%m%d%H%S'` /var/spool/asterisk/tmp/timetest.tmp
mv /var/spool/asterisk/tmp/timetest.tmp /var/spool/asterisk/outgoing/timetest
sleep 5
touch -cm -t `date +'%Y%m%d%H%S'` /var/spool/asterisk/outgoing/timetest
{noformat}

I would expect the call to come in rather immediately.  But after Asterisk knows something about the callfile (in this case, to schedule it for 5 min in the future), it doesn't seem to respect changes to the mtime.
                  
> RetryTime in callfiles is confused
> ----------------------------------
>
>                 Key: ASTERISK-17069
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-17069
>             Project: Asterisk
>          Issue Type: Bug
>          Components: PBX/pbx_spool
>    Affects Versions: SVN, 11.7.0, 12.0.0-beta1
>            Reporter: Jeremy Kister
>         Attachments: callfile.txt, extensions.conf, sip.conf
>
>
> if you make a callfile with 
> MaxRetries: 5
> RetryTime: 420
> the pbx does not reschedule the retry in 420 seconds - instead, it is much sooner, sometimes even immediately.
> the call file itself is modified by the pbx:
> Channel: Local/121 at extensions
> Callerid: 121
> MaxRetries: 15
> RetryTime: 420
> WaitTime: 60
> Context: alarm-ack
> Extension: s
> Priority: 1
> StartRetry: 4419 1 (1291569420)
> EndRetry: 4419 1 (1291569037)
> StartRetry: 4419 2 (1291569481)
> EndRetry: 4419 2 (1291569099)
> StartRetry: 4419 3 (1291569840)
> DelayedRetry: 4419 2 (1291569457)
> EndRetry: 4419 3 (1291569457)
> StartRetry: 4419 4 (1291569901)
> but those epochs are actually *in the future*.  for example, the last "StartRetry 1291569901" was printed appended to the file 380 seconds in the future:
> pbx1> perl -e 'print "$^T\n"'
> 1291569521
> ****** ADDITIONAL INFORMATION ******
> it seems the scheduler has some sanity, as 380 seconds into the future + the 60 second WaitTime = 420 = RetryTime.  but something is confusing the clock.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira