[OpenSER-Devel] [ openser-Bugs-1870301 ] Script variables persist for more than a message processing

[SourceForge.net]

Bugs item #1870301, was opened at 2008-01-13 14:15
Message generated for change (Comment added) made by miconda
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1870301&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: ver devel
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Iñaki Baz (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Script variables persist for more than a message processing

Initial Comment:
According to the doc [1] any user can expect that a script variable persists during a single message proccesing but the real behaviour is very unexpected since the content of a script variable persists eternally into each OpenSer process.

An example:


------------------------------------------------
route {

  if ($rU == "test") {
    $var(test) =  "calling to test !!!";
  }

  xlog("L_INFO","---- pid = $pp \n");
  xlog("L_INFO","---- var(test) = $var(test) \n");

}
------------------------------------------------


Now supossing there are those OpenSer processes running:
  ~# pidof openser
  10001 10002


TEST:

1) Call to $rU = "other":
  ---- pid = 10001
  ---- var(test) = 0  [2]

2) Call to $rU = "test":
  ---- pid = 10002
  ---- var(test) = calling to test !!!

3) Call to $rU = "other":
  ---- pid = 10002
  ---- var(test) = calling to test !!!


Note that in 2) and 3) the message has been processed by the same pid (10002).

In 2) the variable was set to "calling to test !!!" since $rU was "test".

In 3) $rU is not "test" (it's "other" in fact) but when reading the variable $avp(test) it has the previously value "calling to test !!!" set in a **different** message processing.


IMHO there is something wrong here, it makes no sense to keep a variable data for different message processing. In fact this behaviour can become dangerous if we take decissions based on script variable content and we just set them a value in certains cases (note that to be sure we should set "$var(test)=0" at the beggining of the script, that's not very cool).

I think the expected behaviour is that a script variable should persist just during a message processing, and be deleted from memory after that instead of persist for the pid that processed the message.


[1] http://www.openser.org/dokuwiki/doku.php/pseudovariables:1.3.x#script_variables
[2] Correct since null variables are initialized to 0.

----------------------------------------------------------------------

>Comment By: Daniel-Constantin Mierla (miconda)
Date: 2008-01-13 21:04

Message:
Logged In: YES 
user_id=1246013
Originator: NO

If you read the phrase, I think it means what is happening:

"The value of script variables persists over the processing of SIP
messages, being specific per each OpenSER process."

So, it does right. To understand better, the names of variables are
replaced at startup by pointer to private memory structure. These variable
are for fast access, similar to variables in C, where you have to
initialize them, nobody does it for it.

To be persistent only per message, it is going to be something similar to
AVPs, because the message create transaction, and so on, that leads to
share memory.

If you consider that should be automatically reset at the start of config
processing, add a feature request and let-s see who is advocating what
solution. I prefer to stay as it is, in the config can be tens of script
variables, but in the path of one message processing, can meet only few
(e.g., if it is cancel, register, bye, etc) -- going through a list
checking and resetting may eat some resource without reason, as the admin
can set that value when it needs to what it need (again, C-like style).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1870301&group_id=139143