All these sound like very nice improvements!
On Fri, Aug 17, 2018 at 4:13 AM, Robert Middleton
wrote:
> Interesting results! I haven't experienced any problems with logging
> myself, but I've also never gone into benchmarking it.
>
> I don't have much experience with memory pools, but if you're
>From the logging page (http://logging.apache.org/)
if you click on the log4cxx project page button, it sends you to
https://logging.apache.org/log4cxx/latest_stable/latest_stable/
with a Page Not Found error page...
Interesting results! I haven't experienced any problems with logging
myself, but I've also never gone into benchmarking it.
I don't have much experience with memory pools, but if you're still
getting blockages on a call to new/malloc you may be able to get
around it by using the memory pool and t
I don't know much about the state of log4cxx architecture, but nearly all
your points (other than the lock in stringstream) are points we optimize
for in log4j2 at least. Even the stringstream optimization sounds similar
to StringBuffer versus StringBuilder in java. As for the queue used in
async l
The latest version (2.11.1) has been tested mainly against Java 9 changes,
though the Java 10 and 11 changes should also work. I've been using Java 10
and 8 to build/test Log4j myself at least.
On Thu, 16 Aug 2018 at 01:38, Dragan, Krzysztof wrote:
> Hi,
> We are reaching out to you to check Jav
Hello All,
I'd like to share some experience as well as some patches with regard
to using log4cxx in timing-critical application. First few words about
our requirements: it's a service which must generate some network
packets with up to hundred of microseconds precision. Thus, it's very
impor
