General Asterisk question.
We are sending CDR's to MySQL via odbc. It seems that Asterisk is sometimes
dropping CDR's, and they aren't being sent to the database (they ARE in
the Master.csv file though). We suspect that when the MySQL socket is idle, it
gets disconnected, either by the MySQL server or by our firewall, and when
Asterisk goes to send the next CDR over the socket, does not re-open the
database, and drops that CDR. Possibly on the next call, it connects ok and
sends the next CDR.
This was a documented problem with voicemail users in the db in some previous
version of Asterisk 1.2, and was patched and fixed in a later version of
Asterisk 1.2
We are using Asterisk 1.2.19.
So... surely this must be a general problem with ANY Asterisk module that uses
the database. Do all modules use the same common database code or do they all
use their own? If they all use their own, I guess idle database connection
issues may be fixed in some modules and not others. If it's common Asterisk
database code, is it all fixed in a newer version? Is it fixed in Asterisk 1.4?
Thanks,
Doug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20080521/9c3cd705/attachment.htm
Douglas Garstang wrote:> We are sending CDR's to MySQL via odbc. It seems that Asterisk is > sometimes dropping CDR's, and they aren't being sent to the database > (they ARE in the Master.csv file though). We suspect that when the MySQL > socket is idle, it gets disconnected, either by the MySQL server or by > our firewall, and when Asterisk goes to send the next CDR over the > socket, does not re-open the database, and drops that CDR. Possibly on > the next call, it connects ok and sends the next CDR.Isn't there a keepalive option somewhere for cdr_mysql.conf, or failing that, a keepalive mechanism that can be enabled for TCP connections on the server side? -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
I had a similar problem, but in my case we had a custom application that was throwing an segmentation exception which was causing Asterisk to Restart. And in that case It use to miss the log in database. You can determine the same by looking at the UNIQUEID being logged for the call. The UNIQUEID actually comprises of 2 things DateTimeString.CallNumber , everytime Asterisk restarts CallNumber will start from 1. So you can check the 2-3 UNIQUEID before you missed entry in CDR table and 2-3 after the missed entry to determine if Asterisk Restarted. Other way is you can see the kernel logs to see if Asterisk has thrown any exception. they can be found on Linux at /var/log/messages Regards, Sanjay Rajdev ----- Original Message ----- From: "Alex Balashov" <abalashov at evaristesys.com> To: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users at lists.digium.com> Sent: Thursday, May 22, 2008 3:32:07 AM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi Subject: Re: [asterisk-users] Asterisk Database Handling Douglas Garstang wrote:> We are sending CDR's to MySQL via odbc. It seems that Asterisk is > sometimes dropping CDR's, and they aren't being sent to the database > (they ARE in the Master.csv file though). We suspect that when the MySQL > socket is idle, it gets disconnected, either by the MySQL server or by > our firewall, and when Asterisk goes to send the next CDR over the > socket, does not re-open the database, and drops that CDR. Possibly on > the next call, it connects ok and sends the next CDR.Isn't there a keepalive option somewhere for cdr_mysql.conf, or failing that, a keepalive mechanism that can be enabled for TCP connections on the server side? -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080522/c54626bc/attachment.htm
I couldn't find one for cdr_mysql.conf. We're using odbc anyway. MySQL directly might be an option if it works. Don't think we want to modify the server. ----- Original Message ---- From: Alex Balashov <abalashov at evaristesys.com> To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com> Sent: Wednesday, May 21, 2008 3:02:07 PM Subject: Re: [asterisk-users] Asterisk Database Handling Douglas Garstang wrote:> We are sending CDR's to MySQL via odbc. It seems that Asterisk is > sometimes dropping CDR's, and they aren't being sent to the database > (they ARE in the Master.csv file though). We suspect that when the MySQL > socket is idle, it gets disconnected, either by the MySQL server or by > our firewall, and when Asterisk goes to send the next CDR over the > socket, does not re-open the database, and drops that CDR. Possibly on > the next call, it connects ok and sends the next CDR.Isn't there a keepalive option somewhere for cdr_mysql.conf, or failing that, a keepalive mechanism that can be enabled for TCP connections on the server side? -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080521/9b756af9/attachment.htm
Sanjay Rajdev wrote:> I had a similar problem, but in my case we had a custom application that > was throwing an segmentation exception which was causing Asterisk to > Restart. And in that case It use to miss the log in database. > You can determine the same by looking at the UNIQUEID being logged for > the call. The UNIQUEID actually comprises of 2 things > DateTimeString.CallNumber, everytime Asterisk restarts CallNumber will > start from 1. So you can check the 2-3 UNIQUEID before you missed entry > in CDR table and 2-3 after the missed entry to determine if Asterisk > Restarted. > Other way is you can see the kernel logs to see if Asterisk has thrown > any exception. they can be found on Linux at /var/log/messagesThere is no such thing as a segmentation "exception." C does not have exception handling, and Asterisk does not throw any exceptions. There is, however, a "segmentation fault." That is a memory condition that causes the operating system to terminate the process, in absence of a signal handler for it. None of these can or should be characterised as "exceptions," and have absolutely nothing to do with them. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
On Wed, May 21, 2008 at 5:37 PM, Douglas Garstang <dougmig33 at yahoo.com> wrote:> General Asterisk question. > > We are sending CDR's to MySQL via odbc. It seems that Asterisk is sometimes > dropping CDR's, and they aren't being sent to the database (they ARE in the > Master.csv file though). We suspect that when the MySQL socket is idle, it > gets disconnected, either by the MySQL server or by our firewall, and when > Asterisk goes to send the next CDR over the socket, does not re-open the > database, and drops that CDR. Possibly on the next call, it connects ok and > sends the next CDR. > > This was a documented problem with voicemail users in the db in some > previous version of Asterisk 1.2, and was patched and fixed in a later > version of Asterisk 1.2 > > We are using Asterisk 1.2.19. > > So... surely this must be a general problem with ANY Asterisk module that > uses the database. Do all modules use the same common database code or do > they all use their own? If they all use their own, I guess idle database > connection issues may be fixed in some modules and not others. If it's > common Asterisk database code, is it all fixed in a newer version? Is it > fixed in Asterisk 1.4? > > Thanks, > Doug. >I have no answer, just a potential work around if you get no good answers. I guess you could just pipe the master.csv into your database (similar to how queuemetrics does queue_log) Thanks, Steve Totaro
>>>> So... surely this must be a general problem with ANY Asterisk module that >> uses the database. Do all modules use the same common database code or do >> they all use their own? If they all use their own, I guess idle database >> connection issues may be fixed in some modules and not others. If it's >> common Asterisk database code, is it all fixed in a newer version? Is it >> fixed in Asterisk 1.4? >> >> Thanks, >> Doug. >> > >I have no answer, just a potential work around if you get no good answers. > >I guess you could just pipe the master.csv into your database (similar >to how queuemetrics does queue_log)Are you saying this is a known problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080521/49a872cd/attachment.htm
>----- Original Message ---->From: Alex Balashov <abalashov at evaristesys.com> >To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com> >Sent: Wednesday, May 21, 2008 3:30:06 PM >Subject: Re: [asterisk-users] Asterisk Database Handling > >Douglas Garstang wrote: > >> I couldn't find one for cdr_mysql.conf. >> We're using odbc anyway. MySQL directly might be an option if it works. >> Don't think we want to modify the server. > >Perhaps there's a keepalive option to be set on the UnixODBC DSN, then?I already searched. Could not find one. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080521/0771419e/attachment.htm
>I personally can tell you I've never had a problem with either the>PostgreSQL or MySQL cdr apps themselves losing records. However, I can't >say personally how well the ODBC method works. I'll just stick to saying >that if you're considering using the cdr_mysql addon, I would highly >suggest it as I've used it with MUCH success on high load servers.It's interesting you say that Sherwood. Does your MySQL server have some sort of keep alive setting? I suspect this is a general problem that would affect any and all Asterisk database connectivity. Doug. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080521/2ed2997e/attachment.htm
>I personally can tell you I've never had a problem with either the>PostgreSQL or MySQL cdr apps themselves losing records. However, I can't >say personally how well the ODBC method works. I'll just stick to saying >that if you're considering using the cdr_mysql addon, I would highly >suggest it as I've used it with MUCH success on high load servers.Oh... Also... does your system have idle periods? You said your servers where under high load. The issue seems to be that Asterisk does not re-establish the database connection after it is disconnected do to being idle. If you don't have idle periods, you'd never see this problem anyway. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080521/725de61a/attachment.htm
>Not at all, just offering a workaround. If your master.csv is>complete and correct then it makes sense to use that data unless >someone can identify your problem and offer a fix.Unfortunately, not really feesible. I didn't design the system but we are using CDR's not only for billing purposes, but also to keep state on users. The state info (in a call, not in a call etc) needs to be updated in as close to real time as possible. Files won't do it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080521/dfa2b475/attachment.htm
Looks like an Asterisk 1.4 option? ----- Original Message ---- From: Tilghman Lesher <tilghman at mail.jeffandtilghman.com> To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com> Sent: Wednesday, May 21, 2008 4:39:24 PM Subject: Re: [asterisk-users] Asterisk Database Handling On Wednesday 21 May 2008 17:02:07 Alex Balashov wrote:> Douglas Garstang wrote: > > We are sending CDR's to MySQL via odbc. It seems that Asterisk is > > sometimes dropping CDR's, and they aren't being sent to the database > > (they ARE in the Master.csv file though). We suspect that when the MySQL > > socket is idle, it gets disconnected, either by the MySQL server or by > > our firewall, and when Asterisk goes to send the next CDR over the > > socket, does not re-open the database, and drops that CDR. Possibly on > > the next call, it connects ok and sends the next CDR. > > Isn't there a keepalive option somewhere for cdr_mysql.conf, or failing > that, a keepalive mechanism that can be enabled for TCP connections on > the server side?Please check the 'idlecheck' option in res_odbc.conf. -- Tilghman _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080521/48e80bfc/attachment.htm