13 Jan
2012
13 Jan
'12
9 a.m.
Hi all
I have started making some tests with the ndb_redis module. So far we have
not stressed the module (no more than 5 HGET commands/second at maximum).
It works well, but with at some point it starts failing. The failures are
easily found because the logs always show this:
INFO: <core> [main.c:811]: INFO: signal 13 received
After that the redis value is always null. If I restart kamailio it starts
working again.
I've run kamailio with debug=4 but I haven't seen more useful information.
On the redis side, I could find nothing in the logs either, the number of
clientes connected is alway much less than the configured maximum, Any idea?
On the other hand, if I restart redis we need to restart kamailio to
restore the connections. Is the reconnection to redis on the roadmap?
Thanks in advance
Regards
Javi
13 Jan
13 Jan
10:28 a.m.
Javi,
ndb_redis does not reconnect if the server closes connection on timeout.
It should work if you set timeout to zero in server config. I thought
that I created a ticket in the bugtracker for that before, but not sure,
I can't find it right now.
On 13.01.2012 08:00, Javier Gallart wrote:
Hi all
I have started making some tests with the ndb_redis module. So far we
have not stressed the module (no more than 5 HGET commands/second at
maximum). It works well, but with at some point it starts failing. The
failures are easily found because the logs always show this:
INFO: <core> [main.c:811]: INFO: signal 13 received
After that the redis value is always null. If I restart kamailio it
starts working again.
I've run kamailio with debug=4 but I haven't seen more useful
information. On the redis side, I could find nothing in the logs either,
the number of clientes connected is alway much less than the configured
maximum, Any idea?
On the other hand, if I restart redis we need to restart kamailio to
restore the connections. Is the reconnection to redis on the roadmap?
Thanks in advance
Regards
Javi
10:35 a.m.
Hello,
On 1/13/12 8:00 AM, Javier Gallart wrote:
Hi all
I have started making some tests with the ndb_redis module. So far we
have not stressed the module (no more than 5 HGET commands/second at
maximum). It works well, but with at some point it starts failing. The
failures are easily found because the logs always show this:
INFO: <core> [main.c:811]: INFO: signal 13 received
this due to a broken
connection. What do you get in redis reply and info
variables?
After that the redis value is always null. If I
restart kamailio it
starts working again.
I've run kamailio with debug=4 but I haven't seen more useful
information. On the redis side, I could find nothing in the logs
either, the number of clientes connected is alway much less than the
configured maximum, Any idea?
On the other hand, if I restart redis we need to restart kamailio to
restore the connections. Is the reconnection to redis on the roadmap?
It should not be that complex, there is the code for initializing the
connection, it should be reused for doing it again in case of failure.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
1:27 p.m.
Hi Daniel
both values are null. I might have found something: apparently some of the
sockets kamailio->redis were inactive for a while and were being closed in
the redis end. This is redis default config:
# Close the connection after a client is idle for N seconds (0 to disable)
timeout 600
I've set the timeout value to 0 to confirm if this is actually the problem.
In case it might be useful for somebody, we've used lsof in recurrent mode
to monitor the sockets status:
server# lsof -i :6379 -r 5"m===%T===" | grep -e == -e kamailio
===05:28:26===
kamailio 13365 kamailio 4u IPv4 58622 0t0 TCP
localhost:34994->localhost:6379 (ESTABLISHED)
kamailio 13366 kamailio 4u IPv4 58626 0t0 TCP
localhost:34995->localhost:6379 (ESTABLISHED)
kamailio 13367 kamailio 4u IPv4 58628 0t0 TCP
localhost:34996->localhost:6379 (ESTABLISHED)
kamailio 13368 kamailio 4u IPv4 58632 0t0 TCP
localhost:34997->localhost:6379 (ESTABLISHED)
kamailio 13369 kamailio 4u IPv4 58649 0t0 TCP
localhost:35000->localhost:6379 (ESTABLISHED)
kamailio 13370 kamailio 4u IPv4 58661 0t0 TCP
localhost:35003->localhost:6379 (ESTABLISHED)
kamailio 13376 kamailio 10u IPv4 58710 0t0 TCP
localhost:35013->localhost:6379 (ESTABLISHED)
kamailio 13377 kamailio 4u IPv4 58705 0t0 TCP
localhost:35012->localhost:6379 (ESTABLISHED)
kamailio 13378 kamailio 4u IPv4 58695 0t0 TCP
localhost:35008->localhost:6379 (ESTABLISHED)
kamailio 13381 kamailio 4u IPv4 58691 0t0 TCP
localhost:35006->localhost:6379 (ESTABLISHED)
kamailio 13382 kamailio 4u IPv4 58693 0t0 TCP
localhost:35007->localhost:6379 (ESTABLISHED)
===05:28:31===
kamailio 13365 kamailio 4u IPv4 58622 0t0 TCP
localhost:34994->localhost:6379 (ESTABLISHED)
kamailio 13366 kamailio 4u IPv4 58626 0t0 TCP
localhost:34995->localhost:6379 (CLOSE_WAIT)
kamailio 13367 kamailio 4u IPv4 58628 0t0 TCP
localhost:34996->localhost:6379 (ESTABLISHED)
kamailio 13368 kamailio 4u IPv4 58632 0t0 TCP
localhost:34997->localhost:6379 (CLOSE_WAIT)
kamailio 13369 kamailio 4u IPv4 58649 0t0 TCP
localhost:35000->localhost:6379 (CLOSE_WAIT)
kamailio 13370 kamailio 4u IPv4 58661 0t0 TCP
localhost:35003->localhost:6379 (CLOSE_WAIT)
kamailio 13376 kamailio 10u IPv4 58710 0t0 TCP
localhost:35013->localhost:6379 (CLOSE_WAIT)
kamailio 13377 kamailio 4u IPv4 58705 0t0 TCP
localhost:35012->localhost:6379 (CLOSE_WAIT)
kamailio 13378 kamailio 4u IPv4 58695 0t0 TCP
localhost:35008->localhost:6379 (CLOSE_WAIT)
kamailio 13381 kamailio 4u IPv4 58691 0t0 TCP
localhost:35006->localhost:6379 (CLOSE_WAIT)
kamailio 13382 kamailio 4u IPv4 58693 0t0 TCP
localhost:35007->localhost:6379 (CLOSE_WAIT)
Regards
Javi
On Fri, Jan 13, 2012 at 9:35 AM, Daniel-Constantin Mierla <miconda(a)gmail.com
wrote:
Hello,
On 1/13/12 8:00 AM, Javier Gallart wrote:
Hi all
I have started making some tests with the ndb_redis module. So far we
have not stressed the module (no more than 5 HGET commands/second at
maximum). It works well, but with at some point it starts failing. The
failures are easily found because the logs always show this:
INFO: <core> [main.c:811]: INFO: signal 13 received
this due to a broken connection. What do you get in redis reply and info
variables?
After that the redis value is always null. If I restart kamailio it
starts working again.
I've run kamailio with debug=4 but I haven't seen more useful
information. On the redis side, I could find nothing in the logs either,
the number of clientes connected is alway much less than the configured
maximum, Any idea?
On the other hand, if I restart redis we need to restart kamailio to
restore the connections. Is the reconnection to redis on the roadmap?
It should not be that complex, there is the code for initializing the
connection, it should be reused for doing it again in case of failure.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
16 Jan
16 Jan
10:47 a.m.
Hello,
On 1/13/12 12:27 PM, Javier Gallart wrote:
Hi Daniel
both values are null.
ok, could be a hint that the connection is down and try a
reconnect...
I might have found something: apparently some of the
sockets
kamailio->redis were inactive for a while and were being closed in the
redis end.
Do you know if there is a keepalive mechanism that reddis offers, or a
command to set the timeout value from the client side?
Cheers,
Daniel
This is redis default config:
# Close the connection after a client is idle for N seconds (0 to disable)
timeout 600
I've set the timeout value to 0 to confirm if this is actually the
problem.
In case it might be useful for somebody, we've used lsof in recurrent
mode to monitor the sockets status:
server# lsof -i :6379 -r 5"m===%T===" | grep -e == -e kamailio
===05:28:26===
kamailio 13365 kamailio 4u IPv4 58622 0t0 TCP
localhost:34994->localhost:6379 (ESTABLISHED)
kamailio 13366 kamailio 4u IPv4 58626 0t0 TCP
localhost:34995->localhost:6379 (ESTABLISHED)
kamailio 13367 kamailio 4u IPv4 58628 0t0 TCP
localhost:34996->localhost:6379 (ESTABLISHED)
kamailio 13368 kamailio 4u IPv4 58632 0t0 TCP
localhost:34997->localhost:6379 (ESTABLISHED)
kamailio 13369 kamailio 4u IPv4 58649 0t0 TCP
localhost:35000->localhost:6379 (ESTABLISHED)
kamailio 13370 kamailio 4u IPv4 58661 0t0 TCP
localhost:35003->localhost:6379 (ESTABLISHED)
kamailio 13376 kamailio 10u IPv4 58710 0t0 TCP
localhost:35013->localhost:6379 (ESTABLISHED)
kamailio 13377 kamailio 4u IPv4 58705 0t0 TCP
localhost:35012->localhost:6379 (ESTABLISHED)
kamailio 13378 kamailio 4u IPv4 58695 0t0 TCP
localhost:35008->localhost:6379 (ESTABLISHED)
kamailio 13381 kamailio 4u IPv4 58691 0t0 TCP
localhost:35006->localhost:6379 (ESTABLISHED)
kamailio 13382 kamailio 4u IPv4 58693 0t0 TCP
localhost:35007->localhost:6379 (ESTABLISHED)
===05:28:31===
kamailio 13365 kamailio 4u IPv4 58622 0t0 TCP
localhost:34994->localhost:6379 (ESTABLISHED)
kamailio 13366 kamailio 4u IPv4 58626 0t0 TCP
localhost:34995->localhost:6379 (CLOSE_WAIT)
kamailio 13367 kamailio 4u IPv4 58628 0t0 TCP
localhost:34996->localhost:6379 (ESTABLISHED)
kamailio 13368 kamailio 4u IPv4 58632 0t0 TCP
localhost:34997->localhost:6379 (CLOSE_WAIT)
kamailio 13369 kamailio 4u IPv4 58649 0t0 TCP
localhost:35000->localhost:6379 (CLOSE_WAIT)
kamailio 13370 kamailio 4u IPv4 58661 0t0 TCP
localhost:35003->localhost:6379 (CLOSE_WAIT)
kamailio 13376 kamailio 10u IPv4 58710 0t0 TCP
localhost:35013->localhost:6379 (CLOSE_WAIT)
kamailio 13377 kamailio 4u IPv4 58705 0t0 TCP
localhost:35012->localhost:6379 (CLOSE_WAIT)
kamailio 13378 kamailio 4u IPv4 58695 0t0 TCP
localhost:35008->localhost:6379 (CLOSE_WAIT)
kamailio 13381 kamailio 4u IPv4 58691 0t0 TCP
localhost:35006->localhost:6379 (CLOSE_WAIT)
kamailio 13382 kamailio 4u IPv4 58693 0t0 TCP
localhost:35007->localhost:6379 (CLOSE_WAIT)
Regards
Javi
On Fri, Jan 13, 2012 at 9:35 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
On 1/13/12 8:00 AM, Javier Gallart wrote:
Hi all
I have started making some tests with the ndb_redis module. So
far we have not stressed the module (no more than 5 HGET
commands/second at maximum). It works well, but with at some
point it starts failing. The failures are easily found because
the logs always show this:
INFO: <core> [main.c:811]: INFO: signal 13 received
this due to a broken connection. What do you get in redis reply
and info variables?
After that the redis value is always null. If I restart
kamailio it starts working again.
I've run kamailio with debug=4 but I haven't seen more useful
information. On the redis side, I could find nothing in the
logs either, the number of clientes connected is alway much
less than the configured maximum, Any idea?
On the other hand, if I restart redis we need to restart
kamailio to restore the connections. Is the reconnection to
redis on the roadmap?
It should not be that complex, there is the code for initializing
the connection, it should be reused for doing it again in case of
failure.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
1:15 p.m.
Hi Daniel
On Mon, Jan 16, 2012 at 9:47 AM, Daniel-Constantin Mierla <miconda(a)gmail.com
wrote:
Hello,
On 1/13/12 12:27 PM, Javier Gallart wrote:
Hi Daniel
both values are null.
ok, could be a hint that the connection is down and try a reconnect...
I might have found something: apparently some of the sockets
kamailio->redis were inactive for a while and were being closed in the
redis end.
Do you know if there is a keepalive mechanism that reddis offers, or a
command to set the timeout value from the client side?
In redis config file the only related value I've seen is "timeout". If set
to 0, the server never disconnects inactive clients. From the client
perspective, what about this: http://www.redis.io/commands/ping
Regards
Javi
> Cheers,
> Daniel
>
> This is redis default config:
> # Close the connection after a client is idle for N seconds (0 to
> disable)
> timeout 600
>
> I've set the timeout value to 0 to confirm if this is actually the
> problem.
>
> In case it might be useful for somebody, we've used lsof in recurrent
> mode to monitor the sockets status:
>
> server# lsof -i :6379 -r 5"m===%T===" | grep -e == -e kamailio
> ===05:28:26===
> kamailio 13365 kamailio 4u IPv4 58622 0t0 TCP
> localhost:34994->localhost:6379 (ESTABLISHED)
> kamailio 13366 kamailio 4u IPv4 58626 0t0 TCP
> localhost:34995->localhost:6379 (ESTABLISHED)
> kamailio 13367 kamailio 4u IPv4 58628 0t0 TCP
> localhost:34996->localhost:6379 (ESTABLISHED)
> kamailio 13368 kamailio 4u IPv4 58632 0t0 TCP
> localhost:34997->localhost:6379 (ESTABLISHED)
> kamailio 13369 kamailio 4u IPv4 58649 0t0 TCP
> localhost:35000->localhost:6379 (ESTABLISHED)
> kamailio 13370 kamailio 4u IPv4 58661 0t0 TCP
> localhost:35003->localhost:6379 (ESTABLISHED)
> kamailio 13376 kamailio 10u IPv4 58710 0t0 TCP
> localhost:35013->localhost:6379 (ESTABLISHED)
> kamailio 13377 kamailio 4u IPv4 58705 0t0 TCP
> localhost:35012->localhost:6379 (ESTABLISHED)
> kamailio 13378 kamailio 4u IPv4 58695 0t0 TCP
> localhost:35008->localhost:6379 (ESTABLISHED)
> kamailio 13381 kamailio 4u IPv4 58691 0t0 TCP
> localhost:35006->localhost:6379 (ESTABLISHED)
> kamailio 13382 kamailio 4u IPv4 58693 0t0 TCP
> localhost:35007->localhost:6379 (ESTABLISHED)
> ===05:28:31===
> kamailio 13365 kamailio 4u IPv4 58622 0t0 TCP
> localhost:34994->localhost:6379 (ESTABLISHED)
> kamailio 13366 kamailio 4u IPv4 58626 0t0 TCP
> localhost:34995->localhost:6379 (CLOSE_WAIT)
> kamailio 13367 kamailio 4u IPv4 58628 0t0 TCP
> localhost:34996->localhost:6379 (ESTABLISHED)
> kamailio 13368 kamailio 4u IPv4 58632 0t0 TCP
> localhost:34997->localhost:6379 (CLOSE_WAIT)
> kamailio 13369 kamailio 4u IPv4 58649 0t0 TCP
> localhost:35000->localhost:6379 (CLOSE_WAIT)
> kamailio 13370 kamailio 4u IPv4 58661 0t0 TCP
> localhost:35003->localhost:6379 (CLOSE_WAIT)
> kamailio 13376 kamailio 10u IPv4 58710 0t0 TCP
> localhost:35013->localhost:6379 (CLOSE_WAIT)
> kamailio 13377 kamailio 4u IPv4 58705 0t0 TCP
> localhost:35012->localhost:6379 (CLOSE_WAIT)
> kamailio 13378 kamailio 4u IPv4 58695 0t0 TCP
> localhost:35008->localhost:6379 (CLOSE_WAIT)
> kamailio 13381 kamailio 4u IPv4 58691 0t0 TCP
> localhost:35006->localhost:6379 (CLOSE_WAIT)
> kamailio 13382 kamailio 4u IPv4 58693 0t0 TCP
> localhost:35007->localhost:6379 (CLOSE_WAIT)
>
> Regards
>
> Javi
>
> On Fri, Jan 13, 2012 at 9:35 AM, Daniel-Constantin Mierla <
> miconda(a)gmail.com wrote:
>
>> Hello,
>>
>>
>> On 1/13/12 8:00 AM, Javier Gallart wrote:
>>
>>> Hi all
>>>
>>> I have started making some tests with the ndb_redis module. So far we
>>> have not stressed the module (no more than 5 HGET commands/second at
>>> maximum). It works well, but with at some point it starts failing. The
>>> failures are easily found because the logs always show this:
>>> INFO: <core> [main.c:811]: INFO: signal 13 received
>>>
>> this due to a broken connection. What do you get in redis reply and info
>> variables?
>>
>>
>> After that the redis value is always null. If I restart kamailio it
>>> starts working again.
>>> I've run kamailio with debug=4 but I haven't seen more useful
>>> information. On the redis side, I could find nothing in the logs either,
>>> the number of clientes connected is alway much less than the configured
>>> maximum, Any idea?
>>> On the other hand, if I restart redis we need to restart kamailio to
>>> restore the connections. Is the reconnection to redis on the roadmap?
>>>
>>
>> It should not be that complex, there is the code for initializing the
>> connection, it should be reused for doing it again in case of failure.
>>
>> Cheers,
>> Daniel
>>
>> --
>> Daniel-Constantin Mierla -- http://www.asipto.com
>> http://linkedin.com/in/miconda -- http://twitter.com/miconda
>>
>>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierla -- http://www.asipto.comhttp://linkedin.com/in/miconda --
http://twitter.com/miconda
>
>
17 Feb
17 Feb
11:47 a.m.
Hello,
I made a patch for server reconnect -- I had no access to a computer
with redis lib installed for the moment, hopefully it compiles. If you
can try and tell the result, it would be great, I can commit then.
Cheers,
Daniel
On 1/16/12 12:15 PM, Javier Gallart wrote:
Hi Daniel
On Mon, Jan 16, 2012 at 9:47 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
On 1/13/12 12:27 PM, Javier Gallart wrote:
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hi Daniel
both values are null.
ok, could be a hint that the connection is down and
try a
reconnect...
I might have found something: apparently some
of the sockets
kamailio->redis were inactive for a while and were being closed
in the redis end.
Do you know if there is a keepalive mechanism that reddis offers,
or a command to set the timeout value from the client side?
In redis config file the only related value I've seen is "timeout". If
set to 0, the server never disconnects inactive clients. From the
client perspective, what about this: http://www.redis.io/commands/ping
Regards
Javi
Cheers,
Daniel
This is redis default config:
# Close the connection after a client is idle for N seconds (0 to
disable)
timeout 600
I've set the timeout value to 0 to confirm if this is actually
the problem.
In case it might be useful for somebody, we've used lsof in
recurrent mode to monitor the sockets status:
server# lsof -i :6379 -r 5"m===%T===" | grep -e == -e kamailio
===05:28:26===
kamailio 13365 kamailio 4u IPv4 58622 0t0 TCP
localhost:34994->localhost:6379 (ESTABLISHED)
kamailio 13366 kamailio 4u IPv4 58626 0t0 TCP
localhost:34995->localhost:6379 (ESTABLISHED)
kamailio 13367 kamailio 4u IPv4 58628 0t0 TCP
localhost:34996->localhost:6379 (ESTABLISHED)
kamailio 13368 kamailio 4u IPv4 58632 0t0 TCP
localhost:34997->localhost:6379 (ESTABLISHED)
kamailio 13369 kamailio 4u IPv4 58649 0t0 TCP
localhost:35000->localhost:6379 (ESTABLISHED)
kamailio 13370 kamailio 4u IPv4 58661 0t0 TCP
localhost:35003->localhost:6379 (ESTABLISHED)
kamailio 13376 kamailio 10u IPv4 58710 0t0 TCP
localhost:35013->localhost:6379 (ESTABLISHED)
kamailio 13377 kamailio 4u IPv4 58705 0t0 TCP
localhost:35012->localhost:6379 (ESTABLISHED)
kamailio 13378 kamailio 4u IPv4 58695 0t0 TCP
localhost:35008->localhost:6379 (ESTABLISHED)
kamailio 13381 kamailio 4u IPv4 58691 0t0 TCP
localhost:35006->localhost:6379 (ESTABLISHED)
kamailio 13382 kamailio 4u IPv4 58693 0t0 TCP
localhost:35007->localhost:6379 (ESTABLISHED)
===05:28:31===
kamailio 13365 kamailio 4u IPv4 58622 0t0 TCP
localhost:34994->localhost:6379 (ESTABLISHED)
kamailio 13366 kamailio 4u IPv4 58626 0t0 TCP
localhost:34995->localhost:6379 (CLOSE_WAIT)
kamailio 13367 kamailio 4u IPv4 58628 0t0 TCP
localhost:34996->localhost:6379 (ESTABLISHED)
kamailio 13368 kamailio 4u IPv4 58632 0t0 TCP
localhost:34997->localhost:6379 (CLOSE_WAIT)
kamailio 13369 kamailio 4u IPv4 58649 0t0 TCP
localhost:35000->localhost:6379 (CLOSE_WAIT)
kamailio 13370 kamailio 4u IPv4 58661 0t0 TCP
localhost:35003->localhost:6379 (CLOSE_WAIT)
kamailio 13376 kamailio 10u IPv4 58710 0t0 TCP
localhost:35013->localhost:6379 (CLOSE_WAIT)
kamailio 13377 kamailio 4u IPv4 58705 0t0 TCP
localhost:35012->localhost:6379 (CLOSE_WAIT)
kamailio 13378 kamailio 4u IPv4 58695 0t0 TCP
localhost:35008->localhost:6379 (CLOSE_WAIT)
kamailio 13381 kamailio 4u IPv4 58691 0t0 TCP
localhost:35006->localhost:6379 (CLOSE_WAIT)
kamailio 13382 kamailio 4u IPv4 58693 0t0 TCP
localhost:35007->localhost:6379 (CLOSE_WAIT)
Regards
Javi
On Fri, Jan 13, 2012 at 9:35 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
On 1/13/12 8:00 AM, Javier Gallart wrote:
Hi all
I have started making some tests with the ndb_redis
module. So far we have not stressed the module (no more
than 5 HGET commands/second at maximum). It works well,
but with at some point it starts failing. The failures
are easily found because the logs always show this:
INFO: <core> [main.c:811]: INFO: signal 13 received
this due to a broken connection. What do you get in redis
reply and info variables?
After that the redis value is always null. If I restart
kamailio it starts working again.
I've run kamailio with debug=4 but I haven't seen more
useful information. On the redis side, I could find
nothing in the logs either, the number of clientes
connected is alway much less than the configured maximum,
Any idea?
On the other hand, if I restart redis we need to restart
kamailio to restore the connections. Is the reconnection
to redis on the roadmap?
It should not be that complex, there is the code for
initializing the connection, it should be reused for doing it
again in case of failure.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla --http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
12:10 p.m.
Hi Daniel,
On 02/17/2012 10:47 AM, Daniel-Constantin Mierla wrote:
I made a patch for server reconnect -- I had no access
to a computer
with redis lib installed for the moment, hopefully it compiles. If you
can try and tell the result, it would be great, I can commit then.
I may be able to test this patch as well. Currently compilations bails
out on attempt to redeclare redisc_reconnect_server function parameter:
CC (gcc) [M ndb_redis.so] ndb_redis_mod.o
CC (gcc) [M ndb_redis.so] redis_client.o
redis_client.c: In function ‘redisc_reconnect_server’:
redis_client.c:206:19: error: ‘rsrv’ redeclared as different kind of symbol
redis_client.c:202:46: note: previous definition of ‘rsrv’ was here
make[1]: *** [redis_client.o] Error 1
make: *** [modules] Error 1
12:39 p.m.
Hello,
thanks for testing, indeed it was an extra declaration left over. Can
you try with the new patch attached?
Cheers,
Daniel
On 2/17/12 11:10 AM, Andrew Pogrebennyk wrote:
Hi Daniel,
On 02/17/2012 10:47 AM, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
I made a patch for server reconnect -- I had no
access to a computer
with redis lib installed for the moment, hopefully it compiles. If you
can try and tell the result, it would be great, I can commit then.
I may be able
to test this patch as well. Currently compilations bails
out on attempt to redeclare redisc_reconnect_server function parameter:
CC (gcc) [M ndb_redis.so] ndb_redis_mod.o
CC (gcc) [M ndb_redis.so] redis_client.o
redis_client.c: In function ‘redisc_reconnect_server’:
redis_client.c:206:19: error: ‘rsrv’ redeclared as different kind of symbol
redis_client.c:202:46: note: previous definition of ‘rsrv’ was here
make[1]: *** [redis_client.o] Error 1
make: *** [modules] Error 1
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2:13 p.m.
Hi Daniel, Andrew
I've just tested the patch and kamailio crashes when the redis server is
stopped. This is what I could get:
-From the logs:
Feb 17 06:33:32 r-gate-test ./kamailio[23812]: ALERT: <core> [main.c:751]:
child process 23819 exited by a signal 11
Feb 17 06:33:32 r-gate-test ./kamailio[23812]: ALERT: <core> [main.c:754]:
core was generated
Feb 17 06:33:32 r-gate-test ./kamailio[23812]: INFO: <core> [main.c:766]:
INFO: terminating due to SIGCHLD
-An the backtrace:
(...)
Core was generated by `./kamailio -f ../etc/kamailio/kamailio.cfg'.
Program terminated with signal 11, Segmentation fault.
#0 redisFree (c=0x0) at hiredis.c:817
817 if (c->fd > 0)
(gdb) bt
#0 redisFree (c=0x0) at hiredis.c:817
#1 0x00007f726f035461 in redisc_reconnect_server (rsrv=0x7f7271c93ac0) at
redis_client.c:229
#2 0x00007f726f037240 in redisc_exec (srv=<value optimized out>,
cmd=0x7fffe98c6090, argv1=<value optimized out>, argv2=<value optimized
out>, argv3=<value optimized out>,
res=<value optimized out>) at redis_client.c:298
#3 0x00007f726f034f7d in w_redis_cmd3 (msg=0x7f7271d7b018, ssrv=<value
optimized out>, scmd=<value optimized out>, sres=0x7f7271d74b58
"h\341\313qr\177") at ndb_redis_mod.c:156
#4 0x0000000000417025 in do_action (h=0x7fffe98c6570, a=0x7f7271cc5248,
msg=<value optimized out>) at action.c:1134
#5 0x000000000041e58b in run_actions (h=<value optimized out>, a=<value
optimized out>, msg=<value optimized out>) at action.c:1610
#6 0x000000000041e8d4 in run_actions_safe (h=0x7fffe98c7610,
a=0x7f7271c93781, msg=0x7f7271c93780) at action.c:1662
#7 0x00000000004b731d in rval_get_int (h=0x7fffe98c7610, msg=0x0,
i=0x7fffe98c6bd8, rv=0x3, cache=0x4) at rvalue.c:920
#8 0x00000000004bb87c in rval_expr_eval_int (h=0x7fffe98c7610,
msg=0x7f7271d7b018, res=0x7fffe98c6bd8, rve=0x7f7271cc6768) at rvalue.c:1914
#9 0x0000000000417c7c in do_action (h=0x7fffe98c7610, a=0x7f7271ccb9d0,
msg=<value optimized out>) at action.c:1092
#10 0x000000000041e58b in run_actions (h=<value optimized out>, a=<value
optimized out>, msg=<value optimized out>) at action.c:1610
#11 0x0000000000417cd7 in do_action (h=0x7fffe98c7610, a=0x7f7271ccbb10,
msg=<value optimized out>) at action.c:1111
#12 0x000000000041e58b in run_actions (h=<value optimized out>, a=<value
optimized out>, msg=<value optimized out>) at action.c:1610
#13 0x000000000041795e in do_action (h=0x7fffe98c7610, a=<value optimized
out>, msg=<value optimized out>) at action.c:732
#14 0x000000000041e58b in run_actions (h=<value optimized out>, a=<value
optimized out>, msg=<value optimized out>) at action.c:1610
#15 0x000000000041e862 in run_top_route (a=0x7f7271c94888,
msg=0x7f7271d7b018, c=<value optimized out>) at action.c:1683
#16 0x0000000000498f36 in receive_msg (
buf=0x8bb100 "INVITE sip:34661574758@79.170.68.215:5060 SIP/2.0\r\nVia:
SIP/2.0/UDP 79.170.68.214:5060;branch=z9hG4bK-9451-1-0\r\nFrom: 34661574758
<sip:34661574758@79.170.68.214:5060>;tag=9451SIPpTag001\r\nTo: sut
<sip:"..., len=<value optimized out>, rcv_info=0x7fffe98c7910) at
receive.c:207
#17 0x0000000000525987 in udp_rcv_loop () at udp_server.c:544
#18 0x00000000004635f4 in main_loop () at main.c:1585
#19 0x0000000000465e62 in main (argc=3, argv=0x7fffe98c7c08) at main.c:2475
Regards
Javi
On Fri, Feb 17, 2012 at 11:39 AM, Daniel-Constantin Mierla <
miconda(a)gmail.com> wrote:
Hello,
thanks for testing, indeed it was an extra declaration left over. Can you
try with the new patch attached?
Cheers,
Daniel
On 2/17/12 11:10 AM, Andrew Pogrebennyk wrote:
Hi Daniel,
On 02/17/2012 10:47 AM, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
I made a patch for server reconnect -- I had no
access to a computer
with redis lib installed for the moment, hopefully it compiles. If you
can try and tell the result, it would be great, I can commit then.
I may be able to test this patch as well. Currently compilations bails
out on attempt to redeclare redisc_reconnect_server function parameter:
CC (gcc) [M ndb_redis.so] ndb_redis_mod.o
CC (gcc) [M ndb_redis.so] redis_client.o
redis_client.c: In function ‘redisc_reconnect_server’:
redis_client.c:206:19: error: ‘rsrv’ redeclared as different kind of
symbol
redis_client.c:202:46: note: previous definition of ‘rsrv’ was here
make[1]: *** [redis_client.o] Error 1
make: *** [modules] Error 1
______________________________**_________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**users<http:/…
3:30 p.m.
Hello,
right, very dummy paste position for resetting the redis context, use
the attached patch or exchange lines 228 and 229. in redis_client.c
Thanks,
Daniel
On 2/17/12 1:13 PM, Javier Gallart wrote:
Hi Daniel, Andrew
I've just tested the patch and kamailio crashes when the redis server
is stopped. This is what I could get:
-From the logs:
Feb 17 06:33:32 r-gate-test ./kamailio[23812]: ALERT: <core>
[main.c:751]: child process 23819 exited by a signal 11
Feb 17 06:33:32 r-gate-test ./kamailio[23812]: ALERT: <core>
[main.c:754]: core was generated
Feb 17 06:33:32 r-gate-test ./kamailio[23812]: INFO: <core>
[main.c:766]: INFO: terminating due to SIGCHLD
-An the backtrace:
(...)
Core was generated by `./kamailio -f ../etc/kamailio/kamailio.cfg'.
Program terminated with signal 11, Segmentation fault.
#0 redisFree (c=0x0) at hiredis.c:817
817 if (c->fd > 0)
(gdb) bt
#0 redisFree (c=0x0) at hiredis.c:817
#1 0x00007f726f035461 in redisc_reconnect_server
(rsrv=0x7f7271c93ac0) at redis_client.c:229
#2 0x00007f726f037240 in redisc_exec (srv=<value optimized out>,
cmd=0x7fffe98c6090, argv1=<value optimized out>, argv2=<value
optimized out>, argv3=<value optimized out>,
res=<value optimized out>) at redis_client.c:298
#3 0x00007f726f034f7d in w_redis_cmd3 (msg=0x7f7271d7b018,
ssrv=<value optimized out>, scmd=<value optimized out>,
sres=0x7f7271d74b58 "h\341\313qr\177") at ndb_redis_mod.c:156
#4 0x0000000000417025 in do_action (h=0x7fffe98c6570,
a=0x7f7271cc5248, msg=<value optimized out>) at action.c:1134
#5 0x000000000041e58b in run_actions (h=<value optimized out>,
a=<value optimized out>, msg=<value optimized out>) at action.c:1610
#6 0x000000000041e8d4 in run_actions_safe (h=0x7fffe98c7610,
a=0x7f7271c93781, msg=0x7f7271c93780) at action.c:1662
#7 0x00000000004b731d in rval_get_int (h=0x7fffe98c7610, msg=0x0,
i=0x7fffe98c6bd8, rv=0x3, cache=0x4) at rvalue.c:920
#8 0x00000000004bb87c in rval_expr_eval_int (h=0x7fffe98c7610,
msg=0x7f7271d7b018, res=0x7fffe98c6bd8, rve=0x7f7271cc6768) at
rvalue.c:1914
#9 0x0000000000417c7c in do_action (h=0x7fffe98c7610,
a=0x7f7271ccb9d0, msg=<value optimized out>) at action.c:1092
#10 0x000000000041e58b in run_actions (h=<value optimized out>,
a=<value optimized out>, msg=<value optimized out>) at action.c:1610
#11 0x0000000000417cd7 in do_action (h=0x7fffe98c7610,
a=0x7f7271ccbb10, msg=<value optimized out>) at action.c:1111
#12 0x000000000041e58b in run_actions (h=<value optimized out>,
a=<value optimized out>, msg=<value optimized out>) at action.c:1610
#13 0x000000000041795e in do_action (h=0x7fffe98c7610, a=<value
optimized out>, msg=<value optimized out>) at action.c:732
#14 0x000000000041e58b in run_actions (h=<value optimized out>,
a=<value optimized out>, msg=<value optimized out>) at action.c:1610
#15 0x000000000041e862 in run_top_route (a=0x7f7271c94888,
msg=0x7f7271d7b018, c=<value optimized out>) at action.c:1683
#16 0x0000000000498f36 in receive_msg (
buf=0x8bb100 "INVITE sip:34661574758@79.170.68.215:5060
<http://sip:34661574758@79.170.68.215:5060> SIP/2.0\r\nVia:
SIP/2.0/UDP 79.170.68.214:5060;branch=z9hG4bK-9451-1-0\r\nFrom:
34661574758 <sip:34661574758@79.170.68.214:5060
<http://sip:34661574758@79.170.68.214:5060>>;tag=9451SIPpTag001\r\nTo:
sut <sip:"..., len=<value optimized out>, rcv_info=0x7fffe98c7910) at
receive.c:207
#17 0x0000000000525987 in udp_rcv_loop () at udp_server.c:544
#18 0x00000000004635f4 in main_loop () at main.c:1585
#19 0x0000000000465e62 in main (argc=3, argv=0x7fffe98c7c08) at
main.c:2475
Regards
Javi
On Fri, Feb 17, 2012 at 11:39 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
thanks for testing, indeed it was an extra declaration left over.
Can you try with the new patch attached?
Cheers,
Daniel
On 2/17/12 11:10 AM, Andrew Pogrebennyk wrote:
Hi Daniel,
On 02/17/2012 10:47 AM, Daniel-Constantin Mierla wrote:
I made a patch for server reconnect -- I had no access to
a computer
with redis lib installed for the moment, hopefully it
compiles. If you
can try and tell the result, it would be great, I can
commit then.
I may be able to test this patch as well. Currently
compilations bails
out on attempt to redeclare redisc_reconnect_server function
parameter:
CC (gcc) [M ndb_redis.so] ndb_redis_mod.o
CC (gcc) [M ndb_redis.so] redis_client.o
redis_client.c: In function 'redisc_reconnect_server':
redis_client.c:206:19: error: 'rsrv' redeclared as different
kind of symbol
redis_client.c:202:46: note: previous definition of 'rsrv' was
here
make[1]: *** [redis_client.o] Error 1
make: *** [modules] Error 1
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
4:08 p.m.
Thanks Daniel
On Fri, Feb 17, 2012 at 2:30 PM, Daniel-Constantin Mierla <miconda(a)gmail.com
wrote:
Hello,
right, very dummy paste position for resetting the redis context, use the
attached patch or exchange lines 228 and 229. in redis_client.c
It works perfectly well now.:
ERROR: ndb_redis [redis_client.c:246]: error communicating with redis
server [redis1] (127.0.0.1:6379/0): Connection refused
After recovering the redis server everything works as expected again.
Regards
Javi
> Thanks,
> Daniel
>
>
>
> On 2/17/12 1:13 PM, Javier Gallart wrote:
>
> Hi Daniel, Andrew
>
> I've just tested the patch and kamailio crashes when the redis server is
> stopped. This is what I could get:
> -From the logs:
> Feb 17 06:33:32 r-gate-test ./kamailio[23812]: ALERT: <core>
> [main.c:751]: child process 23819 exited by a signal 11
> Feb 17 06:33:32 r-gate-test ./kamailio[23812]: ALERT: <core> [main.c:754]:
> core was generated
> Feb 17 06:33:32 r-gate-test ./kamailio[23812]: INFO: <core> [main.c:766]:
> INFO: terminating due to SIGCHLD
>
> -An the backtrace:
> (...)
> Core was generated by `./kamailio -f ../etc/kamailio/kamailio.cfg'.
> Program terminated with signal 11, Segmentation fault.
> #0 redisFree (c=0x0) at hiredis.c:817
> 817 if (c->fd > 0)
> (gdb) bt
> #0 redisFree (c=0x0) at hiredis.c:817
> #1 0x00007f726f035461 in redisc_reconnect_server (rsrv=0x7f7271c93ac0) at
> redis_client.c:229
> #2 0x00007f726f037240 in redisc_exec (srv=<value optimized out>,
> cmd=0x7fffe98c6090, argv1=<value optimized out>, argv2=<value optimized
> out>, argv3=<value optimized out>,
> res=<value optimized out>) at redis_client.c:298
> #3 0x00007f726f034f7d in w_redis_cmd3 (msg=0x7f7271d7b018, ssrv=<value
> optimized out>, scmd=<value optimized out>, sres=0x7f7271d74b58
> "h\341\313qr\177") at ndb_redis_mod.c:156
> #4 0x0000000000417025 in do_action (h=0x7fffe98c6570, a=0x7f7271cc5248,
> msg=<value optimized out>) at action.c:1134
> #5 0x000000000041e58b in run_actions (h=<value optimized out>, a=<value
> optimized out>, msg=<value optimized out>) at action.c:1610
> #6 0x000000000041e8d4 in run_actions_safe (h=0x7fffe98c7610,
> a=0x7f7271c93781, msg=0x7f7271c93780) at action.c:1662
> #7 0x00000000004b731d in rval_get_int (h=0x7fffe98c7610, msg=0x0,
> i=0x7fffe98c6bd8, rv=0x3, cache=0x4) at rvalue.c:920
> #8 0x00000000004bb87c in rval_expr_eval_int (h=0x7fffe98c7610,
> msg=0x7f7271d7b018, res=0x7fffe98c6bd8, rve=0x7f7271cc6768) at rvalue.c:1914
> #9 0x0000000000417c7c in do_action (h=0x7fffe98c7610, a=0x7f7271ccb9d0,
> msg=<value optimized out>) at action.c:1092
> #10 0x000000000041e58b in run_actions (h=<value optimized out>, a=<value
> optimized out>, msg=<value optimized out>) at action.c:1610
> #11 0x0000000000417cd7 in do_action (h=0x7fffe98c7610, a=0x7f7271ccbb10,
> msg=<value optimized out>) at action.c:1111
> #12 0x000000000041e58b in run_actions (h=<value optimized out>, a=<value
> optimized out>, msg=<value optimized out>) at action.c:1610
> #13 0x000000000041795e in do_action (h=0x7fffe98c7610, a=<value optimized
> out>, msg=<value optimized out>) at action.c:732
> #14 0x000000000041e58b in run_actions (h=<value optimized out>, a=<value
> optimized out>, msg=<value optimized out>) at action.c:1610
> #15 0x000000000041e862 in run_top_route (a=0x7f7271c94888,
> msg=0x7f7271d7b018, c=<value optimized out>) at action.c:1683
> #16 0x0000000000498f36 in receive_msg (
> buf=0x8bb100 "INVITE sip:34661574758@79.170.68.215:5060SIP/2.0\r\nVia:
SIP/2.0/UDP 79.170.68.214:5060;branch=z9hG4bK-9451-1-0\r\nFrom:
> 34661574758 <sip:34661574758@79.170.68.214:5060>;tag=9451SIPpTag001\r\nTo:
> sut <sip:"..., len=<value optimized out>, rcv_info=0x7fffe98c7910) at
> receive.c:207
> #17 0x0000000000525987 in udp_rcv_loop () at udp_server.c:544
> #18 0x00000000004635f4 in main_loop () at main.c:1585
> #19 0x0000000000465e62 in main (argc=3, argv=0x7fffe98c7c08) at main.c:2475
>
>
> Regards
>
> Javi
>
> On Fri, Feb 17, 2012 at 11:39 AM, Daniel-Constantin Mierla <
> miconda(a)gmail.com wrote:
>
>> Hello,
>>
>> thanks for testing, indeed it was an extra declaration left over. Can you
>> try with the new patch attached?
>>
>> Cheers,
>> Daniel
>>
>>
>> On 2/17/12 11:10 AM, Andrew Pogrebennyk wrote:
>>
>>> Hi Daniel,
>>>
>>> On 02/17/2012 10:47 AM, Daniel-Constantin Mierla wrote:
>>>
>>>> I made a patch for server reconnect -- I had no access to a computer
>>>> with redis lib installed for the moment, hopefully it compiles. If you
>>>> can try and tell the result, it would be great, I can commit then.
>>>>
>>> I may be able to test this patch as well. Currently compilations bails
>>> out on attempt to redeclare redisc_reconnect_server function parameter:
>>>
>>> CC (gcc) [M ndb_redis.so] ndb_redis_mod.o
>>> CC (gcc) [M ndb_redis.so] redis_client.o
>>> redis_client.c: In function ‘redisc_reconnect_server’:
>>> redis_client.c:206:19: error: ‘rsrv’ redeclared as different kind of
>>> symbol
>>> redis_client.c:202:46: note: previous definition of ‘rsrv’ was here
>>> make[1]: *** [redis_client.o] Error 1
>>> make: *** [modules] Error 1
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users(a)lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>
>> --
>> Daniel-Constantin Mierla -- http://www.asipto.com
>> http://linkedin.com/in/miconda -- http://twitter.com/miconda
>>
>>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierla -- http://www.asipto.comhttp://linkedin.com/in/miconda --
http://twitter.com/miconda
>
>
4:48 p.m.
Hello,
thanks for testing and feedback. Latest patch was just committed on
master branch.
Cheers,
Daniel
On 2/17/12 3:08 PM, Javier Gallart wrote:
Thanks Daniel
On Fri, Feb 17, 2012 at 2:30 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
right, very dummy paste position for resetting the redis context,
use the attached patch or exchange lines 228 and 229. in
redis_client.c
It works perfectly well now.:
ERROR: ndb_redis [redis_client.c:246]: error communicating with redis
server [redis1] (127.0.0.1:6379/0 <http://127.0.0.1:6379/0>):
Connection refused
After recovering the redis server everything works as expected again.
Regards
Javi
Thanks,
Daniel
On 2/17/12 1:13 PM, Javier Gallart wrote:
Hi Daniel, Andrew
I've just tested the patch and kamailio crashes when the redis
server is stopped. This is what I could get:
-From the logs:
Feb 17 06:33:32 r-gate-test ./kamailio[23812]: ALERT: <core>
[main.c:751]: child process 23819 exited by a signal 11
Feb 17 06:33:32 r-gate-test ./kamailio[23812]: ALERT: <core>
[main.c:754]: core was generated
Feb 17 06:33:32 r-gate-test ./kamailio[23812]: INFO: <core>
[main.c:766]: INFO: terminating due to SIGCHLD
-An the backtrace:
(...)
Core was generated by `./kamailio -f ../etc/kamailio/kamailio.cfg'.
Program terminated with signal 11, Segmentation fault.
#0 redisFree (c=0x0) at hiredis.c:817
817 if (c->fd > 0)
(gdb) bt
#0 redisFree (c=0x0) at hiredis.c:817
#1 0x00007f726f035461 in redisc_reconnect_server
(rsrv=0x7f7271c93ac0) at redis_client.c:229
#2 0x00007f726f037240 in redisc_exec (srv=<value optimized out>,
cmd=0x7fffe98c6090, argv1=<value optimized out>, argv2=<value
optimized out>, argv3=<value optimized out>,
res=<value optimized out>) at redis_client.c:298
#3 0x00007f726f034f7d in w_redis_cmd3 (msg=0x7f7271d7b018,
ssrv=<value optimized out>, scmd=<value optimized out>,
sres=0x7f7271d74b58 "h\341\313qr\177") at ndb_redis_mod.c:156
#4 0x0000000000417025 in do_action (h=0x7fffe98c6570,
a=0x7f7271cc5248, msg=<value optimized out>) at action.c:1134
#5 0x000000000041e58b in run_actions (h=<value optimized out>,
a=<value optimized out>, msg=<value optimized out>) at action.c:1610
#6 0x000000000041e8d4 in run_actions_safe (h=0x7fffe98c7610,
a=0x7f7271c93781, msg=0x7f7271c93780) at action.c:1662
#7 0x00000000004b731d in rval_get_int (h=0x7fffe98c7610,
msg=0x0, i=0x7fffe98c6bd8, rv=0x3, cache=0x4) at rvalue.c:920
#8 0x00000000004bb87c in rval_expr_eval_int (h=0x7fffe98c7610,
msg=0x7f7271d7b018, res=0x7fffe98c6bd8, rve=0x7f7271cc6768) at
rvalue.c:1914
#9 0x0000000000417c7c in do_action (h=0x7fffe98c7610,
a=0x7f7271ccb9d0, msg=<value optimized out>) at action.c:1092
#10 0x000000000041e58b in run_actions (h=<value optimized out>,
a=<value optimized out>, msg=<value optimized out>) at action.c:1610
#11 0x0000000000417cd7 in do_action (h=0x7fffe98c7610,
a=0x7f7271ccbb10, msg=<value optimized out>) at action.c:1111
#12 0x000000000041e58b in run_actions (h=<value optimized out>,
a=<value optimized out>, msg=<value optimized out>) at action.c:1610
#13 0x000000000041795e in do_action (h=0x7fffe98c7610, a=<value
optimized out>, msg=<value optimized out>) at action.c:732
#14 0x000000000041e58b in run_actions (h=<value optimized out>,
a=<value optimized out>, msg=<value optimized out>) at action.c:1610
#15 0x000000000041e862 in run_top_route (a=0x7f7271c94888,
msg=0x7f7271d7b018, c=<value optimized out>) at action.c:1683
#16 0x0000000000498f36 in receive_msg (
buf=0x8bb100 "INVITE sip:34661574758@79.170.68.215:5060
<http://sip:34661574758@79.170.68.215:5060> SIP/2.0\r\nVia:
SIP/2.0/UDP 79.170.68.214:5060;branch=z9hG4bK-9451-1-0\r\nFrom:
34661574758 <sip:34661574758@79.170.68.214:5060
<http://sip:34661574758@79.170.68.214:5060>>;tag=9451SIPpTag001\r\nTo:
sut <sip:"..., len=<value optimized out>,
rcv_info=0x7fffe98c7910) at receive.c:207
#17 0x0000000000525987 in udp_rcv_loop () at udp_server.c:544
#18 0x00000000004635f4 in main_loop () at main.c:1585
#19 0x0000000000465e62 in main (argc=3, argv=0x7fffe98c7c08) at
main.c:2475
Regards
Javi
On Fri, Feb 17, 2012 at 11:39 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
thanks for testing, indeed it was an extra declaration left
over. Can you try with the new patch attached?
Cheers,
Daniel
On 2/17/12 11:10 AM, Andrew Pogrebennyk wrote:
Hi Daniel,
On 02/17/2012 10:47 AM, Daniel-Constantin Mierla wrote:
I made a patch for server reconnect -- I had no
access to a computer
with redis lib installed for the moment, hopefully it
compiles. If you
can try and tell the result, it would be great, I can
commit then.
I may be able to test this patch as well. Currently
compilations bails
out on attempt to redeclare redisc_reconnect_server
function parameter:
CC (gcc) [M ndb_redis.so] ndb_redis_mod.o
CC (gcc) [M ndb_redis.so] redis_client.o
redis_client.c: In function 'redisc_reconnect_server':
redis_client.c:206:19: error: 'rsrv' redeclared as
different kind of symbol
redis_client.c:202:46: note: previous definition of
'rsrv' was here
make[1]: *** [redis_client.o] Error 1
make: *** [modules] Error 1
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) -
sr-users mailing list
sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla --http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
4665
days inactive
4700
days old
12 comments
3 participants
participants (3)
-
Andrew Pogrebennyk -
Daniel-Constantin Mierla -
Javier Gallart