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 <[email protected]> > 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 <[email protected]> >>>> 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 >>>> [email protected] >>>> 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 >> [email protected] >> 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 [email protected] 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
