21 Feb
2015
21 Feb
'15
7:47 p.m.
Good day. Is anyone able to let me in on what this means "WARNING: <core>
[local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer added"? I just
started seeing this after pulling down 5c1a9df from git and it seems like
something that I probably don't want happening.
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
22 Feb
22 Feb
1:09 a.m.
On Saturday, February 21, 2015 12:47:08 PM Anthony Messina wrote:
Good day. Is anyone able to let me in on what this
means "WARNING: <core>
[local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer added"? I just
started seeing this after pulling down 5c1a9df from git and it seems like
something that I probably don't want happening.
It appears that the tcpops.so module must be loaded to prevent these timer
errors, even if not using any of the functions provided by the module. Is
this the future intention?
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
12:16 p.m.
New subject: WARNING: <core> [local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer added"?
Hello,
On 22/02/15 01:09, Anthony Messina wrote:
On Saturday, February 21, 2015 12:47:08 PM Anthony
Messina wrote:
You are running master branch (devel version), right?
The tcpops module is new and probably this issue is due to its latest
addition to allow custom lifetime value per tcp connection. It has to be
fixed to work without a need to load tcpops module, perhaps Camile will
look at it next week.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
Good day. Is anyone able to let me in on what
this means "WARNING: <core>
[local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer added"? I just
started seeing this after pulling down 5c1a9df from git and it seems like
something that I probably don't want happening.
It appears that the tcpops.so
module must be loaded to prevent these timer
errors, even if not using any of the functions provided by the module. Is
this the future intention?
6:05 p.m.
On Sunday, February 22, 2015 12:16:33 PM Daniel-Constantin Mierla wrote:
Hello,
On 22/02/15 01:09, Anthony Messina wrote:
Yes.
On Saturday, February 21, 2015 12:47:08 PM
Anthony Messina wrote:
You are running master branch (devel version), right? Good day. Is anyone able to let me in on what
this means "WARNING:
<core>
[local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer added"? I
just
started seeing this after pulling down 5c1a9df from git and it seems
like
something that I probably don't want happening.
It appears that the tcpops.so module must be loaded to prevent these
timer
errors, even if not using any of the functions provided by the
module. Is
this the future intention? The tcpops module is new and probably this issue is
due to its latest
addition to allow custom lifetime value per tcp connection. It has to be
fixed to work without a need to load tcpops module, perhaps Camile will
look at it next week.
Cheers,
Daniel
Thanks Daniel and Camille, that's what I was thinking. I can report that
tcp_set_connection_lifetime is working nicely. -A
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
26 Feb
26 Feb
11:44 a.m.
New subject: WARNING: <core> [local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer added"?
Le Sat, 21 Feb 2015 18:09:19 -0600,
Anthony Messina <amessina(a)messinet.com> a écrit :
Hi Anthony,
Do you know under which circumstances this warning appears? I'd like to
reproduce it and investigate, but I can't reproduce it for the moment.
I made some changes in the core for connection lifetime that will
affect some timers, but I'm surprised that just loading the tcpops
module would change anything, since the init code of the module does
nothing.
--
Camille
Good day. Is
anyone able to let me in on what this means "WARNING:
<core> [local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer
added"? I just started seeing this after pulling down 5c1a9df from
git and it seems like something that I probably don't want
happening.
It appears that the tcpops.so module must be loaded to prevent these
timer errors, even if not using any of the functions provided by the
module. Is this the future intention?
27 Feb
27 Feb
11:53 a.m.
New subject: WARNING: <core> [local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer added"?
Le Sat, 21 Feb 2015 12:47:08 -0600,
Anthony Messina <amessina(a)messinet.com> a écrit :
Good day. Is anyone able to let me in on what this
means "WARNING:
<core> [local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer
added"? I just started seeing this after pulling down 5c1a9df from
git and it seems like something that I probably don't want happening.
Hi Anthony,
Are you using TLS? I've just sent a patch to master that will fix an
issue I introduced with the per-socket lifetime on TLS connections. Can
you try it?
--
Camille
2:08 p.m.
On Friday, February 27, 2015 11:53:22 Camille Oudot wrote:
Le Sat, 21 Feb 2015 12:47:08 -0600,
Anthony Messina <amessina(a)messinet.com> a écrit :
Thanks Camille. I am using TLS, but I've had some long days at work. I'll
rebuild and give it a shot this weekend. -A
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
Good day. Is anyone able to let me in on what
this means "WARNING:
<core> [local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer
added"? I just started seeing this after pulling down 5c1a9df from
git and it seems like something that I probably don't want happening.
Hi Anthony,
Are you using TLS? I've just sent a patch to master that will fix an
issue I introduced with the per-socket lifetime on TLS connections. Can
you try it?
--
Camille
1 Mar
1 Mar
10:54 p.m.
On Friday, February 27, 2015 07:08:05 AM Anthony Messina wrote:
On Friday, February 27, 2015 11:53:22 Camille Oudot
wrote:
I no longer see this issue. Thank you. I've added a check in onreply_route
for $avp(caller_conid)!=$null since it appears the AVP isn't always available
for some reason. -A
#!ifdef WITH_TCPOPS
if(proto!=UDP && status=="200") {
if(is_method("INVITE")) {
# enable on callee's connection
tcp_keepalive_enable("60", "5",
"5");
# enable on caller's connection
if($avp(caller_conid)!=$null)
tcp_keepalive_enable("$avp(caller_conid)",
"60", "5", "2");
}
if(is_method("BYE")) {
tcp_keepalive_disable();
tcp_keepalive_disable("$avp(bye_conid)");
}
}
#!endif
}
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
Le Sat, 21 Feb 2015 12:47:08 -0600,
Anthony Messina <amessina(a)messinet.com> a écrit :
Thanks Camille. I am using TLS, but I've had some long days at work. I'll
rebuild and give it a shot this weekend. -A Good day. Is anyone able to let me in on what
this means "WARNING:
<core> [local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer
added"? I just started seeing this after pulling down 5c1a9df from
git and it seems like something that I probably don't want happening.
Hi Anthony,
Are you using TLS? I've just sent a patch to master that will fix an
issue I introduced with the per-socket lifetime on TLS connections. Can
you try it?
--
Camille
2 Mar
2 Mar
8:41 a.m.
New subject: WARNING: <core> [local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer added"?
On 01/03/15 22:54, Anthony Messina wrote:
On Friday, February 27, 2015 07:08:05 AM Anthony
Messina wrote:
AVPs are available only the transaction transaction. It is in
onreply_route[abc], not in reply_route. Also, what you set for INVITE
transaction is not in the other requests of other transactions in the
same call (such as BYE) -- use dialog vars for that.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
On Friday, February 27, 2015 11:53:22 Camille
Oudot wrote:
I no longer see this issue. Thank
you. I've added a check in onreply_route
for $avp(caller_conid)!=$null since it appears the AVP isn't always available
for some reason. -A
#!ifdef WITH_TCPOPS
if(proto!=UDP && status=="200") {
if(is_method("INVITE")) {
# enable on callee's connection
tcp_keepalive_enable("60", "5",
"5");
# enable on caller's connection
if($avp(caller_conid)!=$null)
tcp_keepalive_enable("$avp(caller_conid)",
"60", "5", "2");
}
if(is_method("BYE")) {
tcp_keepalive_disable();
tcp_keepalive_disable("$avp(bye_conid)");
}
}
#!endif
} Le Sat, 21 Feb 2015 12:47:08 -0600,
Anthony Messina <amessina(a)messinet.com> a écrit :
Thanks Camille. I am using TLS, but I've had some long days at work.
I'll
rebuild and give it a shot this weekend. -A Good day. Is anyone able to let me in on what
this means "WARNING:
<core> [local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer
added"? I just started seeing this after pulling down 5c1a9df from
git and it seems like something that I probably don't want happening.
Hi Anthony,
Are you using TLS? I've just sent a patch to master that will fix an
issue I introduced with the per-socket lifetime on TLS connections. Can
you try it?
--
Camille
12:15 p.m.
On Monday, March 02, 2015 08:41:27 Daniel-Constantin Mierla wrote:
On 01/03/15 22:54, Anthony Messina wrote:
Thanks Daniel. The TCP Ops module README will probably need some updates
then. My example above is sourced from there.
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
On Friday, February 27, 2015 07:08:05 AM Anthony
Messina wrote:
AVPs are available only the transaction transaction. It is in
onreply_route[abc], not in reply_route. Also, what you set for INVITE
transaction is not in the other requests of other transactions in the
same call (such as BYE) -- use dialog vars for that.
Cheers,
Daniel On Friday, February 27, 2015 11:53:22 Camille
Oudot wrote:
I no longer see this issue. Thank you. I've added a check in
onreply_route for $avp(caller_conid)!=$null since it appears the AVP
isn't always available for some reason. -A
#!ifdef WITH_TCPOPS
if(proto!=UDP && status=="200") {
if(is_method("INVITE")) {
# enable on callee's connection
tcp_keepalive_enable("60", "5",
"5");
# enable on caller's connection
if($avp(caller_conid)!=$null)
tcp_keepalive_enable("$avp(caller_conid)",
"60", "5", "2");
}
if(is_method("BYE")) {
tcp_keepalive_disable();
tcp_keepalive_disable("$avp(bye_conid)");
}
}
#!endif
} Le Sat, 21 Feb 2015 12:47:08 -0600,
Anthony Messina <amessina(a)messinet.com> a écrit :
> Good day. Is anyone able to let me in on what this means "WARNING:
> <core> [local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer
> added"? I just started seeing this after pulling down 5c1a9df from
> git and it seems like something that I probably don't want happening.
Hi Anthony,
Are you using TLS? I've just sent a patch to master that will fix an
issue I introduced with the per-socket lifetime on TLS connections. Can
you try it?
Thanks Camille. I am using TLS, but I've had some long days at work.
I'll
rebuild and give it a shot this weekend. -A
2:57 p.m.
New subject: WARNING: <core> [local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer added"?
Le Mon, 2 Mar 2015 05:15:09 -0600,
Anthony Messina <amessina(a)messinet.com> a écrit :
Thanks Daniel. The TCP Ops module README will
probably need some
updates then. My example above is sourced from there.
Hi Anthony,
the AVP must be accessed in a TM callback. The example is not correct,
i'll fix it.
Thanks for your feedback.
--
Camille
5 Mar
5 Mar
2:44 a.m.
On Monday, March 02, 2015 08:41:27 AM Daniel-Constantin Mierla wrote:
On 01/03/15 22:54, Anthony Messina wrote:
Thanks Daniel. I do have the above in my onreply_route[MANAGE_REPLY], and
have set t_on_reply("MANAGE_REPLY"). Are you saying that $avp(caller_conid)
when set on the initial INVITE, for example, wouldn't be available in the
onreply_route to the INVITE? If so, the examples in the TCP Ops README will
need to reflect the need for using dialog vars instead.
By the way, I'm only using if(proto!=UDP) since the TCP Ops module checks
whether or not it can apply itself, but also logs each time it does so. Is it
more efficient for the script to introduce the check for the proto (avoiding
the clutter in the logs), or more efficient for the module to just return when
it isn't applicable?
request_route {
...
#!ifdef WITH_TCPOPS
if(proto!=UDP) {
if(is_method("INVITE"))
$avp(caller_conid)=$conid;
if(is_method("BYE"))
$avp(bye_conid)=$conid;
}
#!endif
...
}
# Manage incoming replies
onreply_route[MANAGE_REPLY] {
xdbg("incoming reply\n");
if(status=~"[12][0-9][0-9]")
route(NATMANAGE);
#!ifdef WITH_TCPOPS
if(proto!=UDP && status=="200") {
if(is_method("INVITE")) {
# enable on callee's connection
tcp_keepalive_enable("60", "5",
"5");
# enable on caller's connection
if($avp(caller_conid)!=$null)
tcp_keepalive_enable("$avp(caller_conid)",
"60", "5", "2");
}
if(is_method("BYE")) {
tcp_keepalive_disable();
tcp_keepalive_disable("$avp(bye_conid)");
}
}
#!endif
}
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
On Friday, February 27, 2015 07:08:05 AM Anthony
Messina wrote:
"60", "5",
"2");
}
if(is_method("BYE")) {
tcp_keepalive_disable();
tcp_keepalive_disable("$avp(bye_conid)");
}
}
#!endif
}
AVPs are available only the transaction transaction. It is in
onreply_route[abc], not in reply_route. Also, what you set for INVITE
transaction is not in the other requests of other transactions in the
same call (such as BYE) -- use dialog vars for that.
Cheers,
Daniel On Friday, February 27, 2015 11:53:22 Camille
Oudot wrote:
I no longer see this issue. Thank you. I've added a check in
onreply_route for $avp(caller_conid)!=$null since it appears the AVP
isn't always available for some reason. -A
#!ifdef WITH_TCPOPS
if(proto!=UDP && status=="200") {
if(is_method("INVITE")) {
# enable on callee's connection
tcp_keepalive_enable("60", "5",
"5");
# enable on caller's connection
if($avp(caller_conid)!=$null)
tcp_keepalive_enable("$avp(caller_conid)",
Le Sat, 21 Feb 2015 12:47:08 -0600,
Anthony Messina <amessina(a)messinet.com> a écrit :
> Good day. Is anyone able to let me in on what this means "WARNING:
> <core> [local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer
> added"? I just started seeing this after pulling down 5c1a9df from
> git and it seems like something that I probably don't want happening.
Hi Anthony,
Are you using TLS? I've just sent a patch to master that will fix an
issue I introduced with the per-socket lifetime on TLS connections. Can
you try it?
--
Camille
Thanks Camille. I am using TLS, but I've had some long days at
work. I'll rebuild and give it a shot this weekend. -A
12:34 p.m.
New subject: WARNING: <core> [local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer added"?
Are you saying that $avp(caller_conid) when set on the
initial
INVITE, for example, wouldn't be available in the onreply_route to
the INVITE? If so, the examples in the TCP Ops README will need to
reflect the need for using dialog vars instead.
Hi Anthony,
the AVP you set on a request will be available in the onreply_routes
that have been registered with t_on_reply().
The example in the tcpops readme uses some AVPs, but you might of
course need different ways of memorizing connection information that
fits your specific needs (stateless, dialog-aware, use a database, a
hashatable, ...).
By the way, I'm only using if(proto!=UDP) since
the TCP Ops module
checks whether or not it can apply itself, but also logs each time it
does so. Is it more efficient for the script to introduce the check
for the proto (avoiding the clutter in the logs), or more efficient
for the module to just return when it isn't applicable?
The messages complaining about the connection not being a TCP connection
use the ERROR log level, because I felt like calling these TCP tuning
functions on something else than TCP should not remain unnoticed and
should be fixed at script level.
I would recommend that you keep this logic in your script, and in your
case, "if(proto!=UDP)" is efficient (probably more than writing a log
line).
--
Camille
12:43 p.m.
On Thursday, March 05, 2015 12:34:36 PM Camille Oudot wrote:
Thanks, Camille, then I should be all set as I am calling
onreply_route[MANAGE_REPLY].
Again, thank you. BTW, I'm looking forward to
modparam("usrloc", "close_expired_tcp", 1) when I rebuild later...
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
Are you saying
that $avp(caller_conid) when set on the initial
INVITE, for example, wouldn't be available in the onreply_route to
the INVITE? If so, the examples in the TCP Ops README will need to
reflect the need for using dialog vars instead.
Hi Anthony,
the AVP you set on a request will be available in the onreply_routes
that have been registered with t_on_reply().
The example in the tcpops readme uses some AVPs, but you might of
course need different ways of memorizing connection information that
fits your specific needs (stateless, dialog-aware, use a database, a
hashatable, ...). By the way,
I'm only using if(proto!=UDP) since the TCP Ops module
checks whether or not it can apply itself, but also logs each time it
does so. Is it more efficient for the script to introduce the check
for the proto (avoiding the clutter in the logs), or more efficient
for the module to just return when it isn't applicable?
The messages complaining about the connection not being a TCP connection
use the ERROR log level, because I felt like calling these TCP tuning
functions on something else than TCP should not remain unnoticed and
should be fixed at script level.
I would recommend that you keep this logic in your script, and in your
case, "if(proto!=UDP)" is efficient (probably more than writing a log
line).
3352
days inactive
3364
days old
13 comments
3 participants
participants (3)
-
Anthony Messina -
Camille Oudot -
Daniel-Constantin Mierla