[sr-dev] git:master: pv: use msg context id when caching the value for $TV

[Klaus Darilion]

Hi Daniel!

Am 15.04.2012 23:02, schrieb Daniel-Constantin Mierla:
> Hello,
>
> On 4/15/12 10:02 PM, Klaus Darilion wrote:
>> Hi Daniel!
>>
>> I reviewed the patch and it still does not work reliable. The new 
>> approach uses msg-id and pid to find out if $TV(s) still works on the 
>> same message or if a new message is processed and time stamp needs to 
>> be fetched.
>>
>> Consider the following scenario:
>>
>> worker process with pid 100 receives msg with msg-id 7:
>> --> msg context id = 100,7
>> --> $TV(s) is calculated on first usage
>>
>> forwarding times out, timer with pid 99 processes message with msg-id 
>> 7 in failure route:
>> --> msg context id = 99,7
>> --> $TV(s) is calculated on first usage
>>
>> second forwarding times out, timer with pid 99 processes message with 
>> msg-id 7 in failure route:
>> --> msg context id = 99,7
>> --> $TV(s) is not calculated context ids are the same
>>
>>
>> Thus, $TV(s) is different in request route and failure route, but 
>> identically in both failure routes, if the failure route does not 
>> process another message. Thus, current implementation behaves 
>> different, depending on if other requests are forwarded/failed too.
>>
>> So, we need a different implementation. Before implementing, we 
>> should define the expected behavior. There are 2 possible (useful) 
>> implementations.
>> a) $TV(s) in failure route has always the same value as in request route
>> b) $TV(s) in failure route has always the value when the requests 
>> entered the respective failure route
>>
>> I would vote for implementation 2.
>>
>
> these are cached values per (message,process) to skip execution of 
> system calls many times, but also to have more or less same value for 
> several actions in a raw. So such values are valid as long as a pid is 
> processing same message one time or many times without handling 
> another one in between.

Yes, that's the problem. A PV should always return the same value, 
regardless if there was a another message processed inbetween or not.

IMO, it is a bug. If not, we need a new PVs (see below).

Maybe we should store a timestamp in sip_msg and set it automatically 
when the request was received or processing recovered in failure route.

> There are other PVs giving the current time attributes always, without 
> any caching -- one can store the result in other type of variable then 
> and reuse that.

$TV(sn) and $TV(un) are useless, as they need to be queried one after 
the other, this getting different points in time.

$TV(Sn) needs string processing afterwards to split it into seconds and 
useconds, otherwise time calculations are not possible.

I would be more usefull, e.g. if TV(un) reports the cached time, set 
when querying for TV(sn).

>
> IMO, the caching system should be coherent across all PVs relying on 
> it, for other kind of needs there should be different variables.
>
User should also rely that PVs return the same result for the same 
scenario, regardless if other messages are received or not.

regards
Klaus