12 Oct
2010
12 Oct
'10
4:30 p.m.
I've got a strange issue with the latest kamailio. I also had this
problem with kamailio 3.0.3 downloaded from the webpage.
I can start kamailio, but after a while (sometimes within one minuten,
sometimes after an hour),
I get the following log errors:
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core> [db.c:387]:
invalid type (3) or nul (0) version columns for trusted
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core> [db.c:405]:
querying version for table trusted
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: permissions
[trusted.c:249]: error during table version check.
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core>
[sr_module.c:832]: init_mod_child(): Error while initializing module
permissions (//lib/kamailio/modules_k/permissions.so)
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core> [pt.c:481]:
ERROR: fork_tcp_process(): init_child failed for process 10, pid 26621,
"tcp receiver child=0"
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core>
[tcp_main.c:4811]: ERROR: tcp_main: fork failed: Success
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: : <core> [pass_fd.c:103]:
ERROR: recv_all: 1st recv on 21 failed: Connection reset by peer
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: : <core> [tcp_main.c:3323]:
ERROR: handle_tcp_child: read from tcp child 0 (pid 26621, no 10)
Connection reset by peer [104]
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: : <core> [pass_fd.c:293]:
ERROR: receive_fd: EOF on 19
Oct 12 15:46:24 sp01 /sbin/kamailio[26611]: ALERT: <core> [main.c:738]:
child process 26621 exited normally, status=255
Oct 12 15:46:24 sp01 /sbin/kamailio[26611]: INFO: <core> [main.c:756]:
INFO: terminating due to SIGCHLD
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: INFO: <core> [main.c:807]:
INFO: signal 15 received
Looking at the error message, it thinks that the column type of
table_version in the table version is a string (type 3), and it should
be an int (type 1).
But in the database it really is an int.
When I run kamailio with debugging on level 5, I see that it's trying to
run the "select table_version from version where table_name='trusted'"
several times when kamailio starts (for every child thread).
And then minutes, of even an hour later, it suddenly continues with that
check, but based on a database response from another query.
This is the "select password from subscriber ....etc...".
And that column is indeed an string.
I'm using PostgreSQL 8.4 as server,
but maybe someone has seen this before, or now where I have to start
looking?
I first saw it yesterday when started to use the permissions module.
I only see this with the trusted table,
And always it uses the "select password from subscriber ... " response
when giving this error.
So is this an error in the permissions module / trusted.c file?
or something in auth_db that's not freeing the response correctly?
Strange thing is, that is sometimes happens very quick, and sometimes it
can take an half hour or hour.
I can mail the full log if anybody is interested and thinks he/she can
help me.
With kind regards,
Robert Verspuy
--
*Exa-Omicron*
Patroonsweg 10
3892 DB Zeewolde
Tel.: 088-OMICRON (66 427 66)
http://www.exa-omicron.nl
12 Oct
12 Oct
5:01 p.m.
New subject: invalid type (3) or nul (0) version columns for trusted (kamailio 3.1 latest from git)
Robert,
We use Postgres 8.4 as well with the permissions module, but have not
had this problem...
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
On Oct 12, 2010, at 10:30 AM, Robert Verspuy <robert(a)exa-omicron.nl>
wrote:
I've got a strange issue with the latest kamailio.
I also had this
problem with kamailio 3.0.3 downloaded from the webpage.
I can start kamailio, but after a while (sometimes within one
minuten, sometimes after an hour),
I get the following log errors:
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core> [db.c:
387]: invalid type (3) or nul (0) version columns for trusted
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core> [db.c:
405]: querying version for table trusted
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: permissions
[trusted.c:249]: error during table version check.
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core>
[sr_module.c:832]: init_mod_child(): Error while initializing module
permissions (//lib/kamailio/modules_k/permissions.so)
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core> [pt.c:
481]: ERROR: fork_tcp_process(): init_child failed for process 10,
pid 26621, "tcp receiver child=0"
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core>
[tcp_main.c:4811]: ERROR: tcp_main: fork failed: Success
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: : <core> [pass_fd.c:
103]: ERROR: recv_all: 1st recv on 21 failed: Connection reset by peer
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: : <core> [tcp_main.c:
3323]: ERROR: handle_tcp_child: read from tcp child 0 (pid 26621,
no 10) Connection reset by peer [104]
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: : <core> [pass_fd.c:
293]: ERROR: receive_fd: EOF on 19
Oct 12 15:46:24 sp01 /sbin/kamailio[26611]: ALERT: <core>
[main.c:738]: child process 26621 exited normally, status=255
Oct 12 15:46:24 sp01 /sbin/kamailio[26611]: INFO: <core> [main.c:
756]: INFO: terminating due to SIGCHLD
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: INFO: <core> [main.c:
807]: INFO: signal 15 received
Looking at the error message, it thinks that the column type of
table_version in the table version is a string (type 3), and it
should be an int (type 1).
But in the database it really is an int.
When I run kamailio with debugging on level 5, I see that it's
trying to run the "select table_version from version where
table_name='trusted'" several times when kamailio starts (for every
child thread).
And then minutes, of even an hour later, it suddenly continues with
that check, but based on a database response from another query.
This is the "select password from subscriber ....etc...".
And that column is indeed an string.
I'm using PostgreSQL 8.4 as server,
but maybe someone has seen this before, or now where I have to start
looking?
I first saw it yesterday when started to use the permissions module.
I only see this with the trusted table,
And always it uses the "select password from subscriber ... "
response when giving this error.
So is this an error in the permissions module / trusted.c file?
or something in auth_db that's not freeing the response correctly?
Strange thing is, that is sometimes happens very quick, and
sometimes it can take an half hour or hour.
I can mail the full log if anybody is interested and thinks he/she
can help me.
With kind regards,
Robert Verspuy
--
Exa-Omicron
Patroonsweg 10
3892 DB Zeewolde
Tel.: 088-OMICRON (66 427 66)
http://www.exa-omicron.nl
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
21 Oct
21 Oct
10:24 a.m.
Alex,
Could you supply me a bit more information about your setup?
And for anyone with a bit more knowledge of the db_postgres module:
I've been testing a lot now and really have an issue with the receiving
an incorrect resultset.
I think I finally have found what's really going wrong.
The permissions module forks into several threads, and then every thread
is requesting "select table_version from version where
table_name='trusted'".
But all threads do this on the same database connection.
And I see that sometimes thread A sends the query, then thread B sends
the query, on the same database connection.
Then thread B is reading the the resultset, and then thread A is reading
the resultset.
So it is possible that thread A receives the resultset, which is
actually the answer of the query of thread B.
When all threads are requesting the same query (select table_version
from version where table_name='trusted') that's not a big issue,
but when at the same time I receive a SIP REGISTER, Another query is
sent on the same database connection as the query from the permissions
module.
Then the results are swapped, and the table_version function will stop
kamailio.
Shouldn't there be some kind locking mechanisch, that the thread that's
sending a query to the database server, through a database connection,
will also be the thread that's receiving the first resultset. It appears
that such kind of locking is not in use at the moment.
With kind regards,
Robert Verspuy
On 10/12/2010 05:01 PM, Alex Balashov wrote:
Robert,
We use Postgres 8.4 as well with the permissions module, but have not
had this problem...
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
On Oct 12, 2010, at 10:30 AM, Robert Verspuy <robert(a)exa-omicron.nl
<mailto:robert@exa-omicron.nl>> wrote:
> I've got a strange issue with the latest kamailio. I also had this
> problem with kamailio 3.0.3 downloaded from the webpage.
>
> I can start kamailio, but after a while (sometimes within one
> minuten, sometimes after an hour),
> I get the following log errors:
>
> Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core> [db.c:387]:
> invalid type (3) or nul (0) version columns for trusted
> Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core> [db.c:405]:
> querying version for table trusted
> Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: permissions
> [trusted.c:249]: error during table version check.
> Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core>
> [sr_module.c:832]: init_mod_child(): Error while initializing module
> permissions (//lib/kamailio/modules_k/permissions.so)
> Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core> [pt.c:481]:
> ERROR: fork_tcp_process(): init_child failed for process 10, pid
> 26621, "tcp receiver child=0"
> Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core>
> [tcp_main.c:4811]: ERROR: tcp_main: fork failed: Success
> Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: : <core> [pass_fd.c:103]:
> ERROR: recv_all: 1st recv on 21 failed: Connection reset by peer
> Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: : <core>
> [tcp_main.c:3323]: ERROR: handle_tcp_child: read from tcp child 0
> (pid 26621, no 10) Connection reset by peer [104]
> Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: : <core> [pass_fd.c:293]:
> ERROR: receive_fd: EOF on 19
> Oct 12 15:46:24 sp01 /sbin/kamailio[26611]: ALERT: <core>
> [main.c:738]: child process 26621 exited normally, status=255
> Oct 12 15:46:24 sp01 /sbin/kamailio[26611]: INFO: <core>
> [main.c:756]: INFO: terminating due to SIGCHLD
> Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: INFO: <core>
> [main.c:807]: INFO: signal 15 received
>
> Looking at the error message, it thinks that the column type of
> table_version in the table version is a string (type 3), and it
> should be an int (type 1).
> But in the database it really is an int.
>
> When I run kamailio with debugging on level 5, I see that it's trying
> to run the "select table_version from version where
> table_name='trusted'" several times when kamailio starts (for every
> child thread).
> And then minutes, of even an hour later, it suddenly continues with
> that check, but based on a database response from another query.
> This is the "select password from subscriber ....etc...".
> And that column is indeed an string.
>
> I'm using PostgreSQL 8.4 as server,
> but maybe someone has seen this before, or now where I have to start
> looking?
> I first saw it yesterday when started to use the permissions module.
> I only see this with the trusted table,
> And always it uses the "select password from subscriber ... "
> response when giving this error.
>
> So is this an error in the permissions module / trusted.c file?
> or something in auth_db that's not freeing the response correctly?
>
> Strange thing is, that is sometimes happens very quick, and sometimes
> it can take an half hour or hour.
>
> I can mail the full log if anybody is interested and thinks he/she
> can help me.
>
> With kind regards,
> Robert Verspuy
>
>
> --
> *Exa-Omicron*
> Patroonsweg 10
> 3892 DB Zeewolde
> Tel.: 088-OMICRON (66 427 66)
> http://www.exa-omicron.nl
> _______________________________________________
> sr-dev mailing list
> sr-dev(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
*Exa-Omicron*
Patroonsweg 10
3892 DB Zeewolde
Tel.: 088-OMICRON (66 427 66)
http://www.exa-omicron.nl
6:12 p.m.
Robert,
On 10/21/2010 04:24 AM, Robert Verspuy wrote:
I think I finally have found what's really going
wrong.
That's really interesting. Thank you for your work on this!
Personally, I have not had any issues. My setup is with PostgreSQL
8.4 and lately PostgreSQL 9.0, and involves use of 'permissions', a
few other minor DB-backed modules, and also very heavy use of sqlops.
Some of these are very high-volume / concurrent call dense.
To the best of my knowledge I have never run into an issue where a
result for another thread's query was returned. However, it may just
be fortunate coincidence. As someone extremely reliant on
db_postgres, I look forward to the integration of your patch, and
thank you kindly for contributing it!
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
6:17 p.m.
On 10/21/2010 06:12 PM, Alex Balashov wrote:
Personally, I have not had any issues. My setup is
with PostgreSQL
8.4 and lately PostgreSQL 9.0, and involves use of 'permissions', a
few other minor DB-backed modules, and also very heavy use of sqlops.
Some of these are very high-volume / concurrent call dense.
How many threads do
you have running?
And do you have the permissions module setup as cached or not?
I found that the cause is not in the permission module, but the
permissions module (without caching), together with "childeren = 32",
does help to get the problem happen more often.
I have now about 100 threads when kamailio is running ( with childeren =
32 ) on a server with two quad-core processors (8 cores total).
Regards,
Robert
--
*Exa-Omicron*
Patroonsweg 10
3892 DB Zeewolde
Tel.: 088-OMICRON (66 427 66)
http://www.exa-omicron.nl
6:19 p.m.
On 10/21/2010 12:17 PM, Robert Verspuy wrote:
On 10/21/2010 06:12 PM, Alex Balashov wrote:
I also use non-caching with permissions, but my number of threads is
considerably lower than yours; I usually keep them at about the
default 8 per core. I suspect less contention here probably accounts
for the differences in result; I've simply been fortunate that the
database returns queries fast enough and in the order in which they
are made within the timing tolerance demands of the non-reentrant
behaviour.
Thank you again for exploring it.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
Personally, I have not had any issues. My setup
is with PostgreSQL
8.4 and lately PostgreSQL 9.0, and involves use of 'permissions', a
few other minor DB-backed modules, and also very heavy use of
sqlops. Some of these are very high-volume / concurrent call dense.
How many
threads do you have running?
And do you have the permissions module setup as cached or not?
I found that the cause is not in the permission module, but the
permissions module (without caching), together with "childeren = 32",
does help to get the problem happen more often.
I have now about 100 threads when kamailio is running ( with childeren
= 32 ) on a server with two quad-core processors (8 cores total).
19 Oct
19 Oct
noon
I've got some more debug information,
but it almost looks like a race condition.
When I turn of all debugging the problem occurs more often.
When I turn on debugging (level 4 or 5) I almost never see the error.
But I finally have some debugging info:
Oct 18 19:40:53 localhost /sbin/kamailio[29227]: DEBUG: <core>
[sr_module.c:828]: DEBUG: init_mod_child (96): permissions
Oct 18 19:40:53 localhost /sbin/kamailio[29227]: DEBUG: <core>
[db.c:294]: connection 0x958390 found in pool
Oct 18 19:40:53 localhost /sbin/kamailio[29227]: DEBUG: db_postgres
[km_val.c:163]: PQescapeStringConn: in: 7 chars, out: 7 chars
Oct 18 19:40:53 localhost /sbin/kamailio[29227]: DEBUG: db_postgres
[km_dbase.c:149]: 0x959aa0 PQsendQuery(select table_version from version
where table_name='trusted')
Oct 18 19:40:53 localhost /sbin/kamailio[29227]: DEBUG: <core>
[db_res.c:118]: allocate 48 bytes for result set at 0x94d790
Then 47 seconds later (in the mean time, nothing is reported for pid 29227):
Oct 18 19:41:40 localhost /sbin/kamailio[29227]: DEBUG: db_postgres
[km_dbase.c:403]: 0x959aa0 PQresultStatus(PGRES_TUPLES_OK)
PQgetResult(0x139aca20)
Oct 18 19:41:40 localhost /sbin/kamailio[29227]: DEBUG: db_postgres
[km_res.c:108]: 1 columns returned from the query
Oct 18 19:41:40 localhost /sbin/kamailio[29227]: DEBUG: <core>
[db_res.c:155]: allocate 8 bytes for result names at 0x94b1f0
Oct 18 19:41:40 localhost /sbin/kamailio[29227]: DEBUG: <core>
[db_res.c:165]: allocate 4 bytes for result types at 0x942140
Oct 18 19:41:40 localhost /sbin/kamailio[29227]: DEBUG: db_postgres
[km_res.c:126]: allocate 16 bytes for RES_NAMES[0] at 0x9599b0
Oct 18 19:41:40 localhost /sbin/kamailio[29227]: DEBUG: db_postgres
[km_res.c:133]: RES_NAMES(0x9599b0)[0]=[password]
Oct 18 19:41:40 localhost /sbin/kamailio[29227]: DEBUG: db_postgres
[km_res.c:166]: use DB1_STRING result type
Oct 18 19:41:40 localhost /sbin/kamailio[29227]: DEBUG: db_postgres
[km_res.c:222]: allocate for 1 columns 8 bytes in row buffer at 0x959538
Oct 18 19:41:40 localhost /sbin/kamailio[29227]: DEBUG: <core>
[db_res.c:184]: allocate 16 bytes for rows at 0x9598d8
Oct 18 19:41:40 localhost /sbin/kamailio[29227]: DEBUG: db_postgres
[km_res.c:243]: PQgetvalue(0x959aa0,0,0)=[mAC4QMyW262E]
Oct 18 19:41:40 localhost /sbin/kamailio[29227]: DEBUG: db_postgres
[km_res.c:252]: [0][0] Column[password]=[mAC4QMyW262E]
Oct 18 19:41:40 localhost /sbin/kamailio[29227]: DEBUG: <core>
[db_row.c:119]: allocate 32 bytes for row values at 0x94d820
Oct 18 19:41:40 localhost /sbin/kamailio[29227]: DEBUG: <core>
[db_val.c:117]: converting STRING [mAC4QMyW262E]
Oct 18 19:41:40 localhost /sbin/kamailio[29227]: DEBUG: <core>
[db_val.c:127]: allocate 13 bytes memory for STRING at 0x9596d0
Oct 18 19:41:40 localhost /sbin/kamailio[29227]: DEBUG: db_postgres
[km_res.c:267]: freeing row buffer at 0x959538
Oct 18 19:41:40 localhost /sbin/kamailio[29227]: DEBUG: db_postgres
[km_dbase.c:302]: PQclear(0x139aca20) result set
Oct 18 19:41:40 localhost /sbin/kamailio[29227]: ERROR: <core>
[db.c:387]: invalid type (3) or nul (0) version columns for trusted
I have more debugging lines if someone has an idea.
But it appears that pid 29227 is sending a query, and when it continues
it's working with the results from a completely different query.
Regards,
Robert
On 10/12/2010 04:30 PM, Robert Verspuy wrote:
I've got a strange issue with the latest kamailio.
I also had this
problem with kamailio 3.0.3 downloaded from the webpage.
I can start kamailio, but after a while (sometimes within one minuten,
sometimes after an hour),
I get the following log errors:
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core> [db.c:387]:
invalid type (3) or nul (0) version columns for trusted
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core> [db.c:405]:
querying version for table trusted
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: permissions
[trusted.c:249]: error during table version check.
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core>
[sr_module.c:832]: init_mod_child(): Error while initializing module
permissions (//lib/kamailio/modules_k/permissions.so)
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core> [pt.c:481]:
ERROR: fork_tcp_process(): init_child failed for process 10, pid
26621, "tcp receiver child=0"
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core>
[tcp_main.c:4811]: ERROR: tcp_main: fork failed: Success
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: : <core> [pass_fd.c:103]:
ERROR: recv_all: 1st recv on 21 failed: Connection reset by peer
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: : <core>
[tcp_main.c:3323]: ERROR: handle_tcp_child: read from tcp child 0
(pid 26621, no 10) Connection reset by peer [104]
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: : <core> [pass_fd.c:293]:
ERROR: receive_fd: EOF on 19
Oct 12 15:46:24 sp01 /sbin/kamailio[26611]: ALERT: <core>
[main.c:738]: child process 26621 exited normally, status=255
Oct 12 15:46:24 sp01 /sbin/kamailio[26611]: INFO: <core> [main.c:756]:
INFO: terminating due to SIGCHLD
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: INFO: <core> [main.c:807]:
INFO: signal 15 received
Looking at the error message, it thinks that the column type of
table_version in the table version is a string (type 3), and it should
be an int (type 1).
But in the database it really is an int.
When I run kamailio with debugging on level 5, I see that it's trying
to run the "select table_version from version where
table_name='trusted'" several times when kamailio starts (for every
child thread).
And then minutes, of even an hour later, it suddenly continues with
that check, but based on a database response from another query.
This is the "select password from subscriber ....etc...".
And that column is indeed an string.
I'm using PostgreSQL 8.4 as server,
but maybe someone has seen this before, or now where I have to start
looking?
I first saw it yesterday when started to use the permissions module.
I only see this with the trusted table,
And always it uses the "select password from subscriber ... " response
when giving this error.
So is this an error in the permissions module / trusted.c file?
or something in auth_db that's not freeing the response correctly?
Strange thing is, that is sometimes happens very quick, and sometimes
it can take an half hour or hour.
I can mail the full log if anybody is interested and thinks he/she can
help me.
With kind regards,
Robert Verspuy
--
*Exa-Omicron*
Patroonsweg 10
3892 DB Zeewolde
Tel.: 088-OMICRON (66 427 66)
http://www.exa-omicron.nl
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
*Exa-Omicron*
Patroonsweg 10
3892 DB Zeewolde
Tel.: 088-OMICRON (66 427 66)
http://www.exa-omicron.nl
21 Oct
21 Oct
2:29 p.m.
I found the issue.
Hopefully someone who's maintaining the kamailio db_postgres module can
react to this.
According to the libpq documentation (see
http://www.enterprisedb.com/documentation/libpq-concepts.html all the
way at the bottom).
One thread restriction is that no two threads attempt
to manipulate
the same PGconn object at the same time. In particular, you cannot
issue concurrent commands from different threads through the same
connection object. (If you need to run concurrent commands, use
multiple connections.)
I've been adding several debugging code to the
db_postgres module, And I
see that two different threads use two different _con variables,
but the _con->tail from separate threads are pointing both to same
memory location, and using the same postgresql connection.
When multiple threads run at the same time and placing queries almost at
the same time, it happens that the results of those queries are returned
back to the other thread.
I don't know the kamailio code (Just started with kamailio 3 weeks back),
but it appears to me that the lib/srdb source is holding using some kind
of pools for the database connections,
and db_postgres modules also is using pools.
I'm going to try to see if I can fix the code somehow that every thread
gets its own database connection.
but if someone who knows the db_postgres module could help I would be
very thankfull!
--
*Exa-Omicron*
Patroonsweg 10
3892 DB Zeewolde
Tel.: 088-OMICRON (66 427 66)
http://www.exa-omicron.nl
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
*Exa-Omicron*
Patroonsweg 10
3892 DB Zeewolde
Tel.: 088-OMICRON (66 427 66)
http://www.exa-omicron.nl
5:53 p.m.
New subject: [patch] invalid type (3) or nul (0) version columns for trusted (kamailio 3.1 with db_postgres latest from git)
I found the cause of my issue.
In the source lib/srdb1/* some kind of pooling is used.
When kamailio needs a database connection, the cmp_db_id function checks
to see if there is already a database connection with the exact same
params (username, database, server etc..).
According to the PQ library every proces / thread should have it's own
database connection.
The db_postgres is setup to use asynchronous I/O with the PQ library.
So when two threads are using the same database connection it is
possible that,
the resultset from a query of thread A is returned to thread B.
The cmp_db_id function in lib/srdb1/db_id.c does _not_ check the PID.
I've created a small patch to fix the problems mentioned above.
The changes are made in lib/srdb1/* files
So if you apply them, it will be active for _every_ database module.
Maybe it's not needed for the mysql database,
but I *assume* it will not break when used on a mysql database. (not tested)
Maybe you will get a bit more database connections, but that depends on
which modules you're using.
What did I do:
* Added pid to the db_id struct.
* During initialization the pid is saved into the db_id struct.
* In cmp_db_id the pid is also checked when searching for a database
connection to be reused.
With kind Regards,
Robert Verspuy
--
*Exa-Omicron*
Patroonsweg 10
3892 DB Zeewolde
Tel.: 088-OMICRON (66 427 66)
http://www.exa-omicron.nl
30 Nov
30 Nov
10:10 p.m.
New subject: [patch] invalid type (3) or nul (0) version columns for trusted (kamailio 3.1 with db_postgres latest from git)
Hello,
I missed this patch, due to some traveling. It is good in my opinion,
but a different purpose.
Kamailio processes should not share a database connection as well.
Storing the pid inside db connection structure is good to discover that
some module does a fault DB initialization. Your investigation really
helps a lot, thanks!
Cheers,
Daniel
On 10/21/10 5:53 PM, Robert Verspuy wrote:
I found the cause of my issue.
In the source lib/srdb1/* some kind of pooling is used.
When kamailio needs a database connection, the cmp_db_id function
checks to see if there is already a database connection with the exact
same params (username, database, server etc..).
According to the PQ library every proces / thread should have it's own
database connection.
The db_postgres is setup to use asynchronous I/O with the PQ library.
So when two threads are using the same database connection it is
possible that,
the resultset from a query of thread A is returned to thread B.
The cmp_db_id function in lib/srdb1/db_id.c does _not_ check the PID.
I've created a small patch to fix the problems mentioned above.
The changes are made in lib/srdb1/* files
So if you apply them, it will be active for _every_ database module.
Maybe it's not needed for the mysql database,
but I *assume* it will not break when used on a mysql database. (not
tested)
Maybe you will get a bit more database connections, but that depends
on which modules you're using.
What did I do:
* Added pid to the db_id struct.
* During initialization the pid is saved into the db_id struct.
* In cmp_db_id the pid is also checked when searching for a
database connection to be reused.
With kind Regards,
Robert Verspuy
--
*Exa-Omicron*
Patroonsweg 10
3892 DB Zeewolde
Tel.: 088-OMICRON (66 427 66)
http://www.exa-omicron.nl
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Jan 24-26, 2011, Irvine, CA, USA
http://www.asipto.com
4895
days inactive
4944
days old
9 comments
3 participants
participants (3)
-
Alex Balashov -
Daniel-Constantin Mierla -
Robert Verspuy