RE: async logger on slow single core env performs 50% worse than log4j v1

Hi Remko / log4j2, - Tnx for the correction, I'll retest async logger: System.setProperty(Log4jContextSelector, org.apache.logging.log4j.core.async.AsyncLoggerContextSelector); - Before I recompile with a test run for async logger I'll edit log4j2.xml and add bufferedIO=false to the

reflection? RE: async logger on slow single core env performs 50% worse than log4j v1

Hi guys, I mentioned this observation last week, that my embedded single core env, the VM also does not support reflection. Is reflection used in the hot path of logging that might be affecting my testing of V2 using more CPU than v1? LOGGER.debug(sun.reflect.Reflection is not installed);

Re: async logger on slow single core env performs 50% worse than log4j v1

Hang on! By fish tagging do you mean you use logger#entry, #exit, #catching? These methods walk the stack trace to determine the location (class, method) which will give you a *huge* performance penalty! If you#x27;re using async logging this is 20x slower, for sync logging (slower to begin

v2.0-beta7: Logging causes java.lang.OutOfMemoryError: Java heap space

Hello, I'm using version Log4j version 2.0-beta6 on OpenJDK version 1.7.0_25 and I just stumbled upon this issue: https://issues.apache.org/jira/browse/LOG4J2-245 Seeing that it was fixed in version 2.0-beta7, I updated my pom.xml to use this version but now my code hangs for a while on

Re: v2.0-beta7: Logging causes java.lang.OutOfMemoryError: Java heap space

Federico, Thanks for the report! Would you mind raising a Jira ticket with some environment details and if possible steps to reproduce the issue? Many thanks! Remko

Re: v2.0-beta7: Logging causes java.lang.OutOfMemoryError: Java heap space

Please do NOT file a JIRA. One already exists for this: https://issues.apache.org/jira/browse/LOG4J2-322 On Mon, Jul 29, 2013 at 9:36 AM, Remko Popma rem...@yahoo.com wrote: Federico, Thanks for the report! Would you mind raising a Jira ticket with some environment details and if possible

Re: v2.0-beta7: Logging causes java.lang.OutOfMemoryError: Java heap space

Thank you for replying, as Nicholas pointed out (thanks, I didn't see it!) there is already an open Jira ticket for this issue so I'm not goint to file a new one and I will wait for news. Kind regards, Federico On 07/29/2013 04:51 PM, Remko Popma wrote: Federico, Thanks for the report! Are

Re: v2.0-beta7: Logging causes java.lang.OutOfMemoryError: Java heap space

Duplicate mail message. Please ignore. Apologies.

Re: v2.0-beta7: Logging causes java.lang.OutOfMemoryError: Java heap space

Federico, Thanks for the report! Are you on Java 8? Would you mind raising a Jira ticket with some environment details and if possible steps to reproduce the issue? Many thanks! Remko

Re: reflection? RE: async logger on slow single core env performs 50% worse than log4j v1

In your environment I would definitely recommend using BasicContextSelector as you are unlikely to have need for multiple LoggerContexts. Ralph On Jul 29, 2013, at 7:08 AM, SMITH, CURTIS wrote: Hi guys, I mentioned this observation last week, that my embedded single core env, the VM also

Re: reflection? RE: async logger on slow single core env performs 50% worse than log4j v1

This probably warrants an enhancement to Log4jContextFactory. I can imagine other use cases where defaulting to BasicContextSelector also makes sense. Ralph On Jul 29, 2013, at 8:02 AM, Ralph Goers wrote: In your environment I would definitely recommend using BasicContextSelector as you are

RE: reflection? RE: async logger on slow single core env performs 50% worse than log4j v1

Ralph, Was your comment about BasicContextSelector me and my quest to get V2 to run as well as V1 on my slow single core J2ME env? My test run with AsyncLogger blew up. This J2ME VM does not have reflection. Guessing that disruptor uses reflection to cast methods/objects (bottom). This

Re: reflection? RE: async logger on slow single core env performs 50% worse than log4j v1

Yes. ClassLoaderContextSelector is complicated and probably not at all what you want. it uses the Sun reflection class, which you've noticed is not installed, and runs slower without it. I don't think ClassLoaderContextSelector will be of any benefit to you over BasicContextSelector. On Jul

Are the custom appenders only like plugins?

Hi Guys, Trying to embed log4j2 in our OSGi application. So, one small question: How can I create custom appender which will be *not* a plugin? I want to create it like old school log4j1.x appender. For the some reason we can not use osgi.core version = 4.3.0 in our application, only =4.2.0.

Are the custom appenders only like plugins?

Hi Guys, Trying embed log4j2 in our OSGi application. So, one small question: How can I create custom appender which will be not a plugin? I want to create it like old school log4j1.x appender. The cause: We cannot use osgi.core version = 4.3.0 in our application, only =4.2.0. (As you know

RE: reflection? RE: async logger on slow single core env performs 50% worse than log4j v1

Hi Ralph, my exception is from the disruptor jar apparently using reflection (below). How is that related to the ClassLoaderContextSelector? I would have guessed that the BasicContextSelector is default??? I'm not setting Log4jContextSelector so it has to be using some context, wouldn't the

Re: reflection? RE: async logger on slow single core env performs 50% worse than log4j v1

The exception with the Disruptor wouldn't be. It basically means you cannot use the Async Loggers. The benefit to using the BasicContextSelector is that it is lighter weight and you won't get the warning about the Sun Reflection class being missing.] I have not tested with J2ME so I can't

Re: Are the custom appenders only like plugins?

Aliaksandr, I don't think you need a specific OSGi version to make a plugin. Remko From: Aliaksandr Belavusau abelavu...@gmail.com To: log4j-user@logging.apache.org Sent: Tuesday, July 30, 2013 5:27 AM Subject: Are the custom appenders only like plugins?