7 Nov
2022
7 Nov
'22
9:10 p.m.
Probably the data received via evapi connection is in a local buffer,
but I don't recall if json parsing (as I haven't implement it) does any
caching. After all, anyhow it will be an extra copy in memory, which is
probably negligible if it is not in range of mega bytes of data.
Eventually, you can try leveraging app_jsdt with a javascript global
variable -- I haven't tested performances, but jsdt has built-in json
parser that translates to a js object which allows accessing fields in a
structure fashion. I used app_jsdt when I had to do some "heavy"
transformation of json data (e.g., update content, reorder fields, ...).
The module has no external dependency.
Cheers,
Daniel
On 07.11.22 13:31, Alex Balashov wrote:
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.
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
On Nov 7, 2022, at 7:01 AM, Daniel-Constantin
Mierla <miconda(a)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
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
sr-users(a)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 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.
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
> On Nov 7, 2022, at 2:56 AM, Daniel-Constantin
Mierla <miconda(a)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(a)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(a)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