geejay wrote:
Zilch, nada, nitchevo. Apparently the query never hits the server
Is the SQL server idle, apart from the A2B queries? What are connection_limit and log-error set to in my.cnf? Have you verified no connection is attempted using tcpdump or some other sniffer?
Quote:
The queries run just fine.
Query logging as suggested is only partially helpful...
That's what you suggested, so that's what I implemented. As you say the logged queries run fine (excepting the timestamps) when resubmitted to MySQL, this really does start to point the finger of blame. How about rather than merely logging the failed query, if it persisted in submitting it twice per second until MySQL actions it properly or until 10 attempts have been made:
Code:
# retry failed INSERTs up to 10 times at 2Hz
$query_try = 2;
while ($query_try<=10 and $result === FALSE) {
usleep(500000);
$result = $A2B->instance_table -> SQLExec ($A2B -> DBHandle, $QUERY, 0);
$A2B -> debug( VERBOSE | WRITELOG, $agi, __FILE__, __LINE__, "[CC_asterisk_stop 1.1: SQL: DONE : query_try=".$query_try++." :result=".$result."]");
}
Quote:
BTW: The whole issue illustrates that one should ideally have some other switch which also rates the calls in parallel. Without it we would never have picked up that A2Billing leaked these calls.
Yes, I couldn't agree more. It's always reassuring to have something against which to reconcile your figures before receiving the bill from your carrier, whether you're using GPL software or commercial. Asiby has been working on a billing daemon for A2B, hopefully to be seen in v1.4 one day, which should prevent any lost CDRs even if Asterisk crashes. Xrg has done some fine work on v200 where all the billing is handled by the SQL server itself, again having the side effect that a CDR can't be lost entirely.
xrg wrote:
they keep being a hugely complicated layer between the hardware and what you intend to run on it.
If you're referring to VMWare or Xen or indeed most virtualisation techniques then yes you're quite correct. However in my experiences with OpenVZ and especially Linux-VServer the overheads are very minimal indeed: one kernel, one process list, one scheduler, just multiple kernel namespaces to load differing user space OSs into. They're more akin to BSD jails than virtual machines. Consult
the latest VServer kernel patch. I suck at C and I've no kernel experience, but I have no problem reading that patch. It all looks very straightforward. It would be half the size if it didn't also implement COW hard-links for every in-kernel filesystem.