Hi Willy.
On 2026-02-03 (Di.) 09:33, Willy Tarreau wrote:
Hi Aleks,
On Tue, Feb 03, 2026 at 09:20:09AM +0100, Aleksandar Lazic wrote:
Hi.
Mia mentioned in
https://www.mail-archive.com/[email protected]/msg46543.html is there
another solution for JSON reading based on
https://github.com/ibireme/yyjson/ instead of the current used mjson lib.
Interesting, I didn't notice.
This library looks nice but have some points which I would like to discuss.
+ yyjson looks active maintained vs mjson which looks stalled
+ in yyjson is JSON Path build in instead of handcrafted JSON Query in mjson
Honestly I don't know the difference :-)
The biggest difference is the syntax '$.JSON-KEY' vs '/JSON-KEY' for our use
case. The JSON Query can be quite complex but that's not used yet in HAProxy I
assume.
- yyjoon looks much bigger then mjson
Not that much.
That's the Idea of an Roadmap to remove mjson from HAProxy:
* My suggestion is to add yyjson and samples for JSON Path similar to JSON Query
and announce the new feature..
* Add some helper functions for JSON Query to JSON Path translation.
Luckily in HAProxy isn't the JSON Query really "just" some '$.GET_VALUE"'
Stuff.
* Replace mjson calls with yyjson calls.
* Make JSON Query deprecated.
* Remove mjson from HAProxy code.
My questions for a good integration of yyjson into HAProxy.
Which Memory management handling (pool, dynbuf) can I use based on the doc
of yyjson?
https://github.com/ibireme/yyjson/blob/master/doc/API.md#memory-allocator
What's your opinion on that?
Hmmm I hadn't noticed this. That's a big negative. mjson doesn't need to
allocate memory, so here we face the risk of allocating unknown amounts
based on the document's contents, right ? Malloc() is already a bottleneck
on large systems, it represents up to 2 digits of the percent of CPU time
used by some SSL libs. I'm seeing that they also implement pools but then
one needs to implement them by thread otherwise you lose thread safety.
It could be helpful to understand why this lib needs to allocate RAM when
others do not. We're really trying to stay away from memory allocations on
the fly as they cause a lot of trouble under load (or even attacks). It
could be more acceptable to make it work with fixed size buffers even it
it uses more on average rather than random size based on contents.
There is also the option to don't use malloc. I think this can also be used to
limit the json parsing size.
https://github.com/ibireme/yyjson/blob/master/doc/API.md#stack-memory-allocator
```
If the JSON is small enough, you can use stack memory to read or write it.
Sample code:
char buf[128 * 1024]; // stack buffer
yyjson_alc alc;
yyjson_alc_pool_init(&alc, buf, sizeof(buf));
yyjson_doc *doc = yyjson_read_opts(dat, len, 0, &alc, NULL);
...
yyjson_doc_free(doc); // this is optional, as the memory is on stack
```
This also mention the memory handling about parsing.
https://github.com/ibireme/yyjson/blob/master/doc/API.md#stack-memory-usage
```
Most functions in the library use fixed-size stack memory. This includes
functions for JSON reading and writing, as well as JSON Pointer handling.
However, a few functions use recursion and may cause a stack overflow if the
nesting level is too deep. These functions are marked with the following warning
in the header file:
@warning This function is recursive and may cause a stack overflow if the object
level is too deep.
```
I think when in the documentation is mentioned that an recursive parsing should
be avoided should this not be an problem.
Willy
Regards
Aleks
