On Tue, 2 Feb 2016, Michael Biebl wrote:
2016-01-25 10:00 GMT+01:00 Rainer Gerhards <[email protected]>:
Hi all,
please note that the (candidate) tarball for tomorrow's release is now
available at
http://www.rsyslog.com/files/download/rsyslog/rsyslog-8.16.0.tar.gz
If you build packages, it would be nice if you could pick it up and see if
it works for you. Any bug reports received within the next 24hrs could
probably be solved in the actual release.
Note that we do not yet require libfastjson but strongly recommend it.
8.17.0 will finally require it.
While I can understand the motivation, I do fear that ultimately you,
Rainer, take on another responsibility, i.e. maintaining another
library.
And resources are already stretched very thin.
This is my main concern of introducing yet another dependency.
your concerns are very valid. If this was just a performance boost (even the
large one that we are seeing), I think that there would be a very good argument
against doing this. But there is the bigger correctness problem. the json-c
library has significant correctness problems that I personally was starting to
trip over on a very frequent basis, causing a large number of segfaults. We
tried fixing this with locking, but even the most draconian exclusive locks
around any json-c code wasn't enough.
As a result, we need to move off of json-c to something else, libfastjson is
seen as less expensive short-term effort to get us stable (by fixing the
library) compared to switching to a completely different library and variable
handling system.
We think that there is likely to be real value to be gained by moving to a
different variable handling system because 99% of the variables that are created
are subsets of the original message, so if we can use pointers into the original
message instead of copying the data, it could be a big win. But exploring this
sort of thing will be a lot of work.
if json-c was under active development and with frequent releases, then matching
it with a fork would be a lot more work (and probably a lot less needed), but
that's not the case.
It may be that someone other than Rainer would have better luck with
interactions with the json-c project, explaining the issues and convincing them
to do something. If so, we can abandon libfastjson in the future (like we have
been abandoning libestr for example)
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
