That email was from a while ago. I think I just came up with another attribute for the JMX element. I'll have to look at the status logger but I believe it is always creating a StatusData object and putting it in a ring buffer so they can be printed later. This will actually create a lot of objects and will impact performance. So we will want to add a statusLevel attribute to the JMX element to specify what the level is on the events that should be added to the buffer.
It was actually kind of cool though as the person doing the performance test looked at the JMX stats and even though the status was set to error in the configuration they had lots of debug messages in JMX that were quite helpful to verify a misconfiguration. Ralph On Jul 23, 2013, at 3:17 PM, Remko Popma wrote: > Understood about CamelCase, not a problem. > Maybe AsyncLoggers is a better element name anyway. How does this look? >> <configuration level="warn" >> Log4jContextSelector="org.apache.logging.log4j.core.async.AsyncLoggerContextSelector"> >> <AsyncLoggers exceptionHandler="my.custom.Handler" ringBufferSize="128" >> waitStrategy="Block" /> >> <jmx enabled="true" /> >> </configuration> > Sorry, I don't remember what email from Simo you are referring to. > > > From: Gary Gregory <[email protected]> > To: Log4J Developers List <[email protected]> > Sent: Wednesday, July 24, 2013 7:07 AM > Subject: Re: Config additions, WAS: Confused: want low latency: do I need > BOTH async logger AND async appender?? > > What is up with the dashes in element names? That is unsightly IMO. I know > that we have some - IMO unnecessary - flexibility in our config code to make > XML case insensitive but dashes we have in there now make it impossible to > make the XML look decent. If it were just me I would use CamelCase for > element names (like class names) and camelCase for attribute names (like > instance variable names). > > Simo has emailed about a different approach to configuration. Does anyone > have comments on that btw? I know, I should start a different thread... > > Gary > > On Jul 23, 2013, at 17:57, Remko Popma <[email protected]> wrote: > >> After looking at your changes for LOG4J2-318 to add the shutdownHookEnabled >> attribute I understand a bit better. >> >> Here is a list of properties that can be used to configure AsyncLoggers when >> all loggers are Async: >> * >> Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector >> * AsyncLogger.ExceptionHandler >> * AsyncLogger.RingBufferSize >> * AsyncLogger.WaitStrategy >> * log4j.Clock - currently only used for timestamping RingBufferLogEvents. >> Should all LogEvents >> >> The following system properties can be used to configure mixed Async Loggers: >> * AsyncLoggerConfig.ExceptionHandler >> * AsyncLoggerConfig.RingBufferSize >> * AsyncLoggerConfig.WaitStrategy >> >> For JMX there is only the one "disable" property, which Gary suggested to >> make into an element rather than an attribute to future-proof it. >> >> So, should the result look something like this? >> >> <configuration level="warn" >> Log4jContextSelector="org.apache.logging.log4j.core.async.AsyncLoggerContextSelector"> >> <async-configuration exceptionHandler="my.custom.Handler" >> ringBufferSize="128" waitStrategy="Block" /> >> <jmx enabled="true" /> >> </configuration> >> >> >> From: Ralph Goers <[email protected]> >> To: Log4J Developers List <[email protected]> >> Sent: Wednesday, July 24, 2013 2:38 AM >> Subject: Re: Config additions, WAS: Confused: want low latency: do I need >> BOTH async logger AND async appender?? >> >> What don't you know? I'd be happy to help with that :-) >> >> Ralph >> >> >> On Jul 23, 2013, at 9:20 AM, Remko Popma wrote: >> >> > I wouldn't mind doing this but don't know how. >> > >> > Remko >> > >> > Sent from my iPhone >> > >> > On 2013/07/24, at 0:46, Nick Williams <[email protected]> >> > wrote: >> > >> >> I don't know the answer to this guy's question on the user's list, but it >> >> brought up something interesting that we need to look at. Already (in a >> >> separate issue) we have talked about needing a config element for JMX so >> >> that you don't have to use properties in this manner. IMO, if there's not >> >> a way to set these AsyncLogger configuration options in log4j2.xml/json, >> >> that needs to be added, too. You should never have to do >> >> System.setProperty (or -D on the command line) to get Log4j configured >> >> properly. >> >> >> >> My $0.02. >> >> >> >> Nick >> >> >> >> On Jul 23, 2013, at 10:39 AM, SMITH, CURTIS wrote: >> >> >> >>> http://logging.apache.org/log4j/2.x/manual/async.html >> >>> >> >>> This URL describes that v2 has both async logger and async appender. >> >>> What is the suggested config for an embedded situation where I want low >> >>> latency, nothing fancy? >> >>> >> >>> I've had do this in code since we don't own the cmd line: OSGi and >> >>> system vendor owns the box and java command line. >> >>> >> >>> System.setProperty("AsyncLoggerContextSelector", >> >>> "org.apache.logging.log4j.core.async.AsyncLoggerContextSelector"); >> >>> System.setProperty("AsyncLogger.RingBufferSize", "128"); // min >> >>> size permissable to keep memory low >> >>> System.setProperty("AsyncLogger.WaitStrategy", "Block"); // less >> >>> CPU, better for embedded env >> >>> System.setProperty("log4j2.disable.jmx", "true"); // saves >> >>> on a jmx jar and we don't use JMX anyway >> >>> >> >>> Tnx curt >> >>> >> >>> Curt Smith >> >>> AT&T Digital Life >> >>> DLC Software Development >> >>> 404-499-7013 >> >>> (cell) 678-365-6508 >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > >
