[SR-Users] evapi:message-received and state

[Alex Balashov]

I was not sure if there were some static buffer size. You are right, of course, and given modern resources the concern about compute-heavy JSON parsing is probably rather academic.

I require fairly extensive deserialisation into non-scalar AVP structures which are also transaction-persistent. This in effect would require two stages of marshalling. I would rather do it in one place and take the hit on compute-heavy inspection of the JSON payload twice, especially since it’s wrapped behind the convenience of libjansson.

Thank you for the insights!

— Alex

—
Sent from mobile, apologies for brevity and errors.

> On Nov 7, 2022, at 7:01 AM, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> 
> Hello,
> 
> $var() uses pkg memory, so it is available pkg at that moment that sets
> the limit of how much a $var() can store.
> 
> If you need only specific values from json, you can store only them in
> some variables to avoid reparsing. On the other hand, the operations are
> in memory, so probably not big penalty.
> 
> Cheers,
> Daniel
> 
>> On 07.11.22 12:29, Alex Balashov wrote:
>> Hi Daniel, 
>> 
>> Thank you. It’s just a pity because it’s a large JSON blob, so would have to be parsed twice (it also contains the transaction ID/label). I can change the wire format so as to not require this, probably, though. 
>> 
>> Do you know offhand what the maximum length of the value that can be assigned to a $var is?
>> 
>> —
>> Sent from mobile, apologies for brevity and errors.
>> 
>>>> On Nov 7, 2022, at 2:56 AM, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
>>> 
>>> Hello,
>>> 
>>> iirc, the continue is done by the same worker process that executes the
>>> event route, so you can pass it via $var(...), otherwise you can
>>> propagate it to other process via mqueue (+rtimer). Using htable with a
>>> key based on transaction ids should be fine as well, at the end htable
>>> is designed as a fast key/value in-memory storage.
>>> 
>>> Cheers,
>>> Daniel
>>> 
>>>> On 07.11.22 05:36, Alex Balashov wrote:
>>>> Hi,
>>>> 
>>>> I am t_continue()ing a transaction inside of event_route[evapi:message-received]. The $evapi(msg) has quite a bit of payload that will be needed by the resumed transaction.
>>>> 
>>>> Is there a good way to inject this data into the transaction scope externally? No [X]AVPs created in the event_route persist, of course, since the route is scoped outside of the transaction.
>>>> 
>>>> I have been using htable to pass data into the transaction, keyed by the index and label. But, this strikes me as a kind of clumsy memory synchronisation anti-pattern. Is there a better way?
>>>> 
>>>> Cheers,
>>>> 
>>>> — Alex
>>>> 
>>>> -- 
>>>> Alex Balashov | Principal | Evariste Systems LLC
>>>> 
>>>> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
>>>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>>>> 
>>>> 
>>>> __________________________________________________________
>>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>> sr-users at lists.kamailio.org
>>>> Important: keep the mailing list in the recipients, do not reply only to the sender!
>>>> Edit mailing list options or unsubscribe:
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>> -- 
>>> Daniel-Constantin Mierla -- www.asipto.com
>>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>>> 
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> sr-users at lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the sender!
>> Edit mailing list options or unsubscribe:
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>