[jira] [Commented] (LOG4J2-163) Create asynchronous Logger for low-latency logging

2013-03-31 Thread Ralph Goers (JIRA) 

[ 
https://issues.apache.org/jira/browse/LOG4J2-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618253#comment-13618253
 ] 

Ralph Goers commented on LOG4J2-163:


I started to look at the code and I have a couple of issues:
1. @author tags are discouraged by the ASF board of directors and Log4j 2 
doesn't use them. The idea here is that the community owns the code. Individual 
contributions are recognized through the changes.xml and subversion commits.
2. I am seeing com.lmax.disruptor classes in the source code. This is very bad 
practice as it means a log4j jar will now be exposing classes from a third 
party.  The pom.xml should reference the disruptor jar as a dependency. I'd fix 
this but I don't know what version you based this on.

 Create asynchronous Logger for low-latency logging
 --

 Key: LOG4J2-163
 URL: https://issues.apache.org/jira/browse/LOG4J2-163
 Project: Log4j 2
  Issue Type: Improvement
Affects Versions: 2.0-beta4
Reporter: Remko Popma
 Attachments: async-perf-comparison.png, FastLog4j-v2-for-beta4.zip, 
 FastLog4j-v3-for-beta4.zip, FastLog4j-v4-for-beta4.zip, 
 LOG4J2-163-log4j-async-20130320.patch, 
 LOG4J2-163-log4j-async-20130331-images.zip, 
 LOG4J2-163-log4j-async-20130331.patch, LOG4J2-163-log4j-async.patch


 One of the main considerations for selecting a logging library is 
 performance, specifically, how long it takes for a call to Logger.log to 
 return. (See the comments of LOG4J-151 for a discussion of latency versus 
 application throughput and logging throughput.)
 I believe it is possible to improve this performance by an order of magnitude 
 by having an asynchronous Logger implementation that hands off the work to a 
 separate thread as early as possible. The disk I/O would be done in this 
 separate thread. 
 AsynchAppender is not a good match for these requirements, as with that 
 approach (a) the logging call still needs to flow down the hierarchy to the 
 appender, doing synchronization and creating objects at various points on the 
 way, and (b) when serializing the LogEvent, the getSource() method is always 
 called, which is expensive.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Resolved] (LOG4J2-185) Howto individually configure logging for separate instances of a webapp (war file)?

2013-03-31 Thread Ralph Goers (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LOG4J2-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers resolved LOG4J2-185.


Resolution: Not A Problem

 Howto individually configure logging for separate instances of a webapp (war 
 file)?
 ---

 Key: LOG4J2-185
 URL: https://issues.apache.org/jira/browse/LOG4J2-185
 Project: Log4j 2
  Issue Type: Question
  Components: Configurators, Documentation
Affects Versions: 2.0-beta5
 Environment: multiple copies of one webapp (war file) deployed in one 
 servlet container (e.g. Tomcat)
Reporter: Alexander Horz
  Labels: configuration, documentation,

 The logging of separate instances of one webapp (war file) deployed in a 
 joint servlet container shall be directed to separate files/directories. E.g. 
 a production, demo, and test copy of webapp foo.war are deployed in a 
 joint Tomcat, and logging of the shall be directed to .../log/production/*, 
 .../log/demo/* and .../log/test/* respectively.
 The only solution I have found requires replacement of 
 .../WEB-INF/classes/log4j2.xml for each but the first webapp. However, this 
 requires un/repackaging of the war file.
 I would like to:
 - use an unmodified war file for all instances,
 - set the logging directory parameter in each instance' context 
 configuration file, and 
 - programmatically reconfigure the individual configuration loaded from  
 .../WEB-INF/classes/log4j2.xml when each instance is starting.
 Is this possible?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-163) Create asynchronous Logger for low-latency logging

2013-03-31 Thread Gary Gregory (JIRA) 

[ 
https://issues.apache.org/jira/browse/LOG4J2-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618267#comment-13618267
 ] 

Gary Gregory commented on LOG4J2-163:
-

The pom.xml is the best place is acknowledge contributors IMO.

 Create asynchronous Logger for low-latency logging
 --

 Key: LOG4J2-163
 URL: https://issues.apache.org/jira/browse/LOG4J2-163
 Project: Log4j 2
  Issue Type: Improvement
Affects Versions: 2.0-beta4
Reporter: Remko Popma
 Attachments: async-perf-comparison.png, FastLog4j-v2-for-beta4.zip, 
 FastLog4j-v3-for-beta4.zip, FastLog4j-v4-for-beta4.zip, 
 LOG4J2-163-log4j-async-20130320.patch, 
 LOG4J2-163-log4j-async-20130331-images.zip, 
 LOG4J2-163-log4j-async-20130331.patch, LOG4J2-163-log4j-async.patch


 One of the main considerations for selecting a logging library is 
 performance, specifically, how long it takes for a call to Logger.log to 
 return. (See the comments of LOG4J-151 for a discussion of latency versus 
 application throughput and logging throughput.)
 I believe it is possible to improve this performance by an order of magnitude 
 by having an asynchronous Logger implementation that hands off the work to a 
 separate thread as early as possible. The disk I/O would be done in this 
 separate thread. 
 AsynchAppender is not a good match for these requirements, as with that 
 approach (a) the logging call still needs to flow down the hierarchy to the 
 appender, doing synchronization and creating objects at various points on the 
 way, and (b) when serializing the LogEvent, the getSource() method is always 
 called, which is expensive.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Bug report for Log4j [2013/03/31]

2013-03-31 Thread bugzilla 
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
| 4913|Opn|Min|2001-11-16|org.apache.log4j.helpers.FileWatchdog should allow|
|13099|Opn|Nor|2002-09-27|DOMConfigurator ignores category factory setting  |
|17887|Opn|Maj|2003-03-11|RollingFileAppender does not work for 10 threads  |
|20395|Inf|Enh|2003-06-01|PreparedStatementAppender Enhancement |
|23329|New|Enh|2003-09-22|logger element in XML config should support reso|
|26084|Inf|Nor|2004-01-13|Log Event detail panel does not show special chara|
|27363|Inf|Enh|2004-03-02|JNI based SyslogAppender  |
|27367|Inf|Enh|2004-03-02|NetSendAppender   |
|28059|Opn|Enh|2004-03-30|DOMConfigurator.configure(java.io.InputStream)|
|29244|Inf|Nor|2004-05-27|Preserve XML content in log messages when using XM|
|29305|New|Nor|2004-05-30|Chainsaw doesn't see locationinfo from XMLSocketRe|
|30055|New|Nor|2004-07-12|Problem with registering Appenders with the same n|
|30888|Inf|Maj|2004-08-27|Chainsaw mixes files in same panel|
|30892|New|Min|2004-08-27|Log files cannot be closed|
|31089|New|Nor|2004-09-07|Does not accept ISO8601 dates in focus field  |
|31178|Inf|Cri|2004-09-11|Exception using Chainsaw for simple debugging |
|31179|Ass|Enh|2004-09-11|Implement Chainsaw as Eclipse stand-alone applicat|
|33278|New|Min|2005-01-27|NPE thrown durring daily log file rollover|
|33493|Inf|Enh|2005-02-10|contribution to log4j: servlet diagnostic context |
|34440|New|Nor|2005-04-13|sandbox:IMAppender - comma-seperated recipient lis|
|34491|Ver|Nor|2005-04-18|Missing include in build.jms target results in mis|
|34651|New|Enh|2005-04-27|allow for a header on top of every rolled file|
|34738|Inf|Nor|2005-05-04|Chainsaw does not remember what Columns are select|
|34974|Inf|Cri|2005-05-19|Exception when running a Pluglet  |
|35239|Inf|Nor|2005-06-06|NullPointerException when saving displayed events |
|35563|Inf|Enh|2005-06-30|Syslog appender parametrability   |
|35996|Inf|Enh|2005-08-03|Add support for ant-like property in log4j.xml  |
|36435|New|Enh|2005-08-31|Log4J RollingFileAppender under OpenVMS does not f|
|36654|Inf|Min|2005-09-14|Provide better error messages for Please initiali|
|36789|Inf|Nor|2005-09-23|Empty control flow statement in org.apache.log4j.l|
|37638|New|Nor|2005-11-25|logging doesn't fall back with FallbackErrorHandle|
|37734|New|Nor|2005-12-01|Customize Event ID and Event Category with NTEVent|
|38363|Ass|Maj|2006-01-24|SecurityException during log output   |
|38394|Ver|Enh|2006-01-26|PropertySetter fails to print stacktrace if error |
|38395|Ver|Reg|2006-01-26|Unable to set threshold on appender via config fil|
|38406|Ver|Nor|2006-01-26|jdk1.4 dependencies in log4j 1.3 alpha|
|38513|New|Nor|2006-02-05|[PATCH] Suggested unit test for JMSAppender   |
|38582|Ass|Nor|2006-02-08|Chainsaw does not include Receiver JavaDoc in dist|
|38590|Inf|Nor|2006-02-09|no space on device fails another instance |
|38883|Opn|Nor|2006-03-07|LogFilePatternReceiver fails to process multi-line|
|39690|Inf|Cri|2006-05-31|Initialization fail in J2EE Environment   |
|39691|Ass|Nor|2006-05-31|DBAppender doesn't log long events|
|40068|New|Nor|2006-07-18|Add support for attach-on-demand API to chainsaw  |
|40251|Opn|Min|2006-08-14|Hard coded JMX domain name for MBean instances|
|40382|Inf|Maj|2006-09-01|Sysappender hangs during boot time on HP  |
|40385|Inf|Maj|2006-09-01|SocketServer cannot find config file when passed a|
|40472|New|Nor|2006-09-11|SettingsManager calls loadSettings with global set|
|40533|New|Nor|2006-09-18|Chainsaw not showing all logging statements   |
|40611|New|Trv|2006-09-27|Bad subclass example; NullPointerException in Logg|
|40889|Inf|Nor|2006-11-03|repeated entries in log after failure |
|40990|Inf|Nor|2006-11-17|Cannot bind port or ip address for outgoing UDP so|

[jira] [Resolved] (LOG4J2-188) The appender-ref functionality doesn't work perfectly in the AsynchAppender

2013-03-31 Thread Ralph Goers (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LOG4J2-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers resolved LOG4J2-188.


   Resolution: Fixed
Fix Version/s: 2.0-beta5
 Assignee: Ralph Goers

Fixed in revision 1462895. Please verify and close.

 The appender-ref functionality doesn't work perfectly in the AsynchAppender
 -

 Key: LOG4J2-188
 URL: https://issues.apache.org/jira/browse/LOG4J2-188
 Project: Log4j 2
  Issue Type: Bug
  Components: Appenders
Affects Versions: 2.0-beta4
Reporter: Werner 
Assignee: Ralph Goers
Priority: Minor
 Fix For: 2.0-beta5


 The full appender-ref function (level  filter) doesn't work at the 
 AsynchAppender like in the Logger-Configuration.
   Asynch name=AsynchTest blocking=true bufferSize=2 
 error-ref=xy suppressExceptions=true
   appender-ref ref=ListAppender /  
 == do the job
   
   appender-ref ref=ErrorAppender level=Error /   
 == don't work
   
   appender-ref ref=FilterAppender level=Error
 == don't work
   MarkerFilter marker=TEST onmatch=accept 
 onmismatch=deny /
   /appender-ref
   /Asynch
 proposal for solution:
 AsynchAppender.java : line 79
 @Override
 public void start() {
 final MapString, Appender map = config.getAppenders();
 final ListAppenderControl appenders = new 
 ArrayListAppenderControl();
 for (final AppenderRef appenderRef : appenderRefs) {
 if (map.containsKey(appenderRef.getRef())) {
  // appenders.add(new 
 AppenderControl(map.get(appenderRef.getRef()), null, null));
  // new = 
 appenders.add(new AppenderControl(map.get(appenderRef.getRef()), 
 appenderRef.getLevel(), appenderRef.getFilter()));
  ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Resolved] (LOG4J2-189) AsynchAppender: blocking parameter doesn't work

2013-03-31 Thread Ralph Goers (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LOG4J2-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers resolved LOG4J2-189.


   Resolution: Fixed
Fix Version/s: 2.0-beta5
 Assignee: Ralph Goers

Fixed in revision 1462895. Please verify and close.

 AsynchAppender: blocking parameter doesn't work
 -

 Key: LOG4J2-189
 URL: https://issues.apache.org/jira/browse/LOG4J2-189
 Project: Log4j 2
  Issue Type: Bug
  Components: Appenders
Affects Versions: 2.0-beta4
Reporter: Werner 
Assignee: Ralph Goers
 Fix For: 2.0-beta5


 AsynchAppender parameter:
 blocking=false   == LogEvents are never distributed to other appenders
 blocking=true== the appender don't blocks if the queue is full
 proposal for solution:
 AsynchAppender.java 
public void append(final LogEvent event) {
 if (!isStarted()) {
 throw new IllegalStateException(AsynchAppender  + getName() +  
 is not active);
 }
 if (event instanceof Log4jLogEvent) {  
   
 //if (blocking  queue.remainingCapacity()  0) {
 //try {
 //queue.add(Log4jLogEvent.serialize((Log4jLogEvent) 
 event));
 //return;
 //} catch (final IllegalStateException ex) {
 //error(Appender  + getName() +  is unable to write 
 primary appenders. queue is full);
 //}
 //}
 //if (errorAppender != null) {
 //if (!blocking) {
 //error(Appender  + getName() +  is unable to write 
 primary appenders. queue is full);
 //}
 //errorAppender.callAppender(event);
 //}
   boolean appendSuccessful = false;
   if (blocking){
   try {
   
 queue.put(Log4jLogEvent.serialize((Log4jLogEvent) event));  // wait for free 
 slots in the queue
   appendSuccessful = true;
   } catch (InterruptedException e) {
LOGGER.warn(Interrupted while waiting 
 for a free slots in the LogEvent-queue at the AsynchAppender {}, getName());
   }
   }else{
   appendSuccessful = 
 queue.offer(Log4jLogEvent.serialize((Log4jLogEvent) event));
   if (!appendSuccessful){
   error(Appender  + getName() +  is unable to write 
 primary appenders. queue is full);
   }
   }
   if ((!appendSuccessful)  (errorAppender != null)){
   errorAppender.callAppender(event);
   }
 }
 }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-184) the performance for the log4j initialization needs to be improved

2013-03-31 Thread Ralph Goers (JIRA) 

[ 
https://issues.apache.org/jira/browse/LOG4J2-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618286#comment-13618286
 ] 

Ralph Goers commented on LOG4J2-184:


What platform and hardware are you running on? I added the test to Log4j 2 and 
ran it.  Here is the output.

Running org.apache.logging.log4j.Log4jInitPerformance
2013-03-31 01:20:18,694 DEBUG Generated plugins in 0.15000 seconds
2013-03-31 01:20:18,696 DEBUG Generated plugins in 0.11000 seconds
2013-03-31 01:20:18,696 DEBUG Generated plugins in 0.09000 seconds
2013-03-31 01:20:18,696 DEBUG Generated plugins in 0.1 seconds
2013-03-31 01:20:18,697 DEBUG Generated plugins in 0.09000 seconds
2013-03-31 01:20:18,697 DEBUG Generated plugins in 0.09000 seconds
2013-03-31 01:20:18,706 DEBUG Calling createLayout on class 
org.apache.logging.log4j.core.layout.PatternLayout for element PatternLayout 
with params(pattern=%m%n, Configuration(ConfigTest), null, charset=null)
2013-03-31 01:20:18,706 DEBUG Generated plugins in 0.12000 seconds
2013-03-31 01:20:18,711 DEBUG Calling createAppender on class 
org.apache.logging.log4j.core.appender.ConsoleAppender for element Console with 
params(PatternLayout(%m%n), null, target=null, name=STDOUT, follow=null, 
suppressExceptions=null)
2013-03-31 01:20:18,712 DEBUG Calling createAppenders on class 
org.apache.logging.log4j.core.config.plugins.AppendersPlugin for element 
appenders with params(appenders={STDOUT})
2013-03-31 01:20:18,712 DEBUG Generated plugins in 0.13000 seconds
2013-03-31 01:20:18,713 DEBUG Calling createAppenderRef on class 
org.apache.logging.log4j.core.config.AppenderRef for element appender-ref with 
params(ref=STDOUT, level=null, null)
2013-03-31 01:20:18,715 DEBUG Calling createLogger on class 
org.apache.logging.log4j.core.config.LoggerConfig$RootLogger for element root 
with params(additivity=null, level=error, 
appender-ref={org.apache.logging.log4j.core.config.AppenderRef@687bc899}, 
properties={}, Configuration(ConfigTest), null)
2013-03-31 01:20:18,715 DEBUG Calling createLoggers on class 
org.apache.logging.log4j.core.config.plugins.LoggersPlugin for element loggers 
with params(loggers={root})
log4j 2.0 initialization took 278ms
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.321 sec

 the performance for the log4j initialization needs to be improved
 -

 Key: LOG4J2-184
 URL: https://issues.apache.org/jira/browse/LOG4J2-184
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0-beta4
Reporter: Andreas Rytina
 Attachments: Log4j2InitializationPerformanceTest.java


 The initialization of Log4j 2.0 beta4 via an InputStream takes too long. I 
 attached an small performance test which reproduces the problem. On my 
 machine the test takes approximately one second to complete. On the machine 
 at the customer project, I'm currently working on, it's even worse.
 After analyzing this, I found out that the method 
 org.apache.logging.log4j.core.config.plugins.PluginManager.collectPlugins() 
 is called way to often which consumes most time of the initialization!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Comment Edited] (LOG4J2-184) the performance for the log4j initialization needs to be improved

2013-03-31 Thread Ralph Goers (JIRA) 

[ 
https://issues.apache.org/jira/browse/LOG4J2-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618286#comment-13618286
 ] 

Ralph Goers edited comment on LOG4J2-184 at 3/31/13 8:23 AM:
-

What platform and hardware are you running on? I added the test to Log4j 2 and 
ran it. I changed from status=error to status=debug.  Here is the output.

Running org.apache.logging.log4j.Log4jInitPerformance
2013-03-31 01:20:18,694 DEBUG Generated plugins in 0.15000 seconds
2013-03-31 01:20:18,696 DEBUG Generated plugins in 0.11000 seconds
2013-03-31 01:20:18,696 DEBUG Generated plugins in 0.09000 seconds
2013-03-31 01:20:18,696 DEBUG Generated plugins in 0.1 seconds
2013-03-31 01:20:18,697 DEBUG Generated plugins in 0.09000 seconds
2013-03-31 01:20:18,697 DEBUG Generated plugins in 0.09000 seconds
2013-03-31 01:20:18,706 DEBUG Calling createLayout on class 
org.apache.logging.log4j.core.layout.PatternLayout for element PatternLayout 
with params(pattern=%m%n, Configuration(ConfigTest), null, charset=null)
2013-03-31 01:20:18,706 DEBUG Generated plugins in 0.12000 seconds
2013-03-31 01:20:18,711 DEBUG Calling createAppender on class 
org.apache.logging.log4j.core.appender.ConsoleAppender for element Console with 
params(PatternLayout(%m%n), null, target=null, name=STDOUT, follow=null, 
suppressExceptions=null)
2013-03-31 01:20:18,712 DEBUG Calling createAppenders on class 
org.apache.logging.log4j.core.config.plugins.AppendersPlugin for element 
appenders with params(appenders={STDOUT})
2013-03-31 01:20:18,712 DEBUG Generated plugins in 0.13000 seconds
2013-03-31 01:20:18,713 DEBUG Calling createAppenderRef on class 
org.apache.logging.log4j.core.config.AppenderRef for element appender-ref with 
params(ref=STDOUT, level=null, null)
2013-03-31 01:20:18,715 DEBUG Calling createLogger on class 
org.apache.logging.log4j.core.config.LoggerConfig$RootLogger for element root 
with params(additivity=null, level=error, 
appender-ref={org.apache.logging.log4j.core.config.AppenderRef@687bc899}, 
properties={}, Configuration(ConfigTest), null)
2013-03-31 01:20:18,715 DEBUG Calling createLoggers on class 
org.apache.logging.log4j.core.config.plugins.LoggersPlugin for element loggers 
with params(loggers={root})
log4j 2.0 initialization took 278ms
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.321 sec

  was (Author: ralph.go...@dslextreme.com):
What platform and hardware are you running on? I added the test to Log4j 2 
and ran it.  Here is the output.

Running org.apache.logging.log4j.Log4jInitPerformance
2013-03-31 01:20:18,694 DEBUG Generated plugins in 0.15000 seconds
2013-03-31 01:20:18,696 DEBUG Generated plugins in 0.11000 seconds
2013-03-31 01:20:18,696 DEBUG Generated plugins in 0.09000 seconds
2013-03-31 01:20:18,696 DEBUG Generated plugins in 0.1 seconds
2013-03-31 01:20:18,697 DEBUG Generated plugins in 0.09000 seconds
2013-03-31 01:20:18,697 DEBUG Generated plugins in 0.09000 seconds
2013-03-31 01:20:18,706 DEBUG Calling createLayout on class 
org.apache.logging.log4j.core.layout.PatternLayout for element PatternLayout 
with params(pattern=%m%n, Configuration(ConfigTest), null, charset=null)
2013-03-31 01:20:18,706 DEBUG Generated plugins in 0.12000 seconds
2013-03-31 01:20:18,711 DEBUG Calling createAppender on class 
org.apache.logging.log4j.core.appender.ConsoleAppender for element Console with 
params(PatternLayout(%m%n), null, target=null, name=STDOUT, follow=null, 
suppressExceptions=null)
2013-03-31 01:20:18,712 DEBUG Calling createAppenders on class 
org.apache.logging.log4j.core.config.plugins.AppendersPlugin for element 
appenders with params(appenders={STDOUT})
2013-03-31 01:20:18,712 DEBUG Generated plugins in 0.13000 seconds
2013-03-31 01:20:18,713 DEBUG Calling createAppenderRef on class 
org.apache.logging.log4j.core.config.AppenderRef for element appender-ref with 
params(ref=STDOUT, level=null, null)
2013-03-31 01:20:18,715 DEBUG Calling createLogger on class 
org.apache.logging.log4j.core.config.LoggerConfig$RootLogger for element root 
with params(additivity=null, level=error, 
appender-ref={org.apache.logging.log4j.core.config.AppenderRef@687bc899}, 
properties={}, Configuration(ConfigTest), null)
2013-03-31 01:20:18,715 DEBUG Calling createLoggers on class 
org.apache.logging.log4j.core.config.plugins.LoggersPlugin for element loggers 
with params(loggers={root})
log4j 2.0 initialization took 278ms
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.321 sec
  
 the performance for the log4j initialization needs to be improved
 -

 Key: LOG4J2-184
 URL: https://issues.apache.org/jira/browse/LOG4J2-184
 Project: Log4j 2
  Issue Type: Bug

[jira] [Comment Edited] (LOG4J2-163) Create asynchronous Logger for low-latency logging

2013-03-31 Thread Remko Popma (JIRA) 

[ 
https://issues.apache.org/jira/browse/LOG4J2-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618302#comment-13618302
 ] 

Remko Popma edited comment on LOG4J2-163 at 3/31/13 10:40 AM:
--

Ralph, Gregory, thanks for your feedback!
Please find attached file LOG4J2-163-log4j-async-20130331a.patch

This fixes the issues you mentioned:
* removed @author tags from source code
* removed com.lmax classes, declared dependency in pom, fixed imports and 
updated documentation

The disruptor version I used is 3.0.0.beta3.

(the images referenced in the manual have not changed, so I did not upload them 
again. Please unzip them into the src/site/resources/images/ directory)

  was (Author: rem...@yahoo.com):
Ralph, thanks for your feedback!
Please find attached file LOG4J2-163-log4j-async-20130331a.patch

This fixes the issues you mentioned:
* removed @author tags from source code
* removed com.lmax classes, declared dependency in pom, fixed imports and 
updated documentation

The disruptor version I used is 3.0.0.beta3.

(the images referenced in the manual have not changed, so I did not upload them 
again. Please unzip them into the src/site/resources/images/ directory)
  
 Create asynchronous Logger for low-latency logging
 --

 Key: LOG4J2-163
 URL: https://issues.apache.org/jira/browse/LOG4J2-163
 Project: Log4j 2
  Issue Type: Improvement
Affects Versions: 2.0-beta4
Reporter: Remko Popma
 Attachments: async-perf-comparison.png, FastLog4j-v2-for-beta4.zip, 
 FastLog4j-v3-for-beta4.zip, FastLog4j-v4-for-beta4.zip, 
 LOG4J2-163-log4j-async-20130320.patch, 
 LOG4J2-163-log4j-async-20130331a.patch, 
 LOG4J2-163-log4j-async-20130331-images.zip, 
 LOG4J2-163-log4j-async-20130331.patch, LOG4J2-163-log4j-async.patch


 One of the main considerations for selecting a logging library is 
 performance, specifically, how long it takes for a call to Logger.log to 
 return. (See the comments of LOG4J-151 for a discussion of latency versus 
 application throughput and logging throughput.)
 I believe it is possible to improve this performance by an order of magnitude 
 by having an asynchronous Logger implementation that hands off the work to a 
 separate thread as early as possible. The disk I/O would be done in this 
 separate thread. 
 AsynchAppender is not a good match for these requirements, as with that 
 approach (a) the logging call still needs to flow down the hierarchy to the 
 appender, doing synchronization and creating objects at various points on the 
 way, and (b) when serializing the LogEvent, the getSource() method is always 
 called, which is expensive.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-163) Create asynchronous Logger for low-latency logging

2013-03-31 Thread Remko Popma (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LOG4J2-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-163:
---

Attachment: LOG4J2-163-log4j-async-20130331a.patch

Ralph, thanks for your feedback!
Please find attached file LOG4J2-163-log4j-async-20130331a.patch

This fixes the issues you mentioned:
* removed @author tags from source code
* removed com.lmax classes, declared dependency in pom, fixed imports and 
updated documentation

The disruptor version I used is 3.0.0.beta3.

(the images referenced in the manual have not changed, so I did not upload them 
again. Please unzip them into the src/site/resources/images/ directory)

 Create asynchronous Logger for low-latency logging
 --

 Key: LOG4J2-163
 URL: https://issues.apache.org/jira/browse/LOG4J2-163
 Project: Log4j 2
  Issue Type: Improvement
Affects Versions: 2.0-beta4
Reporter: Remko Popma
 Attachments: async-perf-comparison.png, FastLog4j-v2-for-beta4.zip, 
 FastLog4j-v3-for-beta4.zip, FastLog4j-v4-for-beta4.zip, 
 LOG4J2-163-log4j-async-20130320.patch, 
 LOG4J2-163-log4j-async-20130331a.patch, 
 LOG4J2-163-log4j-async-20130331-images.zip, 
 LOG4J2-163-log4j-async-20130331.patch, LOG4J2-163-log4j-async.patch


 One of the main considerations for selecting a logging library is 
 performance, specifically, how long it takes for a call to Logger.log to 
 return. (See the comments of LOG4J-151 for a discussion of latency versus 
 application throughput and logging throughput.)
 I believe it is possible to improve this performance by an order of magnitude 
 by having an asynchronous Logger implementation that hands off the work to a 
 separate thread as early as possible. The disk I/O would be done in this 
 separate thread. 
 AsynchAppender is not a good match for these requirements, as with that 
 approach (a) the logging call still needs to flow down the hierarchy to the 
 appender, doing synchronization and creating objects at various points on the 
 way, and (b) when serializing the LogEvent, the getSource() method is always 
 called, which is expensive.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Created] (LOG4J2-191) Improve plugin uniqueness by name and type, not just name

2013-03-31 Thread Scott Deboy (JIRA) 
Scott Deboy created LOG4J2-191:
--

 Summary: Improve plugin uniqueness by name and type, not just name
 Key: LOG4J2-191
 URL: https://issues.apache.org/jira/browse/LOG4J2-191
 Project: Log4j 2
  Issue Type: Bug
Reporter: Scott Deboy


I have a default/no-op 'advertiser' implementation:
@Plugin(name = default, type = Core, elementType = advertiser, 
printObject = false)
public class DefaultLeftOut implements Advertiser {

If some other person names another plugin as 'default' in 'core' (admittedly 
default is a terrible name and I should rename it)...we will have a problem.

I think the element type should be part of the resolution..

Still using:
PluginManager pluginManager = new PluginManager(Core);
pluginManager.collectPlugins();

But instead of code using:
PluginType type = getPluginManager().getPluginType(name);
(with name = 'default' in this Advertiser case, giving me a DefaultAdvertiser)

Maybe:
PluginType type = getPluginmanager().getPluginType(elementType, name);
(with elementType = 'advertiser' and name = 'default' in this advertiser case)

In theory, we should also update the Maps in pluginmanager to support this 
uniqueness...right now we collide just on 'name' in the type.

Right now, the last one wins, which isn't ideal.

At least we'd reduce the likelihood of collisions.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-184) the performance for the log4j initialization needs to be improved

2013-03-31 Thread Scott Deboy (JIRA) 

[ 
https://issues.apache.org/jira/browse/LOG4J2-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618387#comment-13618387
 ] 

Scott Deboy commented on LOG4J2-184:


If someone works to reduce the calls to collectPlugins, be aware of the kinds 
of issues you can run into when plugins are cached - I had to fix this one:

https://issues.apache.org/jira/browse/LOG4J2-175

 the performance for the log4j initialization needs to be improved
 -

 Key: LOG4J2-184
 URL: https://issues.apache.org/jira/browse/LOG4J2-184
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0-beta4
Reporter: Andreas Rytina
 Attachments: Log4j2InitializationPerformanceTest.java


 The initialization of Log4j 2.0 beta4 via an InputStream takes too long. I 
 attached an small performance test which reproduces the problem. On my 
 machine the test takes approximately one second to complete. On the machine 
 at the customer project, I'm currently working on, it's even worse.
 After analyzing this, I found out that the method 
 org.apache.logging.log4j.core.config.plugins.PluginManager.collectPlugins() 
 is called way to often which consumes most time of the initialization!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Resolved] (LOG4J2-157) Provide access to config properties in LoggerConfig

2013-03-31 Thread Ralph Goers (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LOG4J2-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers resolved LOG4J2-157.


   Resolution: Fixed
Fix Version/s: 2.0-beta5
 Assignee: Ralph Goers

Patch applied in revision 1463078. Please verify and close.

 Provide access to config properties in LoggerConfig
 ---

 Key: LOG4J2-157
 URL: https://issues.apache.org/jira/browse/LOG4J2-157
 Project: Log4j 2
  Issue Type: New Feature
  Components: Configurators
Affects Versions: 2.0-beta4
Reporter: Remko Popma
Assignee: Ralph Goers
 Fix For: 2.0-beta5

 Attachments: LOG4J2-157-patch.txt


 Custom Loggers that want to support configuration properties when creating 
 custom LogEvent objects currently have no easy way to access these 
 configuration Property objects.
 The configuration Property map in LoggerConfig is private. Please provide an 
 accessor method that returns a (read-only) view of this Property map.
 proposal: add below method to 
 org.apache.logging.log4j.core.config.LoggerConfig:
 /**
  * Returns an unmodifiable map with the configuration properties, or 
  * {@code null} if this {@code LoggerConfig} does not have any configuration
  * properties.
  * p
  * For each {@code Property} key in the map, the value is {@code true} if
  * the property value has a variable that needs to be substituted.
  * 
  * @return an unmodifiable map with the configuration properties, or 
  * {@code null}
  * @see Configuration#getSubst()
  * @see StrSubstitutor
  */
 public MapProperty, Boolean getProperties() {
 return properties == null ? null : 
 Collections.unmodifiableMap(properties);
 }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Resolved] (LOG4J2-151) Please facilitate subclassing Logger and LoggerContext (in org.apache.logging.log4j.core)

2013-03-31 Thread Ralph Goers (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LOG4J2-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers resolved LOG4J2-151.


   Resolution: Fixed
Fix Version/s: 2.0-beta5
 Assignee: Ralph Goers

Patch applied in revision 1463078 from LOG4J2-163. Please verify and close.

 Please facilitate subclassing Logger and LoggerContext (in 
 org.apache.logging.log4j.core)
 -

 Key: LOG4J2-151
 URL: https://issues.apache.org/jira/browse/LOG4J2-151
 Project: Log4j 2
  Issue Type: New Feature
  Components: Core
Affects Versions: 2.0-beta3
Reporter: Remko Popma
Assignee: Ralph Goers
 Fix For: 2.0-beta5

 Attachments: FastLog4j-v2-for-beta4.zip, FastLog4j.zip, 
 LOG4J2-151-patch-LoggerContext.txt, LOG4J2-151-patch-Logger.txt


 I would like to create a custom logger, while reusing the 
 org.apache.logging.log4j.core.Logger functionality.
 The following two changes would make subclassing possible:
 * change visibility of method Logger$PrivateConfig#logEvent(LogEvent) (line 
 265) from protected to public
 * change visibility of method LoggerContext#newInstance(LoggerContext, 
 String) (line 310) from private to protected
 My use case is that I want to create an asynchronous Logger for low latency 
 logging.
 This custom logger hands off control to a separate thread as early as 
 possible. In my case, AsynchAppender is not a good match for my requirements, 
 as with that approach (a) the logging call still needs to flow down the 
 hierarchy to the appender, doing synchronization and creating objects at 
 various points on the way, and (b) when serializing the LogEvent, the 
 getSource() method is always called, which is expensive.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Resolved] (LOG4J2-163) Create asynchronous Logger for low-latency logging

2013-03-31 Thread Ralph Goers (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LOG4J2-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers resolved LOG4J2-163.


   Resolution: Fixed
Fix Version/s: 2.0-beta5
 Assignee: Ralph Goers

Patch applied in revision 1463078. Please verify and close.

 Create asynchronous Logger for low-latency logging
 --

 Key: LOG4J2-163
 URL: https://issues.apache.org/jira/browse/LOG4J2-163
 Project: Log4j 2
  Issue Type: Improvement
Affects Versions: 2.0-beta4
Reporter: Remko Popma
Assignee: Ralph Goers
 Fix For: 2.0-beta5

 Attachments: async-perf-comparison.png, FastLog4j-v2-for-beta4.zip, 
 FastLog4j-v3-for-beta4.zip, FastLog4j-v4-for-beta4.zip, 
 LOG4J2-163-log4j-async-20130320.patch, 
 LOG4J2-163-log4j-async-20130331a.patch, 
 LOG4J2-163-log4j-async-20130331-images.zip, 
 LOG4J2-163-log4j-async-20130331.patch, LOG4J2-163-log4j-async.patch


 One of the main considerations for selecting a logging library is 
 performance, specifically, how long it takes for a call to Logger.log to 
 return. (See the comments of LOG4J-151 for a discussion of latency versus 
 application throughput and logging throughput.)
 I believe it is possible to improve this performance by an order of magnitude 
 by having an asynchronous Logger implementation that hands off the work to a 
 separate thread as early as possible. The disk I/O would be done in this 
 separate thread. 
 AsynchAppender is not a good match for these requirements, as with that 
 approach (a) the logging call still needs to flow down the hierarchy to the 
 appender, doing synchronization and creating objects at various points on the 
 way, and (b) when serializing the LogEvent, the getSource() method is always 
 called, which is expensive.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-164) Add methods is/setEndOfBatch to LogEvent (buffered appender performance improvement)

2013-03-31 Thread Remko Popma (JIRA) 

[ 
https://issues.apache.org/jira/browse/LOG4J2-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618623#comment-13618623
 ] 

Remko Popma commented on LOG4J2-164:


Apologies.
Looks like my patch for LOG4J2-163 missed the change to 
AbstractOutputStreamAppender:

org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender

current (line 116-117):
if (this.immediateFlush) {
manager.flush();

proposed change:
if (this.immediateFlush || event.isEndOfBatch()) {
manager.flush();


 Add methods is/setEndOfBatch to LogEvent (buffered appender performance 
 improvement)
 

 Key: LOG4J2-164
 URL: https://issues.apache.org/jira/browse/LOG4J2-164
 Project: Log4j 2
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.0-beta4
Reporter: Remko Popma
Assignee: Ralph Goers
 Fix For: 2.0-beta5

 Attachments: LOG4J2-164-files.zip, LOG4J2-164-patch.txt


 Many buffered Appenders have an attribute immediateFlush that gives users 
 the option to follow each write with a flush to ensure that all messages are 
 available on disk. The drawback of the immediateFlush idiom is the 
 performance impact of touching the disk on every single event.
 If the appender could determine from the current LogEvent whether any more 
 events are expected, it could avoid unnecessary flushes and only write to 
 disk when the last event was received (or the buffer is full). 
 This would work especially nicely when receiving bursts of events - a common 
 scenario - when you want to avoid adding more overhead to a system that is 
 already very busy.
 Asynchronous loggers and appenders are well-positioned to use such a 
 mechanism: they can easily call LogEvent.setEndOfBatch(true) if the current 
 event is the last one in the queue.
 The patches I proposed for LOG4J2-151 and LOG4J2-163 already use this 
 mechanism internally. The FastFileAppender included in these patches checks 
 if a log event is a specific class, casts the event to that class, and 
 finally calls the isEndOfBatch method on that event. However I think the idea 
 is generally applicable to any buffered appender and adding these methods to 
 the LogEvent interface would benefit users of the existing AsynchAppender and 
 OutputStreamAppender classes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-178) Build broken: FlumePersistentAppenderTest fails because of java.security.InvalidKeyExceptions

2013-03-31 Thread Remko Popma (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LOG4J2-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-178.
--


Confirmed this problem no longer occurs.

 Build broken: FlumePersistentAppenderTest fails because of 
 java.security.InvalidKeyExceptions
 -

 Key: LOG4J2-178
 URL: https://issues.apache.org/jira/browse/LOG4J2-178
 Project: Log4j 2
  Issue Type: Bug
Affects Versions: 2.0-beta5
Reporter: Remko Popma
 Fix For: 2.0-beta5


 from the Maven output:
 Tests run: 18, Failures: 0, Errors: 4, Skipped: 0
 [INFO] 
 
 [INFO] Reactor Summary:
 [INFO]
 [INFO] Apache Log4j 2  SUCCESS [1.470s]
 [INFO] Apache Log4j API .. SUCCESS [11.678s]
 [INFO] Apache Log4J Core . SUCCESS [2:28.445s]
 [INFO] Apache Log4j 1.x Compatibility API  SUCCESS [5.078s]
 [INFO] Apache Log4j SLF4J Binding  SUCCESS [3.871s]
 [INFO] Apache Log4j to SLF4J Adapter . SUCCESS [2.386s]
 [INFO] Apache Log4j Commons Logging Bridge ... SUCCESS [2.818s]
 [INFO] Apache Log4j Flume NG Bridge .. FAILURE [44.447s]
 [INFO] Log4j Web Adapters  SKIPPED
 [INFO] log4j-samples . SKIPPED
 [INFO] flume-common .. SKIPPED
 [INFO] flume-remote .. SKIPPED
 [INFO] flume-embedded  SKIPPED
 [INFO] Apache Log4j Async  SKIPPED
 [INFO] 
 
 [INFO] BUILD FAILURE
 [INFO] 
 
 Tests in error:
   
 testMultiple(org.apache.logging.log4j.flume.appender.FlumePersistentAppenderTest):
  An exception occurred processing Appender eventLogger
   
 testFailover(org.apache.logging.log4j.flume.appender.FlumePersistentAppenderTest):
  An exception occurred processing Appender eventLogger
   
 testLog4Event(org.apache.logging.log4j.flume.appender.FlumePersistentAppenderTest):
  An exception occurred processing Appender eventLogger
   
 testPerformance(org.apache.logging.log4j.flume.appender.FlumePersistentAppenderTest):
  An exception occurred processing Appender eventLogger
 Running org.apache.logging.log4j.flume.appender.FlumePersistentAppenderTest
 2013-03-20 15:00:30,323 ERROR An exception occurred processing Appender 
 eventLogger org.apache.logging.log4j.LoggingException: Exception occurred 
 writing log event
 at 
 org.apache.logging.log4j.flume.appender.FlumePersistentManager.send(FlumePersistentManager.java:167)
 at 
 org.apache.logging.log4j.flume.appender.FlumeAppender.append(FlumeAppender.java:90)
 at 
 org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:102)
 at 
 org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:366)
 at 
 org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:347)
 at 
 org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:310)
 at org.apache.logging.log4j.core.Logger.log(Logger.java:108)
 at 
 org.apache.logging.log4j.spi.AbstractLoggerWrapper.log(AbstractLoggerWrapper.java:55)
 at org.apache.logging.log4j.EventLogger.logEvent(EventLogger.java:54)
 at 
 org.apache.logging.log4j.flume.appender.FlumePersistentAppenderTest.testMultiple(FlumePersistentAppenderTest.java:145)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
 at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
 at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
 at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
 at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
 at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
 at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
 at

[jira] [Closed] (LOG4J2-176) IllegalArgumentException during AsyncAppender shutdown

2013-03-31 Thread Remko Popma (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LOG4J2-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-176.
--


Confirmed this issue no longer occurs.

 IllegalArgumentException during AsyncAppender shutdown
 --

 Key: LOG4J2-176
 URL: https://issues.apache.org/jira/browse/LOG4J2-176
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0-beta4
 Environment: Windows 2000, JDK1.6.0_031, single-cpu machine, multiple 
 threads calling Logger.log
Reporter: Remko Popma
Assignee: Ralph Goers
Priority: Minor
 Fix For: 2.0-beta5


 I am seeing the following exception:
 Exception in thread Thread-7 java.lang.IllegalArgumentException: Event is 
 not a serialized LogEvent: Shutdown
 at 
 org.apache.logging.log4j.core.impl.Log4jLogEvent.deserialize(Log4jLogEvent.java:303)
 at 
 org.apache.logging.log4j.core.appender.AsynchAppender$AsynchThread.run(AsynchAppender.java:229)
 (I cannot reproduce this on other platforms)
 I think this is what is happening:
 [AppThread] calls ((LifeCycle) LogManager.getContext()).stop();
 [AppThread] sets AsyncAppender.shutdown field to true (line 240)
 [AsyncThread] breaks out of while(!shutdown) loop (line 196)
 [AppThread] adds String Shutdown to queue
 [AsyncThread] processes remaining items in the queue, tries to deserialize 
 String Shutdown - Error
 Solution:
 replace AsyncAppender line 229:
 final Log4jLogEvent event = Log4jLogEvent.deserialize(queue.take());
 with
 Serializable s = queue.take();
 if (SHUTDOWN.equals(s)) { continue; } // or break?
 final Log4jLogEvent event = Log4jLogEvent.deserialize(s);
 
 I don't think this is a major issue as the AsyncThread will exit its run() 
 method (so JVM can exit), it just looks a bit sloppy.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-157) Provide access to config properties in LoggerConfig

2013-03-31 Thread Remko Popma (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LOG4J2-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-157.
--


Verified as complete.

 Provide access to config properties in LoggerConfig
 ---

 Key: LOG4J2-157
 URL: https://issues.apache.org/jira/browse/LOG4J2-157
 Project: Log4j 2
  Issue Type: New Feature
  Components: Configurators
Affects Versions: 2.0-beta4
Reporter: Remko Popma
Assignee: Ralph Goers
 Fix For: 2.0-beta5

 Attachments: LOG4J2-157-patch.txt


 Custom Loggers that want to support configuration properties when creating 
 custom LogEvent objects currently have no easy way to access these 
 configuration Property objects.
 The configuration Property map in LoggerConfig is private. Please provide an 
 accessor method that returns a (read-only) view of this Property map.
 proposal: add below method to 
 org.apache.logging.log4j.core.config.LoggerConfig:
 /**
  * Returns an unmodifiable map with the configuration properties, or 
  * {@code null} if this {@code LoggerConfig} does not have any configuration
  * properties.
  * p
  * For each {@code Property} key in the map, the value is {@code true} if
  * the property value has a variable that needs to be substituted.
  * 
  * @return an unmodifiable map with the configuration properties, or 
  * {@code null}
  * @see Configuration#getSubst()
  * @see StrSubstitutor
  */
 public MapProperty, Boolean getProperties() {
 return properties == null ? null : 
 Collections.unmodifiableMap(properties);
 }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-153) Async Logger/Appender performance improvement: provide mechanism to discover if location StackTraceElement is actually required downstream.

2013-03-31 Thread Remko Popma (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LOG4J2-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-153.
--


Verified as complete.

 Async Logger/Appender performance improvement: provide mechanism to discover 
 if location StackTraceElement is actually required downstream.
 ---

 Key: LOG4J2-153
 URL: https://issues.apache.org/jira/browse/LOG4J2-153
 Project: Log4j 2
  Issue Type: Improvement
Reporter: Remko Popma
Assignee: Ralph Goers
 Fix For: 2.0-beta5


 (update 2013 Feb 4: changed summary.
 Previous title: Add a method to the Layout interface to allow Loggers to 
 discover if any of their Appenders need the location StackTraceElement.)
 
 Use Case: any asynchronous Logger or Appender has this problem:
 should it take a snapshot of the call stack (as implemented in 
 Log4jLogEvent.getSource) or not?
 This is an expensive method (1600+ nanoseconds on a machine with 2.9GHz 
 cores) so you only want to call it if you need it. Currently there is no way 
 to discover if the location information is used by any of the configured 
 layouts.
 If the Layout interface has a method that indicates whether the layout calls 
 the LogEvent.getSource method, then the Logger can query its LoggerConfig if 
 any of the configured Appenders has a Layout which needs location info. 
 (Maybe boolean needsLocationInfo() would be a good name?)
 With this information, a Logger can construct Log4jLogEvents with a non-null 
 dummy StackTraceElement location if none of the layouts downstream need 
 location info. The non-null dummy location would prevent LogEvent.getSource 
 from taking a call stack snapshot.
 The current AsynchAppender class would get an immediate performance boost 
 from this, and custom asynchronous Loggers or Appenders would reap the same 
 benefits.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org