28 Jul
2010
28 Jul
'10
6:08 p.m.
2010/7/28 Jon Bonilla <manwe(a)aholab.ehu.es>es>:
I do not know from the programmer point of view if
this approach is feasible.
I've coded a very similar solution for a personal project and works
really well under scenarios with high traffic so I consider it
feasible, I just wonder if it's feasible from the current Kamailio
design point of view.
But kamailio is never the only process running in a
system. Other processes as
cron, a mta, ssh server (at least) run in the same machine. If syslog is
blocked, you might get a frozen system anyways. Almost every service relies on
syslog, which makes this solution incomplete.
Sure, but anyway I don't care ssh, a mta (never running in my kamailio
servers!) or cron (just to rotate logs, no more). If kamailio remains
working that's what I need :)
I think that the solution to this problem is in
syslog's side. It's a critical
service in any system and this solution would just mask the problem.
Don't think in my suggestion just from the point of view of
"reliability" but also think in "efficience":
Currently a kamailio worker must wait for the syslog() call to return
before continuing processing the SIP message (blocking design). Using
a posix queue the worker sends the log to it which is not a blocking
call. Just the kamailio syslogger process should have to deal with
syslog daemon.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>