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