[SR-Users] pseudovariable values written from app_lua sometimes appear incorrect

elactrum at jamailca.com elactrum at jamailca.com
Fri Oct 5 19:54:32 CEST 2012


On 2012-09-27 11:05, elactrum at jamailca.com wrote:
> On 2012-09-27 10:19, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> On 9/26/12 9:47 PM, elactrum at jamailca.com wrote:
>>> Hi,
>>>
>>> I am using app_lua to frequently store some data in htable and avp 
>>> entries, using sr.pv.sets. When I read the values using sr.pv.get 
>>> immediately after writing them, they seem correct. However, when I 
>>> read them later from Lua, I have noticed that sometimes the value is 
>>> incorrect or nil. Am I doing something wrong?
>>>
>>> The following code uses rtimer to duplicate the problem on startup, 
>>> printing the errors to syslog.
>>>
>>> Tested on version: kamailio 3.3.1 (i386/linux) 2d0f6f
>>>
>>> ###############
>>> # kamailio.cfg
>>> ###############
>>> loadmodule    "pv.so"
>>> loadmodule    "xlog.so"
>>> loadmodule    "htable.so"
>>> loadmodule    "rtimer.so"
>>> loadmodule    "app_lua"
>>>
>>> modparam("htable", "htable", "status=>size=14;autoexpire=0;")
>>>
>>> modparam("rtimer", "timer", "name=ta;interval=10;mode=1")
>>> modparam("rtimer", "exec", "timer=ta;route=LUA_TEST")
>>>
>>> # the following path may need to change depending on filesystem 
>>> setup
>>> modparam("app_lua", "load", "/etc/kamailio/kamailio.lua")
>>>
>>> route
>>> {
>>>     route(LUA_TEST);
>>> }
>>>
>>> route[LUA_TEST] {
>>>
>>>         $var(lua_test_key) = $(pp{s.toupper}) + "::";
>>> lua_runstring("htable_test([[status=>$var(lua_test_key)]])");
>>> lua_runstring("avp_test([[status=>$var(lua_test_key)]])");
>>>
>>> }
>>>
>>> ----------------
>>> -- kamailio.lua
>>> ----------------
>>> -- Test of sr.pv operations in Lua
>>>
>>> function htable_test (namekey)
>>>     local pvar_prefix = "$sht("..namekey
>>>     pvar_test(pvar_prefix)
>>> end
>>>
>>> function avp_test ( name )
>>>     local pvar_prefix = "$avp("..name
>>>     pvar_test(pvar_prefix)
>>> end
>>>
>>>
>>> function pvar_test ( pvar_prefix )
>>>
>>>     for value = 10000, 10050 do
>>>         local pvar = pvar_prefix..value..")"
>>>         --sr.log("info", "Lua attempting to set '"..pvar.."' to 
>>> value '"..value.."'")
>>>         sr.pv.sets(pvar, value)
>>>     end
>>>
>>>     for value = 10000, 10050 do
>>>         -- now we check what was stored
>>>         local pvar = pvar_prefix..value..")"
>>>         local checkvar = sr.pv.get(pvar)
>>>         if ( tostring(checkvar) ~= tostring(value) ) then
>>>             sr.err(string.format("CHECK: Lua checking pvar '%s' and 
>>> got value '%s' which is NOT '%s'",
>>>                 tostring(pvar),
>>>                 tostring(checkvar),
>>>                 tostring(value)
>>>             ))
>>>         end
>>>
>>>     end
>>> end
>>> -- end of kamailio.lua
>>
>> can you provide the log messages?
>
> Sorry, I should have included them with the initial posting. I have
> attached an example of the first seven executions of rtimer after a
> fresh startup. Each startup of kamailio results in slightly different
> error values, but the pattern seems similar.
>
> Please let me know if it would be good to send more logs or anything 
> else.
>
>
>> Note that avps are destroyed after
>> execution of the rtimer route - avps are attached to
>> message/transaction. Hash table values should stay no matter where 
>> are
>> set.
>
> Thanks for the reminder. I think in this case the test is valid,
> though, since the avp values are written and read within a single
> rtimer route.
>
>>
>> Cheers,
>> Daniel
>
> Thanks for the help!
>
> -Andrew


I have now duplicated this on the following systems:

Alpine Linux (2.4.5) - kamailio-3.3.0-r0 at edge
Ubuntu (12.04.1) - kamailio-3.3.0+precise1
Ubuntu (12.04.1) - kamailio-3.3.0+wheezy1


Only certain pseudovariables are affected:

sr.pv.sets("$sht(name=>key)") fails
sr.pv.sets("$avp(name)") fails
sr.pv.sets("$xavp(name)") fails
sr.pv.sets("$shv(name)") works
sr.pv.sets("$var(name)") works

Do you need any more information to track this problem?


Thanks,

-Andrew




More information about the sr-users mailing list