Hello all,
Daniel-Constantin Mierla schrieb:
Hello Christian,
On 06/09/2009 04:56 PM, Christian Koch wrote:
Hello Daniel,
Daniel-Constantin Mierla schrieb:
unfortunately you cannot use $sht in this way
from perl module. The
same limitation that prevent calling any function from modules apply
here -- the fixup system used at startup, when string parameters are
pre-compiled in different forms to speed up runtime execution.
So there is no way
to access $sht from other moduls (like perl or
xlog)? It seems to work, but obviously the memory isn't freed :-)
you could
access it by adding some sht extensions to the Perl API,
same way as for AVP, but this requires development as well.
From other modules is easier, as one can evaluate the name and then do
search in the hashtable.
We tried the solution suggested by Mik (copy $sht-values
to AVP in
config file and accessing only AVPs from perl) and made about 20.000
calls without any problems. Seems that solved our problem. Thanks a lot!!!
What we are trying to do is the following:
During processing of "INVITE" we need to save some call details
(source IP, URI, ...) and want to write them to file when the call is
finished (including duration, ...), while processing BYE or CANCEL,
to have CDRs. As there are multiple childs of kamailio we tried to
save the calls details from the INVITE in shared memory using htable
(e.g. "$sht(a=>$ci::srcip) = $si"), so we can use them while
processing the BYE (possibly in another child). There we wanted to
use perl to be able to write the saved details to a file.
We used the shared memory module as we donĀ“t want to save the infos
to DB because of performance issues we suspect when using DBs.
But as you mentioned $sht is not supposed to be used in such a way.
Do you have any idea what else we can do to generate CDRs as mentioned?
By using other modules for example or a complete other way you may know?
You can use shared memory from perl, see persistence.pl in
modules/perl/doc/samples/
Well, we've already tried that. But it occurred several times, that
after about two weeks the shared memory got corrupted and we had to
reboot the machine. It seems "IPC::Shareable" is not ready for
production use. We also tried "IPC::ShareLite" instead of
"IPC::Shareable". "IPC::ShareLite" seems to be newer, better
maintained
and supported. But we had no success fetching saved values from shared
memory - probably we didn't use it the right way.
Regards,
Christian