[SR-Users] Kamailio lib/srdb1/db_id.c handling of multiple database connections and race condition

[Robert Verspuy]

Hi Torge,

I think it's better to send your mail to the mailinglist, then more 
people can have a look at your problem.

I'm not really familiar with the kamailio source code. Just started 
using Kamailio about 8 months back. I came across a problem with 
requesting information from a postgresql database and made a patch which 
'works for me'. I'm not using siptrace.

Maybe you can supply more logging (through the mailinglist) of the 
database communication. The mysql error "Duplicate entry '96193' for key 
'PRIMARY'" is a bit weird. As I said, I don't know and don't use the 
msyql driver in kamailio, but normally I would expect that mysql itself 
would take care of generating a primary key for the record.

So maybe your problem is in the mysql server and not kamailio.
Maybe this page can help you:
http://www.softwareprojects.com/resources/programming/t-how-to-fix-mysql-duplicate-entry-for-key-primary-o-1844.html

With kind regards,
Robert Verspuy



Op 05-05-11 13:19, Dr. Torge Szczepanek schreef:
> Hi!
>
> First of all thanks for all of your work. I really appreciate and I am 
> glad that there is such a nice Opensource SIP Proxy available.
>
> In a current project I am heavily relying on SIP Traces stored to a 
> database and other sqlops, dialplan operations using database connections.
>
> It seems that there is a race condition with SQL Databases (Postgres 
> and also MySQL) due to thread insafety as described in:
>
> http://lists.sip-router.org/pipermail/sr-dev/2010-October/009689.html
>
> This is causing multiple errors. I guess that the following error is 
> also caused by this race condition (thread safety):
>
> /usr/sbin/kamailio[5646]: ERROR: <core> [db_query.c:179]: error while 
> submitting query
> /usr/sbin/kamailio[5646]: ERROR: siptrace [siptrace.c:532]: error 
> storing trace
> /usr/sbin/kamailio[5646]: ERROR: db_mysql [km_dbase.c:120]: driver 
> error on query: Duplicate entry '96193' for key 'PRIMARY'
>
> My Kamailo Version (3.1.2) is reporting duplicate database URLs using 
> a warning:
>
> /usr/sbin/kamailio[5613]: WARNING: <core> [db_id.c:281]: identical DB 
> URLs, but different DB connection pid [5613/5562]
> /usr/sbin/kamailio[5618]: WARNING: <core> [db_id.c:281]: identical DB 
> URLs, but different DB connection pid [5618/5562]
> /usr/sbin/kamailio[5616]: WARNING: <core> [db_id.c:281]: identical DB 
> URLs, but different DB connection pid [5616/5562]
> /usr/sbin/kamailio[5600]: WARNING: <core> [db_id.c:281]: identical DB 
> URLs, but different DB connection pid [5600/5562]
> /usr/sbin/kamailio[5617]: WARNING: <core> [db_id.c:281]: identical DB 
> URLs, but different DB connection pid [5617/5562]
>
> Git commit 9fb37a55e0b97a98b7d2d104a7692f18cb3f7df6 is turning this 
> into a debug message, which I think is a bad idea if the thread 
> insafety still exists.
>
> As far as I know every thread should use its own database handle, at 
> least when using the MySQL API.
>
> Is there a way to handle this correctly? Can you give me any clues on 
> which approach to take here? Since I need a solution for this I would 
> like to  fix this issue at least for myself and of course giving the 
> change back.
>
> Greetings Torge
> --
> Dr. Torge Szczepanek
>
> Cygnus Networks GmbH                       Tel:   +49-228-9090987-0
> Adenauerallee 73                           Fax:   +49-228-9090987-70
> D-53113 Bonn                               EMail: 
> info at cygnusnetworks.de <mailto:info at cygnusnetworks.de>
> Amtsgericht Bonn, HRB 15928                SIP: info at cygnusnetworks.de 
> <mailto:info at cygnusnetworks.de>
> Geschaeftsfuehrer Dr. Torge Szczepanek http://www.cygnusnetworks.de/
> Steuernummer 205/5710/1347                 USt-ID DE258507007
>


-- 
*Exa-Omicron*
Patroonsweg 10
3892 DB Zeewolde
Tel.: 088-OMICRON (66 427 66)
http://www.exa-omicron.nl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20110505/a95b82ad/attachment.htm>