Hi Daniel,
On 03/12/2012 05:02 PM, Daniel-Constantin Mierla wrote:
Hello,
On 3/8/12 4:49 PM, Anca Vamanu wrote:
Module: sip-router Branch: master Commit: 7f54aacb740011abe968eb599509cf296e003a61 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=7f54aacb...
Author: Anca Vamanuanca.vamanu@1and1.ro Committer: Anca Vamanuanca.vamanu@1and1.ro Date: Thu Mar 8 17:26:06 2012 +0200
modules_k/presence: Fixed bug - calling child_init in process main
Process main calls child_init with process type PROC_MAIN before forking the TCP children. Since presence module opens database connection in child_init, this resulted in connection being inherited by the TCP children and wierd things happening when doing DB operations.
Have you noticed db connection sharing between processes?
The DB API stores for each connection the PID of the process opening it. When a process is asking for a db connection and URL matches and existing one, current PID is checked with connection pid and if they differ, a new connection should be created, thus no connection sharing should be between processes. Is the db connection open in main process used in other processes?
Yes, this was the case db connection opened by main process inherited by the TCP children. The bug was in presence module and it was introduced by me a couple of weeks ago when I permitted calling child_init function for rank PROC_MAIN.
I noticed only last week when I did the fix that the main process calls child_init with this PROC_MAIN rank before forking the tcp children. Actually there isn't any place now where child_init is called by proc main after all forks.
I understand that the new DB connection is made quite safe to avoid this case, but the bad thing was that presence module had in child_init somewhere at the start:
if (pa_db) return 0;
So it actually did not call the init connection function again for those children.
Regards, Anca
Cheers, Daniel