[asterisk-bugs] [JIRA] (ASTERISK-17069) Callfile retries behave erratically as file size grows
newborn (JIRA)
noreply at issues.asterisk.org
Thu Jul 17 13:41:56 CDT 2014
[ https://issues.asterisk.org/jira/browse/ASTERISK-17069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=220703#comment-220703 ]
newborn commented on ASTERISK-17069:
------------------------------------
Temporary fixed by shorting the callfile name.
> Callfile retries behave erratically as file size grows
> ------------------------------------------------------
>
> 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.6.0, 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 was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list