You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a dual socket Xeon motherboard on which I'm doing nothing else but running asterisk and php. Despite seemingly abundant resources, my scripts always crash with a read timeout.
I've tried increasing the read timeout threshold a thousand-fold, and it doesn't help. I've inserted a sleep of a quarter second between my queries, and I can't say for sure if there is a change. What helped greatly was not using the AMI whenever possible. Now I do a burst of DBPut/Gets a the beginning of the script, and then only perform additional ones as needed.
Nonetheless, I saw it crash a few seconds after the initial burst when I manually triggered a few more queries, not in rapid succession.
I wrote this little snippet to see if there was anything I could do to keep it running for more than a few minutes while consistently querying:
That does one DBPut and one Get per pass. Messing with this in combination with the steps outlined above failed to yield a stable combination.
Lastly, I tried an OriginateAction almost entirely from the quickstart.php file, and for whatever reason the Originate works, but also crashes the script with another read timeout. The difference here is that it is not intermittent. It happens every time. Here's that code that causes the error:
$originateMsg = new OriginateAction('SIP/1000');
$originateMsg->setContext('concierge');
$originateMsg->setPriority('1');
$originateMsg->setExtension('99');
var_dump($client->send($originateMsg));
And the exception I get is:
PHP Fatal error: Uncaught PAMI\Client\Exception\ClientException: Read timeout in /root/cordmon/vendor/marcelog/pami/src/PAMI/Client/Impl/ClientImpl.php:424
Stack trace:
#0 /root/cordmon/call_handler.php(68): PAMI\Client\Impl\ClientImpl->send(Object(PAMI\Message\Action\OriginateAction)) #1 {main}
thrown in /root/cordmon/vendor/marcelog/pami/src/PAMI/Client/Impl/ClientImpl.php on line 424
Fatal error: Uncaught PAMI\Client\Exception\ClientException: Read timeout in /root/cordmon/vendor/marcelog/pami/src/PAMI/Client/Impl/ClientImpl.php:424
Stack trace:
#0 /root/cordmon/call_handler.php(68): PAMI\Client\Impl\ClientImpl->send(Object(PAMI\Message\Action\OriginateAction)) #1 {main}
thrown in /root/cordmon/vendor/marcelog/pami/src/PAMI/Client/Impl/ClientImpl.php on line 424
Any help is much appreciated.
The text was updated successfully, but these errors were encountered:
I have a dual socket Xeon motherboard on which I'm doing nothing else but running asterisk and php. Despite seemingly abundant resources, my scripts always crash with a read timeout.
I've tried increasing the read timeout threshold a thousand-fold, and it doesn't help. I've inserted a sleep of a quarter second between my queries, and I can't say for sure if there is a change. What helped greatly was not using the AMI whenever possible. Now I do a burst of DBPut/Gets a the beginning of the script, and then only perform additional ones as needed.
Nonetheless, I saw it crash a few seconds after the initial burst when I manually triggered a few more queries, not in rapid succession.
I wrote this little snippet to see if there was anything I could do to keep it running for more than a few minutes while consistently querying:
That does one DBPut and one Get per pass. Messing with this in combination with the steps outlined above failed to yield a stable combination.
Lastly, I tried an OriginateAction almost entirely from the quickstart.php file, and for whatever reason the Originate works, but also crashes the script with another read timeout. The difference here is that it is not intermittent. It happens every time. Here's that code that causes the error:
And the exception I get is:
Any help is much appreciated.
The text was updated successfully, but these errors were encountered: