provided by Star2Billing S.L.

I have now patched Class.A2Billing.php (BTW: I suggest to make the patch a standard a2billing feature, as otherwise such database errors will never be caught)



After applying the patch I see now errors like the following:

Sep 19 18:01:51 online php: /var/lib/asterisk/agi-bin/libs_a2billing/adodb/adodb-errorhandler.inc.ph
p[77]: mysql error: [2006: MySQL server has gone away] in EXECUTE("UPDATE cc_card SET inuse=inuse-1
WHERE username='584543545'")

This points to the following issue
http://bugs.mysql.com/bug.php?id=28359

I have now increased connect_timeout on the mysql server from 5 to 15 seconds.

Fingers crossed.

Geejay

I got a bit closer to the cause of the problem.

I have compared agi log files, showing adodb errors "mysql server has gone away", and dumped at the same time all traffic sent to the mysql server.

Apparently those INSERT and UPDATE queries which show up as errors are never sent out to the database server, they are missing in the dump !

I note that at the time when these queries are sent other "EXPLAIN SELECT" queries from the web interface are going through. (BTW: why does the webinterface generate "EXPLAIN SELECT" queries?)

Is it possible that there is some concurrency problem here? That the adodb library or the mysql client libraries block inserts and updates while doing selects ?

Any other ideas on whats up here ?

This one is driving me slowly nuts.

Thanks for any input any of you may have.

Geejay

A quick grep of the A2B source leads me to believe that it doesn't, or at least nothing outside of the ADODB library itself mentions EXPLAIN or Explain(). Are you sure these EXPLAINs are coming from A2B?
Yes, but ADODB isn't where the problem lies. There's a little discussion of MySQL's lock contention in this thread.

The new Falcon storage engine in MySQL 6 has addressed some of the more heinous concerns, but at the cost of a huge hit in performance on top of the already poor scalability. It seems MySQL is still a toy.

Stavros,

upon closer inspection it appears that every msql query from the webinterface is first sent as a an "EXPLAIN ...... " statement and then the real query is sent, (I can see "EXPLAIN" commands only in the adodb interface supplied with a2billing e.g.:


Some of these EXPLAIN queries return quite big bunches of data.

EXPLAIN statements only appear in adodb/perf directory libraries of adodb. "Library for basic performance monitoring and tuning"

I cant believe that I am the first who is stumbling upon this.

Geejay

This needs to be quickly addressed.

It's the first time I've seen it reported.
Is it possible that in your quest to find the root of the problem you have turned up the default debug levels for parts of A2B and/or ADODB which may be triggering the EXPLAINs?

"Is it possible that in your quest to find the root of the problem you have turned up the default debug levels for parts of A2B and/or ADODB which may be triggering the EXPLAINs?"

Sure its possible, but I would not know where to enable this. Perhaps someone else can do an



on his a2billing installation and then do some queries on the webinterface, to check whether these EXPLAIN queries are switched on by default ?

BTW - are the following errors normal, they appear always before cdr INSERTs, those that work and those that dont. this is A2Billing 1.3.2, Asterisk 1.4 running with DeadAGI, yes I have read the other threads relating to this error but it didnt make me any smarter. As far as I can tell this error does not influence things, as most cdrs are inserted dispite this error:



Geejay

tcpdump shows me that on Postgres with A2B v1.3.3 with default settings there are no EXPLAINs at all when viewing the customer list and the CDRs.

There was a significant amount of tidying of the code between the v1.3.2 and v1.3.3 releases. If you receive these warnings from v1.3.3 please let us know.

Looking through the logs I notice that only calls with long durations (over 300 seconds) get lost, do not get inserted into the database.

Upon checking the msql configuration I notice that I set a wait timeout of 300 seconds, to ensure that unused connections do not hang around too long.

Is it possible that mya2billing opens the connection to the database when the call is started and closes the connection when the call is stopped ??

If so, that would explain why only long calls get lost, (as the database connection times out)

Given the distribution of long and short calls it cannot be accidental that only long duration calls are lost.

Geejay

The problem appears to be solved. I increased the wait_timout in mysql to longer than the longest possible call length.

I have not checked the A2Billing code but I conclude that the database connection is kept open for the entire call length.

If this is indeed so, then perhaps the database handling in A2Billing should be looked over. IMVHO A2Billing should not make any assumptions about database server configurations.

I cannot see any need for keeping the database connection open during the call as nothing is happening during a call.

Cheers and thanks for all the input.

Geejay

[[CC_asterisk_stop 1.1: SQL: DONE : result=]]

Touching all timeout settings in my.cnf, and still cannot resolve it.
Any clues ?

Yes, this is a very nasty issue. The problem can be caused by the A2billing side and on the mysql side at various places.

The hint for me were the missing CDR call lengths

Try


and see whether you find some specific failure pattern in the missing CDRs.

Geejay

Did you try A2B 1.3.3 as stavros suggest?

After tweaking a little the mysql config file my.cnf, the problem seems to have dissapeared.
I left the timeout options commented, this is my.cnf portion that was tweaked :

# * Fine Tuning
#
max_connections = 400
key_buffer = 512M
myisam_sort_buffer_size = 64M
join_buffer_size = 2M
read_buffer_size = 4M
sort_buffer_size = 4M
table_cache = 1024
thread_cache_size = 286
#interactive_timeout = 25
#wait_timeout = 11800
#connect_timeout = 60
max_allowed_packet = 16M
max_connect_errors = 10
query_cache_limit = 1M
query_cache_size = 128M
query_cache_type = 1
tmp_table_size = 16M

Hi to all,

I did not know where to put this, and because my problem has similar issue, I am putting this here.

The problem is this: When I have customer that is on postpay, who has two simultaneous conversations on the same account, the first call does not get billed for the whole time while it lasts. For example, if first talks starts at 12:00, second call starts at 12:01, then the first call is only billed as it lasts for example 2, or 2.5 min. (12:02), but when I see detailed asterisk log, then I can see that that call lasted for 60 min ! The second call for example lasts for 58 minutes according to a2billing and asterisk too.
I am using a2billing ver. 1.3.2. asterisk 1.4.10
The attach is the a2billing_agi.log of the example that I described above.

The call listing at my provider says that the first call lasted 60 min, not 2 min. Attached I have my asterisk log

This happened twice, it was at the same customer. He uses linksys pap2t phone adapter with two phones on it, the same account on both sip accounts.

Please help me to solve this issue, I do not know what is wrong here