[jira] [Created] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
Remko Popma created LOG4J2-555:
--
Summary: Location-based functionality broken in
AbstractLoggerWrapper subclasses
Key: LOG4J2-555
URL: https://issues.apache.org/jira/browse/LOG4J2-555
Project: Log4j 2
Issue Type: Bug
Components: API, Core
Affects Versions: 2.0-rc1
Reporter: Remko Popma
Assignee: Remko Popma
Fix For: 2.0-rc2
*How to reproduce*
* Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
one with the tool attached to LOG4J2-519)
* In the custom logger provide a public method that invokes the {{log(Level,
String)}} method
* Configure a pattern layout that uses location, like %C for the logger FQCN
* From a sample app, call the public method on your custom logger.
* The output will show the class name of the custom logger instead of the class
name of the calling class in the sample application.
*Cause*
{{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
{{AbstractLogger.class.getName()}}. Then, in {{Log4jLogEvent#calcLocation()}},
when walking over the stack trace elements, the element _following_ the FQCN is
returned. So only loggers that directly subclass from {{AbstractLogger}} will
work correctly. Loggers that inherit from {{AbstractLoggerWrapper}} are two
levels removed from {{AbstractLogger}} and the {{calcLocation()}} method will
not work correctly.
*Solution*
I think {{AbstractLogger}}'s FQCN field should be made non-static, and
initialized to {{getClass().getName()}} in the constructor of
{{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
return the {{StackElement}} whose class name matches the FQCN, instead of the
next element. Location-based functionality should then work for arbitrarily
deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917298#comment-13917298
]
Remko Popma commented on LOG4J2-519:
vibin, the quick fix may be to use %c (lowercase) in your pattern layout
instead of %C (upper case). This will use the logger _name_ instead of its
class and as a side-effect will be about [ten times
faster|http://logging.apache.org/log4j/2.x/manual/async.html#Throughput_of_Logging_With_Location_includeLocationtrue]
because it doesn't use reflection.
Ralph, this looks like a bug:
it basically means that any location-based logic is broken for loggers that
subclass AbstractLoggerWrapper. I've raised LOG4J2-555 for this.
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achieve the above customization; especially taking away existing methods is
> not possible.
> An alternative is for the user to create a wrapper class that exposes only
> the convenience methods for the desired log levels. When _extending_ the
> {{Logger}} API (_adding_ methods), this wrapper class could subclass
> {{org.apache.logging.log4j.spi.AbstractLoggerWrapper}}. When _customizing_
> the {{Logger}} API (_removing_ built-in methods), the wrapper class would
> simply not extend AbstractLoggerWrapper, so the only public methods would be
> the methods for the custom log levels.
> As the custom log Levels are not known in advance, Log4J cannot provide
> pre-built wrapper classes for these custom log Levels. However, we don't want
> to ask the users to hand-code such a wrapper class: this is cumbersome and
> error-prone: there are 14 methods for each built-in level. To provide
> comparable functionality for custom log Levels one would need to provide 14
> methods for each custom log Level.
> The proposal is to s
[jira] [Comment Edited] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917298#comment-13917298
]
Remko Popma edited comment on LOG4J2-519 at 3/2/14 6:25 AM:
vibin, thanks a lot for testing this!
The quick fix may be to use %c (lowercase) in your pattern layout instead of %C
(upper case). This will use the logger _name_ instead of its class and as a
side-effect will be about [ten times
faster|http://logging.apache.org/log4j/2.x/manual/async.html#Throughput_of_Logging_With_Location_includeLocationtrue]
because it doesn't use reflection.
Ralph, this looks like a bug:
it basically means that any location-based logic is broken for loggers that
subclass AbstractLoggerWrapper. I've raised LOG4J2-555 for this.
was (Author: rem...@yahoo.com):
vibin, the quick fix may be to use %c (lowercase) in your pattern layout
instead of %C (upper case). This will use the logger _name_ instead of its
class and as a side-effect will be about [ten times
faster|http://logging.apache.org/log4j/2.x/manual/async.html#Throughput_of_Logging_With_Location_includeLocationtrue]
because it doesn't use reflection.
Ralph, this looks like a bug:
it basically means that any location-based logic is broken for loggers that
subclass AbstractLoggerWrapper. I've raised LOG4J2-555 for this.
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achieve the above customization; especially taking away existing methods is
> not possible.
> An alternative is for the user to create a wrapper class that exposes only
> the convenience methods for the desired log levels. When _extending_ the
> {{Logger}} API (_adding_ methods), this wrapper class could subclass
> {{org.apache.logging.log4j.spi.AbstractLoggerWrapper}}. When _customizing_
[jira] [Comment Edited] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917298#comment-13917298
]
Remko Popma edited comment on LOG4J2-519 at 3/2/14 6:26 AM:
vibin, thanks a lot for testing this!
The quick fix may be to use %c (lowercase) in your pattern layout instead of %C
(upper case). This will use the logger _name_ instead of its class and as a
side-effect will be about [ten times
faster|http://logging.apache.org/log4j/2.x/manual/async.html#Throughput_of_Logging_With_Location_includeLocationtrue]
(depending on how many threads you use) because it doesn't use reflection.
Ralph, this looks like a bug:
it basically means that any location-based logic is broken for loggers that
subclass AbstractLoggerWrapper. I've raised LOG4J2-555 for this.
was (Author: rem...@yahoo.com):
vibin, thanks a lot for testing this!
The quick fix may be to use %c (lowercase) in your pattern layout instead of %C
(upper case). This will use the logger _name_ instead of its class and as a
side-effect will be about [ten times
faster|http://logging.apache.org/log4j/2.x/manual/async.html#Throughput_of_Logging_With_Location_includeLocationtrue]
because it doesn't use reflection.
Ralph, this looks like a bug:
it basically means that any location-based logic is broken for loggers that
subclass AbstractLoggerWrapper. I've raised LOG4J2-555 for this.
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achieve the above customization; especially taking away existing methods is
> not possible.
> An alternative is for the user to create a wrapper class that exposes only
> the convenience methods for the desired log levels. When _extending_ the
> {{Logger}} API (_adding_ methods), this wrapper class could subclass
> {{org
[jira] [Commented] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917313#comment-13917313
]
Remko Popma commented on LOG4J2-555:
Interesting! I see the difficulty now: apps may call a method in the subclass
or in AbstractLogger, so any stacktrace-walking should work for both.
If custom loggers _must_ use the {{log(Marker, String, Level, Message,
Throwable)}} method, {{AbstractLogger}} should at least make its
{{MessageFactory}} available to subclasses. The fact that this is not available
was what made me call the other {{log}} methods in the custom logger in
LOG4J2-519.
Still, it seems a bit... fragile to ask subclasses to use only that particular
method. I'll think a bit more if there isn't an alternative. Thanks for the
explanation!
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
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-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917313#comment-13917313
]
Remko Popma edited comment on LOG4J2-555 at 3/2/14 7:21 AM:
Interesting! I see the difficulty now: apps may call a method in the subclass
or in AbstractLogger, so any stacktrace-walking should work for both.
If custom loggers _must_ use the {{log(Marker, String, Level, Message,
Throwable)}} method, {{AbstractLogger}} should at least make its
{{MessageFactory}} available to subclasses. The fact that this is not available
was what made me call the other {{log}} methods in the custom logger in
LOG4J2-519. EDIT: I overlooked the getter method for this.
Still, it seems a bit... fragile to ask subclasses to use only that particular
method. I'll think a bit more if there isn't an alternative. Thanks for the
explanation!
was (Author: rem...@yahoo.com):
Interesting! I see the difficulty now: apps may call a method in the subclass
or in AbstractLogger, so any stacktrace-walking should work for both.
If custom loggers _must_ use the {{log(Marker, String, Level, Message,
Throwable)}} method, {{AbstractLogger}} should at least make its
{{MessageFactory}} available to subclasses. The fact that this is not available
was what made me call the other {{log}} methods in the custom logger in
LOG4J2-519.
Still, it seems a bit... fragile to ask subclasses to use only that particular
method. I'll think a bit more if there isn't an alternative. Thanks for the
explanation!
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-519:
---
Attachment: (was: Generate.java)
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java, Generate_old_20140130.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achieve the above customization; especially taking away existing methods is
> not possible.
> An alternative is for the user to create a wrapper class that exposes only
> the convenience methods for the desired log levels. When _extending_ the
> {{Logger}} API (_adding_ methods), this wrapper class could subclass
> {{org.apache.logging.log4j.spi.AbstractLoggerWrapper}}. When _customizing_
> the {{Logger}} API (_removing_ built-in methods), the wrapper class would
> simply not extend AbstractLoggerWrapper, so the only public methods would be
> the methods for the custom log levels.
> As the custom log Levels are not known in advance, Log4J cannot provide
> pre-built wrapper classes for these custom log Levels. However, we don't want
> to ask the users to hand-code such a wrapper class: this is cumbersome and
> error-prone: there are 14 methods for each built-in level. To provide
> comparable functionality for custom log Levels one would need to provide 14
> methods for each custom log Level.
> The proposal is to solve this by providing a tool that generates the source
> code for a wrapper class. The user can specify:
> * the fully qualified name of the class to generate
> * the list of custom levels to support and their {{intLevel}} relative
> strength
> * whether to extend {{Logger}} (and keep the existing built-in methods) or
> have only methods for the custom log levels
> and the tool generates the source code for the wrapper class that has exactly
> the required methods. Users would include this source code in the
[jira] [Updated] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-519:
---
Attachment: Generate.java
Generate_old_20140130.java
I've updated the attached [^Generate.java] tool to keep track of its own FQCN
and always call the {{log(Marker, String, Level, Message, Throwable)}} method.
That should solve the problem even when using %C or other location patterns in
the layout.
Example code below for an *Extended* logger is generated with the command
{code}
java org.apache.logging.log4j.util.Generate$ExtendedLogger com.mycomp.ExtLogger
DIAG=350 NOTICE=450 VERBOSE=550
{code}
to generate a wrapper that only provides convenience methods for the specified
custom levels (and hides the convenience methods for the built-in levels), use
the *CustomLogger* tool:
{code}
java org.apache.logging.log4j.util.Generate$CustomLogger com.mycomp.MyLogger
DEFCON1=350 DEFCON2=450 DEFCON3=550
{code}
Sample generated code:
{code}
package com.mycomp;
import org.apache.logging.log4j.Level;
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.Marker;
import org.apache.logging.log4j.message.Message;
import org.apache.logging.log4j.message.MessageFactory;
import org.apache.logging.log4j.spi.AbstractLogger;
import org.apache.logging.log4j.spi.AbstractLoggerWrapper;
/**
* Extended Logger interface with convenience methods for
* the DIAG, NOTICE and VERBOSE custom log levels.
*/
public final class ExtLogger extends AbstractLoggerWrapper {
private static final long serialVersionUID = 26876940739430L;
private final AbstractLoggerWrapper logger;
private static final String FQCN = ExtLogger.class.getName();
private static final Level DIAG = Level.forName("DIAG", 350);
private static final Level NOTICE = Level.forName("NOTICE", 450);
private static final Level VERBOSE = Level.forName("VERBOSE", 550);
private ExtLogger(final Logger logger) {
super((AbstractLogger) logger, logger.getName(),
logger.getMessageFactory());
this.logger = this;
}
/**
* Returns a custom Logger with the name of the calling class.
*
* @return The custom Logger for the calling class.
*/
public static ExtLogger create() {
final Logger wrapped = LogManager.getLogger();
return new ExtLogger(wrapped);
}
/**
* Returns a custom Logger using the fully qualified name of the Class as
* the Logger name.
*
* @param loggerName The Class whose name should be used as the Logger name.
*If null it will default to the calling class.
* @return The custom Logger.
*/
public static ExtLogger create(final Class loggerName) {
final Logger wrapped = LogManager.getLogger(loggerName);
return new ExtLogger(wrapped);
}
/**
* Returns a custom Logger using the fully qualified name of the Class as
* the Logger name.
*
* @param loggerName The Class whose name should be used as the Logger name.
*If null it will default to the calling class.
* @param messageFactory The message factory is used only when creating a
*logger, subsequent use does not change the logger but will log
*a warning if mismatched.
* @return The custom Logger.
*/
public static ExtLogger create(final Class loggerName, final
MessageFactory factory) {
final Logger wrapped = LogManager.getLogger(loggerName, factory);
return new ExtLogger(wrapped);
}
/**
* Returns a custom Logger using the fully qualified class name of the value
* as the Logger name.
*
* @param value The value whose class name should be used as the Logger
*name. If null the name of the calling class will be used as
*the logger name.
* @return The custom Logger.
*/
public static ExtLogger create(final Object value) {
final Logger wrapped = LogManager.getLogger(value);
return new ExtLogger(wrapped);
}
/**
* Returns a custom Logger using the fully qualified class name of the value
* as the Logger name.
*
* @param value The value whose class name should be used as the Logger
*name. If null the name of the calling class will be used as
*the logger name.
* @param messageFactory The message factory is used only when creating a
*logger, subsequent use does not change the logger but will log
*a warning if mismatched.
* @return The custom Logger.
*/
public static ExtLogger create(final Object value, final MessageFactory
factory) {
final Logger wrapped = LogManager.getLogger(value, factory);
return new ExtLogger(wrapped);
}
/**
* Returns a custom Logg
[jira] [Updated] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-519:
---
Description:
Please try out the attached [^Generate.java] tool that provides the
functionality described below and give feedback if you notice any issues.
{anchor:Extending}
*[#Extending] the Logger interface*
LOG4J2-41 added support for custom log Levels. Users can now log messages at
the new custom level by passing the custom level to the {{Logger.log()}} method:
{code}
final Logger logger = LogManager.getLogger();
final Level VERBOSE = Level.forName("VERBOSE", 550);
logger.log(VERBOSE, "a verbose message");
logger.log(VERBOSE, "another message");
{code}
However, custom levels are not as easy to use as the built-in levels: one needs
to call the generic {{log()}} method and pass a {{Level}} parameter. Built-in
levels on the other hand have a set of convenience methods on the Logger
interface. For example, the Logger interface has 14 debug methods that support
the DEBUG level:
{code}
debug(Marker, Message)
debug(Marker, Message, Throwable)
debug(Marker, Object)
debug(Marker, Object, Throwable)
debug(Marker, String)
debug(Marker, String, Object...)
debug(Marker, String, Throwable)
debug(Message)
debug(Message, Throwable)
debug(Object)
debug(Object, Throwable)
debug(String)
debug(String, Object...)
debug(String, Throwable)
{code}
Similar method sets exist for the other built-in levels.
Several people have expressed the desire to have the same ease of use with
custom levels, so after declaring a custom VERBOSE level, we would like to be
able to use code like this:
{code}
logger.verbose("a verbose message"); // no need to pass the VERBOSE level as a
parameter
logger.verbose("another message");
{code}
{anchor:Customizing}
*[#Customizing] the Logger interface*
In the above use case, convenience methods were _added_ to the Logger
interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
... methods for the built-in log levels.
There is another use case, Domain Specific Language loggers, where we want to
_replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
all-custom methods.
For example, for medical devices we could have only {{critical()}},
{{warning()}}, and {{advisory()}} methods. Another example could be a game that
has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
Finally, if it were possible to hide existing log levels, users could customize
the Logger interface to match their requirements. Some people may not want to
have a {{FATAL}} or a {{TRACE}} level, for example. They would like to be able
to create a custom Logger that only has {{debug()}}, {{info()}}, {{warn()}} and
{{error()}} methods.
{anchor:wrapper}
*Proposal: Generate source code for a Logger [#wrapper]*
Common log4j usage is to get an instance of the {{Logger}} interface from the
{{LogManager}} and call the methods on this interface. This makes it hard to
achieve the above customization; especially taking away existing methods is not
possible.
An alternative is for the user to create a wrapper class that exposes only the
convenience methods for the desired log levels. When _extending_ the {{Logger}}
API (_adding_ methods), this wrapper class could subclass
{{org.apache.logging.log4j.spi.AbstractLoggerWrapper}}. When _customizing_ the
{{Logger}} API (_removing_ built-in methods), the wrapper class would simply
not extend AbstractLoggerWrapper, so the only public methods would be the
methods for the custom log levels.
As the custom log Levels are not known in advance, Log4J cannot provide
pre-built wrapper classes for these custom log Levels. However, we don't want
to ask the users to hand-code such a wrapper class: this is cumbersome and
error-prone: there are 14 methods for each built-in level. To provide
comparable functionality for custom log Levels one would need to provide 14
methods for each custom log Level.
The proposal is to solve this by providing a tool that generates the source
code for a wrapper class. The user can specify:
* the fully qualified name of the class to generate
* the list of custom levels to support and their {{intLevel}} relative strength
* whether to extend {{Logger}} (and keep the existing built-in methods) or have
only methods for the custom log levels
and the tool generates the source code for the wrapper class that has exactly
the required methods. Users would include this source code in the project where
they want to use custom log levels.
{anchor:GeneratedWrapperUsage}
Note that no Log4J API changes are required to support this functionality.
Users would create instances of the wrapper by calling a factory method on the
wrapper class, instead of calling the {{LogManager.getLogger()}} methods.
For example, instead of writing:
{code}
import org.apache.logging.log4j.Level;
import org.apache.logging.log4j.Lo
[jira] [Commented] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917362#comment-13917362
]
Remko Popma commented on LOG4J2-555:
With hindsight I probably saw the {{getMessageFactory}} method but thought I
could avoid using it.
I just updated the Generate tool in LOG4J2-519 and having to go through the
{{log(Marker, String, Level, Message, Throwable)}} method was quite painful.
Method implementations are now three or four lines instead of one line, and
there is a need to pass {{null}} parameters now.
I'm not complaining, just noticing that the previous implementation was more
intuitive so documentation is probably necessary if the longer and less
intuitive implementation is the only correct way to do things.
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917419#comment-13917419
]
Remko Popma commented on LOG4J2-555:
I keep thinking there must be a more robust way to achieve this... So far, the
best I've been able to come up with is instead of having a single FQCN, we can
have a {{Set}} of all FQCNs of the class hierarchy of loggers that extend
AbstractLogger. When a logger instance is constructed, it builds that Set in
the constructor, starting with {{getClass()}}, then keep calling
{{cls.getParent()}} until either {{AbstractLogger}} is found or {{null}}.
So for a generated extended logger the set would be { {{ExtendedLogger,
AbstractLoggerWrapper, AbstractLogger}} }, and for a "normal" logger obtained
from {{LogManager}} the set would be { {{core.Logger, AbstractLogger}} }.
Unfortunately this breaks down for custom loggers that don't extend from
{{AbstractLoggerWrapper}} but instead _have an_ {{AbstractLoggerWrapper}} field
that they delegate calls to. How to add the FQCN of such custom loggers to the
FQCN Set of the {{AbstractLoggerWrapper}} that they delegate to? (And wouldn't
this just move the problem: now custom logger authors need to remember to add
the custom logger FQCN to the FQCN Set of its {{AbstractLoggerWrapper}} field,
which is almost as bad as saying "don't use these methods, you can call only
this one"...) :-(
And then of course there is the cost-benefit trade-off: how much effort to
spend on this... Perhaps just updating the docs is good enough. I just wanted
to write my thoughts down, I may revisit this later.
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917569#comment-13917569
]
Remko Popma commented on LOG4J2-555:
Hey Gary! I missed your comment. Yeah, I know! The generated code now basically
looks very similar to the AbstractLogger implementation of the convenience
methods for the built-in levels:
{code}
public void customLevel(...) {
if (logger.isEnabled(lots, of, parameters)) {
Message msg = createMessage();
logger.log(marker, fqcn, level, msg, throwable);
}
}
{code}
Where before it looked like:
{code}
public void customLevel(...) {
logger.log(available, parameters);
}
{code}
Perhaps a nice solution for this would also allow the code in AbstractLogger to
be simplified...
Refactoring may be possible, both in the Generate tool and in AbstractLogger.
Be aware there are some subtleties with the Throwable that may or may not be
the last parameter in logging methods that take a varargs parameter.
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-543) Add JDO database appender
[ https://issues.apache.org/jira/browse/LOG4J2-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917643#comment-13917643 ] Remko Popma commented on LOG4J2-543: Just FYI, usually I would prefer to leave the ticket open in case someone else wants to do the work to address this. But since you're the one who created the ticket I guess it's okay for you to say you no longer need this (or not yet). > Add JDO database appender > - > > Key: LOG4J2-543 > URL: https://issues.apache.org/jira/browse/LOG4J2-543 > Project: Log4j 2 > Issue Type: New Feature > Components: Appenders >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker > Labels: appender, jdo > > DataNucleus includes support for the JDO API which would be nice to support. > This expands data source support quite significantly, and it would work > better for non-SQL databases. See for example [DataNucleus > JDO|http://www.datanucleus.org/products/accessplatform_3_3/jdo/api.html]. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-346) Cyclic dependency in OSGi-context. Apache Log4j SLF4J Binding <-> slf4j-api
[
https://issues.apache.org/jira/browse/LOG4J2-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917652#comment-13917652
]
Remko Popma commented on LOG4J2-346:
It's probably best to aim to match OSGi users expectations. So if it is common
practice to have a {{some-functionality.jar}} and a
{{some-functionality-bundle.jar}} then I'm fine with that.
About the module names matching the artifact names, I think you're right about
this being a recommended practice, but adding {{"log4j-"}} to the beginning and
{{"-bundle"}} to the end of every folder name just makes the names 11 chars
longer without actually adding meaning. :-( Not a fan... But if everyone
prefers it that way then I can live with it.
> Cyclic dependency in OSGi-context. Apache Log4j SLF4J Binding <-> slf4j-api
> ---
>
> Key: LOG4J2-346
> URL: https://issues.apache.org/jira/browse/LOG4J2-346
> Project: Log4j 2
> Issue Type: Bug
> Components: Core, SLF4J Bridge
>Affects Versions: 2.0-beta4, 2.0-beta8, 2.0-beta9
> Environment: OSGi R5 / Apache Felix 4.x
>Reporter: Roland Weiglhofer
>Priority: Blocker
> Labels: Bundle, OSGi, SLF4J
> Fix For: 2.0-rc2
>
> Attachments: 0001-Add-SLF4J-related-bundles.patch,
> log4j2-slf4j-impl.patch
>
>
> The bundle "Apache Log4j SLF4J Binding" (2.0.0.beta8) has an unresolved
> dependency to the package org.slf4j which is exported by the slf4j-api
> bundle. The Slf4j-api bundle has also an unresolved dependency to the package
> org.slf4j.impl which is exported by the bundle "Apache Log4j SLF4J Binding".
> Without the slf4j-api everything works. But the Slf4j-api bundle is needed
> because of given dependencies of third-party-bundles. The "Apache Log4j SLF4J
> Binding" bundle should also export the package org.slf4j.
>
>ID|State |Level|Name
> 0|Active |0|System Bundle (4.2.1)
> 4|Active |2|Apache Felix Bundle Repository (1.6.6)
> 5|Active |2|Apache Felix Configuration Admin Service (1.6.0)
> 6|Active |2|Apache Felix Gogo Command (0.12.0)
> 7|Active |2|Apache Felix Gogo Runtime (0.10.0)
> 8|Active |2|Apache Felix Gogo Shell (0.10.0)
> 9|Resolved |2|Apache Felix Security Provider (2.2.0)
>10|Active |2|Apache Felix Shell Service (1.4.3)
>11|Installed |2|Apache Log4j 1.x Compatibility API (2.0.0.beta8)
>12|Active |2|Apache Log4j API (2.0.0.beta8)
>13|Installed |2|Apache Log4j Commons Logging Bridge (2.0.0.beta8)
>14|Installed |2|Apache Log4j Core (2.0.0.beta8)
>15|Installed |2|Apache Log4j SLF4J Binding (2.0.0.beta8)
>16|Active |2|cal10n-api (0.7.4)
>17|Active |2|Commons IO (2.4.0)
>18|Active |2|Commons Lang (2.6.0)
>19|Active |2|Data mapper for Jackson JSON processor (1.9.13)
>20|Active |2|Jackson JSON processor (1.9.13)
>21|Active |2|JSON.simple (1.1.1)
>22|Installed |2|slf4j-api (1.5.11)
>23|Installed |2|slf4j-ext (1.5.11)
> Unresolved constraint in bundle org.apache.logging.log4j-slf4j-impl [15]:
> Unable to resolve 15.0: missing requirement [15.0] osgi.wiring.package;
> (osgi.wiring.package=org.slf4j) [caused by: Unable to resolve 22.0: missing
> requirement [22.0] osgi.wiring.package;
> (&(osgi.wiring.package=org.slf4j.impl)(version>=1.5.5))]
> Unresolved constraint in bundle slf4j.api [22]: Unable to resolve 22.0:
> missing requirement [22.0] osgi.wiring.package;
> (&(osgi.wiring.package=org.slf4j.impl)(version>=1.5.5))
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-543) Add JDO database appender
[ https://issues.apache.org/jira/browse/LOG4J2-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917653#comment-13917653 ] Remko Popma commented on LOG4J2-543: Unless adding something would somehow break existing stuff, I would say that adding things is okay at any time... > Add JDO database appender > - > > Key: LOG4J2-543 > URL: https://issues.apache.org/jira/browse/LOG4J2-543 > Project: Log4j 2 > Issue Type: New Feature > Components: Appenders >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker > Labels: appender, jdo > > DataNucleus includes support for the JDO API which would be nice to support. > This expands data source support quite significantly, and it would work > better for non-SQL databases. See for example [DataNucleus > JDO|http://www.datanucleus.org/products/accessplatform_3_3/jdo/api.html]. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-547) Update LoggerStream API
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917734#comment-13917734 ] Remko Popma commented on LOG4J2-547: If you need AbstractLogger functionality that is not in the Logger interface you have little choice but to fail if this is not available... So casting is okay, I think. > Update LoggerStream API > --- > > Key: LOG4J2-547 > URL: https://issues.apache.org/jira/browse/LOG4J2-547 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker >Assignee: Ralph Goers > Fix For: 2.0 > > Attachments: 0001-PrintStream-API-update.patch, > Add_caller_info_tests.patch, log4j2-loggerStream.patch > > > I've got some ideas on how to improve the LoggerStream idea that I added a > little while ago. The main thing I'd like to do is extract an interface from > it, rename the default implementation to SimpleLoggerStream (part of the > SimpleLogger stuff), and allow log4j implementations to specify a different > implementation if desired. > In doing this, I'm not sure where specifically I'd prefer the getStream > methods to be. Right now, it's in Logger, but really, it could be in > LoggerContext instead. I don't think I should be required to get a Logger > just to get a LoggerStream. > Now if only the java.io package used interfaces instead of classes. This > would be so much easier to design! -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13918962#comment-13918962
]
Remko Popma commented on LOG4J2-555:
I do have a refactoring in mind that would replace the four lines of code with
one line. This would be applicable to both the Generate tool and
AbstractLogger. The goal is merely to reduce the almost-but-not-quite-duplicate
code and still work correctly for the FQCN issue mentioned in this ticket. Not
sure it it will help you with the stream stuff.
Work is extremely busy now and I may not be able to work on this in the next
few weeks.
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923148#comment-13923148
]
Remko Popma commented on LOG4J2-519:
Bruce, it looks like the FQCN is declared, but never used in your example
ExtLogger. This means that the FQCN of AbstractLogger will be used and the
caller location in the log file will be listed as ExtLogger (because ExtLogger
calls a method in AbstractLogger) but we want to list MyApp (the class calling
ExtLogger) - this is basically the issue vibin reported above... Note that I've
only looked at the code, not tried to run it.
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java, Generate_old_20140130.java
>
>
> Please try out the attached [^Generate.java] tool that provides the
> functionality described below and give feedback if you notice any issues.
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achieve the above customization; especially taking away existing methods is
> not possible.
> An alternative is for the user to create a wrapper class that exposes only
> the convenience methods for the desired log levels. When _extending_ the
> {{Logger}} API (_adding_ methods), this wrapper class could subclass
> {{org.apache.logging.log4j.spi.AbstractLoggerWrapper}}. When _customizing_
> the {{Logger}} API (_removing_ built-in methods), the wrapper class would
> simply not extend AbstractLoggerWrapper, so the only public methods would be
> the methods for the custom log levels.
> As the custom log Levels are not known in advance, Log4J cannot provide
> pre-built wrapper classes for these custom log Levels. However, we don't want
> to ask the users to hand-code such a wrapper class: this is cumbersome and
> error-prone: there are 14 methods for each built-in level. To provide
> comparable functionality for custom log Levels one wou
[jira] [Commented] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923194#comment-13923194
]
Remko Popma commented on LOG4J2-555:
I won't have time to work out the details for another 2 weeks or so, so let me
draw the big picture of the refactoring I have in mind.
The goal of the refactoring is to end up with a single {{doLog()}} method that
both AbstractLogger and Extended/Custom Loggers can call.
So for example in AbstractLogger
{code}
public void error(final String message, final Object... params) {
if (isEnabled(Level.ERROR, null, message, params)) {
final Message msg = messageFactory.newMessage(message, params);
log(null, FQCN, Level.ERROR, msg, msg.getThrowable());
}
}
{code}
the above would become
{code}
public void error(final String message, final Object... params) {
doLog(Enabled.stringVarargs, null, FQCN, Level.ERROR,
MsgBuilder.stringVarargs,
message, null, params);
}
{code}
The idea is to create enums for all {{isEnabled()}} methods, and passing this
enum value to the {{doLog}} method instead of calling the {{isEnabled}} method
directly in {{error()}}.
The new {{doLog}} method would look like this:
{code}
private void doLog(Enabled enabled, Marker marker, String FQCN, Level level,
MsgBuilder builder,
String message, Throwable throwable, Object... params) {
Message msg = builder.build(message, throwable, params);
if (enabled.isEnabled(this, level, marker, msg, throwable)) {
log(marker, FQCN, level, msg, msg.getThrowable());
}
}
{code}
Each of the 5 enum values for {{Enabled}} has a different implementation of the
{{isEnabled}} method that ignores some parameters, so we end up with the same
behaviour as what AbstractLogger currently does, with a few extra method
invocations inbetween (that Hotspot can easily optimize out).
A similar enum mechanism can be used to create the {{Message}} object.
So the trade-off is we gain a simpler implementation for the existing
convenience methods
(6 levels times 14 methods = 84 methods where we go from 3-4 lines to 1 line).
And in return we need to add the new {{doLog}} method above as well as enums
for Enabled and MsgBuilder.
The enums can be protected static so they can be re-used in Extended/Custom
loggers.
This also means there would be no need for complex tracking of FQCNs in the
class hierarchy.
Thoughts?
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
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-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923194#comment-13923194
]
Remko Popma edited comment on LOG4J2-555 at 3/7/14 1:09 AM:
I won't have time to work out the details for another 2 weeks or so, so let me
draw the big picture of the refactoring I have in mind.
The goal of the refactoring is to reduce the lines of code in the convenience
methods (what is currently almost, but not quite duplicate code). These methods
would end up delegating to a single {{doLog()}} method (in both AbstractLogger
and Extended/Custom Loggers, not sure about the Writers). For example, the
current code in AbstractLogger looks like this:
{code}
public void error(final String message, final Object... params) {
if (isEnabled(Level.ERROR, null, message, params)) {
final Message msg = messageFactory.newMessage(message, params);
log(null, FQCN, Level.ERROR, msg, msg.getThrowable());
}
}
{code}
the above would become
{code}
public void error(final String message, final Object... params) {
doLog(Enabled.stringVarargs, null, FQCN, Level.ERROR,
MsgBuilder.stringVarargs,
message, null, params);
}
{code}
The idea is to create enums for all {{isEnabled()}} methods, and passing this
enum value to the {{doLog}} method instead of calling the {{isEnabled}} method
directly in {{error()}}.
The new {{doLog}} method would look something like this:
{code}
private void doLog(Enabled enabled, Marker marker, String FQCN, Level level,
MsgBuilder builder,
String message, Throwable throwable, Object... params) {
Message msg = builder.build(message, throwable, params);
if (enabled.isEnabled(this, level, marker, msg, throwable)) {
log(marker, FQCN, level, msg, msg.getThrowable());
}
}
{code}
Each of the 5 enum values for {{Enabled}} has a different implementation of the
{{isEnabled}} method that ignores some parameters, so we end up with the same
behaviour as what AbstractLogger currently does, with a few extra method
invocations in between (that Hotspot can easily optimize out).
A similar enum mechanism can be used to create the {{Message}} object
(tentatively named {{MsgBuilder}}).
So the trade-off is we gain a simpler implementation for the existing
convenience methods
(6 levels times 14 methods = 84 methods where we go from 3-4 lines to 1 line).
And in return we need to add the new {{doLog}} method above as well as enums
for Enabled and MsgBuilder. The enums can be public static inner classes of
AbstractLogger so they can be re-used in Extended/Custom loggers.
This also means there would be no need to track FQCNs in the class hierarchy.
I'm kind of moving away from any kind of central FQCN tracking. It is much
simpler if each AbstractLogger subclass manages its own FQCN.
Thoughts?
was (Author: rem...@yahoo.com):
I won't have time to work out the details for another 2 weeks or so, so let me
draw the big picture of the refactoring I have in mind.
The goal of the refactoring is to end up with a single {{doLog()}} method that
both AbstractLogger and Extended/Custom Loggers can call.
So for example in AbstractLogger
{code}
public void error(final String message, final Object... params) {
if (isEnabled(Level.ERROR, null, message, params)) {
final Message msg = messageFactory.newMessage(message, params);
log(null, FQCN, Level.ERROR, msg, msg.getThrowable());
}
}
{code}
the above would become
{code}
public void error(final String message, final Object... params) {
doLog(Enabled.stringVarargs, null, FQCN, Level.ERROR,
MsgBuilder.stringVarargs,
message, null, params);
}
{code}
The idea is to create enums for all {{isEnabled()}} methods, and passing this
enum value to the {{doLog}} method instead of calling the {{isEnabled}} method
directly in {{error()}}.
The new {{doLog}} method would look like this:
{code}
private void doLog(Enabled enabled, Marker marker, String FQCN, Level level,
MsgBuilder builder,
String message, Throwable throwable, Object... params) {
Message msg = builder.build(message, throwable, params);
if (enabled.isEnabled(this, level, marker, msg, throwable)) {
log(marker, FQCN, level, msg, msg.getThrowable());
}
}
{code}
Each of the 5 enum values for {{Enabled}} has a different implementation of the
{{isEnabled}} method that ignores some parameters, so we end up with the same
behaviour as what AbstractLogger currently does, with a few extra method
invocations inbetween (that Hotspot can easily optimize out).
A similar enum mechanism can be used to create the {{Message}} object.
So the trade-off is we gain a simpler implementation for the existing
convenience methods
(6 levels times 14 methods = 84 methods where we go from 3-4 lines to 1 line).
And in return we need to add the new {{doLog}} method above as
[jira] [Commented] (LOG4J2-562) Improve ability to create custom extended logger
[
https://issues.apache.org/jira/browse/LOG4J2-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13924804#comment-13924804
]
Remko Popma commented on LOG4J2-562:
I had a look at the attached patch. It looks like this is a single patch for a
number of initiatives. It may be better to split this up so they can be
considered in isolation. Is it possible to separate the Writer/OutputStream
related changes from the LoggerExtension changes?
The idea of the {{LoggerExtension}} and {{ExtensibleLogger}} interfaces is
interesting. It does automatically provide the correct FQCN for custom/extended
loggers. On the other hand, the proposed interfaces and methods add quite a bit
of public API surface and their use may be harder to understand than simply
extending AbstractLogger or AbstractLoggerWrapper. Also, the proposed solution
sometimes helps to reduce code (SLF4JLogger in the patch), but sometimes
requires more code (jcl/Log4jLog in the patch). So I'm not sure that the
overall trade-off is a good one, especially since extending loggers will be
fairly rare...
Do you think the delegation idea proposed in LOG4J2-555 will be useful in the
Writers/OutputStreams? I'll try to flesh out that idea to make it more concrete.
> Improve ability to create custom extended logger
>
>
> Key: LOG4J2-562
> URL: https://issues.apache.org/jira/browse/LOG4J2-562
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Reporter: Bruce Brouwer
> Attachments: log4j2-loggerExtension.patch
>
>
> Create a LoggerExtension from the original logger which simply remembers the
> FQCN that will ultimately be the extension.
> Also by doing this, we can switch a bunch of methods that ended up being
> public back to protected. I'm guessing they became public so extensions could
> call them.
> This can simplify extensions (such as slf4j, jcl, custom extensions, logger
> streams) so they don't have to pass in the FQCN to that special log method on
> AbstractLogger anymore. Also, you don't have to wrap every extended log
> method with a check to see if the logging is enabled. Finally, you don't need
> to have any access to the MessageFactory. This even has to potential to
> eliminate AbstractLoggerWrapper.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-555:
---
Attachment: LOG4J2-555-delegate.patch
Inspired by Gary's call for a refactoring, please find attached patch. This
eliminates most of the semi-duplicate code in AbstractLogger and reduces the
class length by 115 lines.
It also provides a clear example to follow for custom/extended logger authors
(I hope). At least the code generated by the tool attached to LOG4J2-519 can be
reduced by following the same pattern.
Thoughts?
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
> Attachments: LOG4J2-555-delegate.patch
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925106#comment-13925106
]
Remko Popma commented on LOG4J2-555:
I completely agree that if there is any performance impact at all, we should
not do this.
Also, to clarify, I really don't want to over-complicate things. The idea I
mentioned in an earlier comment of having a set of FQCNs was just a thought
experiment and I now think that the benefit for custom loggers is not worth any
added complexity. Custom loggers are a rare case and simply documenting "custom
loggers must use the abstract {{log(Marker, String, Level, Message,
Throwable)}} method because they must specify _their own_ FQCN" is probably
sufficient.
The attached patch reduces complexity a little bit in many places (7 x 14
methods) and adds complexity in one place (the enums and the {{doLog}} method).
I'd like feedback on whether other people think this is a good trade-off.
Perhaps this is just a matter of taste? Anyway, feedback welcome.
I'll do some performance testing and post the results.
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
> Attachments: LOG4J2-555-delegate.patch
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925138#comment-13925138
]
Remko Popma commented on LOG4J2-555:
I did some performance tests but did not see any significant difference.
SimplePerfTest gave very similar results before and after applying the patch.
I also ran the {{org.apache.logging.log4j.core.async.perftest.PerfTestDriver}}
tests with
{{-DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector}}
to make all loggers asynchronous. Again the differences between before and
after are within the standard deviation:
|| ||Before|| ||After (1)|| ||After (2)|| ||
|| ||Ops/sec||stdev||Ops/sec||stdev||Ops/sec||stdev||
|1 thread| 4,306,635| 680,748|4,035,179| 154,953|
4,727,986| 1,274,861|
|2 threads| 3,177,743| 2,204,713| 2,223,271| 722,988|
2,786,508| 700,968|
|4 threads| 3,020,324| 1,960,143| 3,443,250| 1,643,893|
3,839,109| 2,997,553|
So I guess it is just a matter of do we like the original code better or the
new code better?
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
> Attachments: LOG4J2-555-delegate.patch
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925346#comment-13925346
]
Remko Popma commented on LOG4J2-555:
Hotspot compiles to native code if the method is "hot" enough (>40,000 or
50,000 calls). During the compile, I expect the extra method invocations are
optimized away.
In fact, since SimplePerfTest uses the DefaultConfiguration (level=ERROR) but
the test logs at DEBUG level, I wouldn't be surprised if Hotspot optimizes the
whole loop away because it isn't actually causing any side-effects (doing any
work)...
You'd be surprised at how different what actually gets executed looks from the
original java source. http://m.youtube.com/watch?v=UwB0OSmkOtQ
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
> Attachments: LOG4J2-555-delegate.patch
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925443#comment-13925443
]
Remko Popma commented on LOG4J2-555:
The enums (like MsgBuilder) use the double-dispatch pattern as a clean way to
avoid introducing a conditional. Avoiding a branch means the CPU doesn't need
to do branch prediction (potential cache miss/pipeline stall).
The purpose of the refactoring in the patch was to
# reduce semi-duplicate code in many AbstractLogger methods
# extract elements of the {{if(isEnabled(...){log(...);\}_}} pattern so these
elements can be re-used in extended/custom loggers
# these reusable elements in turn make managing the FQCN less onerous for
custom/extended loggers: these loggers don't need to repeat the
{{if(isEnabled(...){log(...);\}_}} pattern but instead can have a one-line
implementation that calls the {{doLog(...)}} method.
So to me, this patch solves the FQCN problem this ticket was created for. If we
decide to reject this patch I don't mind not having a solution but just keeping
things the way they are. I don't think the FQCN is a huge problem and I would
not be in favor of much added complexity just to make FQCN easier to manage for
the rare use case of custom/extended loggers. Any extra classes/interfaces
should carry their own weight so to speak and have benefits other than FQCN,
IMHO.
Would the stream/writer loggers benefit from the patch attached here? (I
haven't checked...)
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
> Attachments: LOG4J2-555-delegate.patch
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13932812#comment-13932812
]
Remko Popma commented on LOG4J2-555:
At first glance this accomplishes the same as what I was trying to do, but
without the enums. It looks simpler. I need to take a more detailed look later,
but just looking at AbstractLogger I like your patch better than my solution.
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
> Attachments: LOG4J2-555-delegate.patch, log4j2-555-bbrouwer.patch
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-565) Log4j2 loading time
[
https://issues.apache.org/jira/browse/LOG4J2-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13932825#comment-13932825
]
Remko Popma commented on LOG4J2-565:
In your configuration, can you change the first line to
{code}
...
{code}
and post a comment with the internal log4j2 status log output that should
appear on the console?
That should give some indication of what log4j is doing at startup.
> Log4j2 loading time
> ---
>
> Key: LOG4J2-565
> URL: https://issues.apache.org/jira/browse/LOG4J2-565
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.0-rc1
> Environment: Using ejre1.6.0_25 in an ARM926EJ-S rev 5 (v5l)
>Reporter: Tiago Cardoso
>
> Everything runs fine on the Desktop computer, but the embedded system
> struggles to obtain the Logger.
> It takes 17 seconds just to run this line:
> Logger logger = LogManager.getLogger("testLogger");
> The classpath is empty and the whole applications is just:
> public static void main(String[] arg){
> System.out.println("Starting application:" + System.currentTimeMillis());
> Logger logger = LogManager.getLogger("testLogger");
> logger.trace("Going to leave application." + System.currentTimeMillis());
> System.exit(1);
> }
> The same system is able to run a client graphic application without this kind
> of event.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-565) Log4j2 loading time
[
https://issues.apache.org/jira/browse/LOG4J2-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13933144#comment-13933144
]
Remko Popma commented on LOG4J2-565:
It looks like you unzipped the log4j api and core jars and zipped the contents
back into your {{/var/media/AppJar.jar}} jar file. If this file is very large,
log4j startup will be slow.
Log4j2 has a plugin model, where all components (loggers, appenders, etc) are
plugins. The log4j2 plugin manager will open a {{JarInputStream}} to the jar
that contains it, and loop over *all* entries in this jar to test if their
package name matches "org.apache.logging.log4j.core" (or optionally any
configured custom plugin packages). If the package name matches, and the entry
(the class) has the right annotations, it is registered as a plugin component.
The standard log4j-core-2.0.jar is less than 700KB with less than 500 entries.
A linear scan over all {{JarEntry}} s in the standard core jar file takes
100-150 milliseconds. How many entries does your {{AppJar.jar}} contain? Can
you try keeping the log4j-core-2.0.jar separate?
> Log4j2 loading time
> ---
>
> Key: LOG4J2-565
> URL: https://issues.apache.org/jira/browse/LOG4J2-565
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.0-rc1
> Environment: Using ejre1.6.0_25 in an ARM926EJ-S rev 5 (v5l)
>Reporter: Tiago Cardoso
>
> Everything runs fine on the Desktop computer, but the embedded system
> struggles to obtain the Logger.
> It takes 17 seconds just to run this line:
> Logger logger = LogManager.getLogger("testLogger");
> The classpath is empty and the whole applications is just:
> public static void main(String[] arg){
> System.out.println("Starting application:" + System.currentTimeMillis());
> Logger logger = LogManager.getLogger("testLogger");
> logger.trace("Going to leave application." + System.currentTimeMillis());
> System.exit(1);
> }
> The same system is able to run a client graphic application without this kind
> of event.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-566) Configure RollingRandomAccessFileAppender buffer size
Remko Popma created LOG4J2-566: -- Summary: Configure RollingRandomAccessFileAppender buffer size Key: LOG4J2-566 URL: https://issues.apache.org/jira/browse/LOG4J2-566 Project: Log4j 2 Issue Type: Improvement Components: Appenders Affects Versions: 2.0-rc1 Reporter: Remko Popma Assignee: Remko Popma Fix For: 2.0-rc2 Make buffer size of RollingRandomAccessFileAppender configurable similar to what was done for RandomAccessFileAppender in LOG4J2-402. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-402) Configure RandomAccessFileAppender buffer size
[ https://issues.apache.org/jira/browse/LOG4J2-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13933152#comment-13933152 ] Remko Popma commented on LOG4J2-402: Good catch! I've created LOG4J2-566 for this. Thanks for bringing it to our attention! > Configure RandomAccessFileAppender buffer size > -- > > Key: LOG4J2-402 > URL: https://issues.apache.org/jira/browse/LOG4J2-402 > Project: Log4j 2 > Issue Type: New Feature > Components: API, Appenders >Affects Versions: 2.0-beta8 > Environment: LOG4J2-beta8, java 1.7, eclipse kepler, windows xp.. >Reporter: Chandra Sekhar Kakarla > Labels: documentation, features, newbie > Fix For: 2.0-rc1 > > Original Estimate: 96h > Remaining Estimate: 96h > > Add feature for Appenders to support buffer, which will store log in to > memory(app/system) and write in to file when it reaches buffer size provided. > (http://stackoverflow.com/questions/18785611/way-to-implement-buffered-io-using-log4j2) > this is possible? > If this feature is already available, could you please provide me reference > for it?. > Thanks in advance. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-566) Configure RollingRandomAccessFileAppender buffer size
[ https://issues.apache.org/jira/browse/LOG4J2-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1392#comment-1392 ] Remko Popma commented on LOG4J2-566: Oh wow, that is fast! Would it be possible for you to submit this as a patch? > Configure RollingRandomAccessFileAppender buffer size > - > > Key: LOG4J2-566 > URL: https://issues.apache.org/jira/browse/LOG4J2-566 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.0-rc1 >Reporter: Remko Popma >Assignee: Remko Popma > Fix For: 2.0-rc2 > > Attachments: RollingRandomAccessFile.zip > > > Make buffer size of RollingRandomAccessFileAppender configurable similar to > what was done for RandomAccessFileAppender in LOG4J2-402. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-565) Log4j2 loading time
[
https://issues.apache.org/jira/browse/LOG4J2-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13933376#comment-13933376
]
Remko Popma commented on LOG4J2-565:
Looks like my analysis was incorrect or incomplete. To be clear, the load time
you are experiencing is not normal. I think a normal load time is like 100-150
milliseconds.
Still, for some reason the plugin manager is taking a long time locating the
log4j plugins... Two questions to help us try to reproduce the issue: do you
have any custom log4j plugins, or does your log4j2.xml configuration have a
value in the {{packages}} attribute? For example:
{code}
...
{code}
Also, could you tell us what you see when you print
{{System.out.println(System.getProperty("java.class.path"));}} ?
> Log4j2 loading time
> ---
>
> Key: LOG4J2-565
> URL: https://issues.apache.org/jira/browse/LOG4J2-565
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.0-rc1
> Environment: Using ejre1.6.0_25 in an ARM926EJ-S rev 5 (v5l)
>Reporter: Tiago Cardoso
>
> Everything runs fine on the Desktop computer, but the embedded system
> struggles to obtain the Logger.
> It takes 17 seconds just to run this line:
> Logger logger = LogManager.getLogger("testLogger");
> The classpath is empty and the whole applications is just:
> public static void main(String[] arg){
> System.out.println("Starting application:" + System.currentTimeMillis());
> Logger logger = LogManager.getLogger("testLogger");
> logger.trace("Going to leave application." + System.currentTimeMillis());
> System.exit(1);
> }
> The same system is able to run a client graphic application without this kind
> of event.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935960#comment-13935960
]
Remko Popma commented on LOG4J2-519:
This weekend I won't have time (one more push for an exam I have next week),
but after that I'll look at the patch for LOG4J2-555 and also update the
generator tool.
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java, Generate_old_20140130.java
>
>
> Please try out the attached [^Generate.java] tool that provides the
> functionality described below and give feedback if you notice any issues.
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achieve the above customization; especially taking away existing methods is
> not possible.
> An alternative is for the user to create a wrapper class that exposes only
> the convenience methods for the desired log levels. When _extending_ the
> {{Logger}} API (_adding_ methods), this wrapper class could subclass
> {{org.apache.logging.log4j.spi.AbstractLoggerWrapper}}. When _customizing_
> the {{Logger}} API (_removing_ built-in methods), the wrapper class would
> simply not extend AbstractLoggerWrapper, so the only public methods would be
> the methods for the custom log levels.
> As the custom log Levels are not known in advance, Log4J cannot provide
> pre-built wrapper classes for these custom log Levels. However, we don't want
> to ask the users to hand-code such a wrapper class: this is cumbersome and
> error-prone: there are 14 methods for each built-in level. To provide
> comparable functionality for custom log Levels one would need to provide 14
> methods for each custom log Level.
> The proposal is to solve this by providing a tool that generates the source
> code for a wrapper class. The user can specify:
> * the fully qualified name of the class to generate
> * the list of custom leve
[jira] [Commented] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935983#comment-13935983
]
Remko Popma commented on LOG4J2-555:
Thanks for the overview. It is helpful to not only know what you are doing but
also why you are doing it.
Thanks also for running the performance test. These numbers tend to vary
between runs, and I suspect the difference between before and after is not
significant. (Meaning that your changes did not make performance worse. :-) )
Some platforms are more consistent than others, but for example on my Windows
laptop I see large differences between runs. What OS & hardware (cpu, #cores)
did you use?
I should update the performance test to print only throughput with standard
deviation and omit the (useless) latency numbers. The same test framework also
has a latency-only test mode but currently processing/pretty-printing those
results is not automated yet.
A final note on performance testing: I've started to look at
[JMH|http://openjdk.java.net/projects/code-tools/jmh/] for benchmarking log4j
performance. Looks promising.
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
> Attachments: LOG4J2-555-delegate.patch, log4j2-555-bbrouwer-2.patch,
> log4j2-555-bbrouwer.patch
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Reopened] (LOG4J2-323) ThreadLocal-leak on tomcat shutdown when using async logging
[
https://issues.apache.org/jira/browse/LOG4J2-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma reopened LOG4J2-323:
Assignee: (was: Nick Williams)
Re-opened for investigation.
> ThreadLocal-leak on tomcat shutdown when using async logging
>
>
> Key: LOG4J2-323
> URL: https://issues.apache.org/jira/browse/LOG4J2-323
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.0-beta9
> Environment: Mac OS X 10.8.4, Tomcat 7.0.42, java version 1.6.0_51
>Reporter: Michael Kloster
>Priority: Minor
> Fix For: 2.0-rc1
>
>
> When shutting down Tomcat 7.0.42, catalina.out displays the following warning
> indicating a memory leak:
> {code}
> Jul 28, 2013 9:55:59 AM org.apache.coyote.AbstractProtocol start
> INFO: Starting ProtocolHandler ["http-bio-8080"]
> Jul 28, 2013 9:55:59 AM org.apache.coyote.AbstractProtocol start
> INFO: Starting ProtocolHandler ["ajp-bio-8009"]
> Jul 28, 2013 9:55:59 AM org.apache.catalina.startup.Catalina start
> INFO: Server startup in 841 ms
> Jul 28, 2013 9:56:09 AM org.apache.catalina.core.StandardServer await
> INFO: A valid shutdown command was received via the shutdown port. Stopping
> the Server instance.
> Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol pause
> INFO: Pausing ProtocolHandler ["http-bio-8080"]
> Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol pause
> INFO: Pausing ProtocolHandler ["ajp-bio-8009"]
> Jul 28, 2013 9:56:09 AM org.apache.catalina.core.StandardService stopInternal
> INFO: Stopping service Catalina
> Jul 28, 2013 9:56:09 AM org.apache.catalina.loader.WebappClassLoader
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/asynclog] created a ThreadLocal with key of
> type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@648bfdea]) and a
> value of type [org.apache.logging.log4j.core.async.AsyncLogger.Info] (value
> [org.apache.logging.log4j.core.async.AsyncLogger$Info@4e26d560]) but failed
> to remove it when the web application was stopped. Threads are going to be
> renewed over time to try and avoid a probable memory leak.
> Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol stop
> INFO: Stopping ProtocolHandler ["http-bio-8080"]
> Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol stop
> INFO: Stopping ProtocolHandler ["ajp-bio-8009"]
> Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol destroy
> INFO: Destroying ProtocolHandler ["http-bio-8080"]
> Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol destroy
> INFO: Destroying ProtocolHandler ["ajp-bio-8009"]
> {code}
> {code:xml|title=log4j2.xml|borderStyle=solid}
>
>
>
>filePattern="logs/my-%d{COMPACT}.log">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> {code:title=log4j2.xml|borderStyle=solid}
> #!/bin/bash
> CATALINA_OPTS=-DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-571) AsyncLoggerConfig-1 Thread consuming excessive CPU
[
https://issues.apache.org/jira/browse/LOG4J2-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940200#comment-13940200
]
Remko Popma commented on LOG4J2-571:
Can you create another thread dump after setting system property
{{-DAsyncLoggerConfig.WaitStrategy=Block}}? If the configuration is successful
we should now see {{com/lmax/disruptor/BlockingWaitStrategy.waitFor}} in the
stack trace.
When you start the process, do you specify any other system properties?
Also, could you post the log4j2.xml configuration?
> AsyncLoggerConfig-1 Thread consuming excessive CPU
> --
>
> Key: LOG4J2-571
> URL: https://issues.apache.org/jira/browse/LOG4J2-571
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.0-rc1
> Environment: AIX 6.1
> oslevel -s: 6100-08-02-1316
> IBM WAS: 8.5.0.2
> IBM JRE/JDK:
> /opt/IBM/WebSphere/AppServer/java/bin/java -version
> java version "1.6.0"
> Java(TM) SE Runtime Environment (build pap6460_26sr5fp2-20130423_01(SR5 FP2))
> IBM J9 VM (build 2.6, JRE 1.6.0 AIX ppc64-64 Compressed References
> 20130419_145740 (JIT disabled, AOT disabled)
> J9VM - R26_Java626_SR5_FP2_20130419_1420_B145740
> GC - R26_Java626_SR5_FP2_20130419_1420_B145740_CMPRSS
> J9CL - 20130419_145740)
> JCL - 20130419_01
>Reporter: Chris Graham
>
> In this instance, I'm an indirect used of log4j2 2.0-rc1, as it's in the web
> app that I'm using, Apache Archiva 2.0.1.
> The issue is that when running under WebSphere 8.5.0.2 (obviously on the IBM
> JDK, 1.6) on AIX 6.1 TL8, Apache Archiva when it's doing nothing, is sitting
> idle on around 50% CPU.
> Using the native AIX perf/mon tools, I've traced the source of the issue
> through to this Java thread. This is the relevant section from the heap dump.
> 3XMTHREADINFO "AsyncLoggerConfig-1" J9VMThread:0x31D14600,
> j9thread_t:0x0100137D8BD0, java/lang/Thread:0x4301C508, state:CW,
> prio=5
> 3XMJAVALTHREAD(java/lang/Thread getId:0x6A, isDaemon:true)
> 3XMTHREADINFO1(native thread ID:0x2BF00F9, native priority:0x5,
> native policy:UNKNOWN)
> 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACEat sun/misc/Unsafe.park(Native Method)
> 4XESTACKTRACEat
> java/util/concurrent/locks/LockSupport.parkNanos(LockSupport.java:332)
> 4XESTACKTRACEat
> com/lmax/disruptor/SleepingWaitStrategy.applyWaitMethod(SleepingWaitStrategy.java:66)
> 4XESTACKTRACEat
> com/lmax/disruptor/SleepingWaitStrategy.waitFor(SleepingWaitStrategy.java:39)
> 4XESTACKTRACEat
> com/lmax/disruptor/ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:55)
> 4XESTACKTRACEat
> com/lmax/disruptor/BatchEventProcessor.run(BatchEventProcessor.java:115)
> 4XESTACKTRACEat
> java/util/concurrent/ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> 4XESTACKTRACEat
> java/util/concurrent/ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> 4XESTACKTRACEat java/lang/Thread.run(Thread.java:773)
> 3XMTHREADINFO3 Native callstack:
> 4XENATIVESTACK _event_wait+0x2b8 (0x097E7D3C
> [libpthreads.a+0x16d3c])
> 4XENATIVESTACK _cond_wait_local+0x4e4 (0x097F5A48
> [libpthreads.a+0x24a48])
> 4XENATIVESTACK _cond_wait+0xbc (0x097F6020
> [libpthreads.a+0x25020])
> 4XENATIVESTACK pthread_cond_wait+0x1a8 (0x097F6C8C
> [libpthreads.a+0x25c8c])
> 4XENATIVESTACK (0x090001223014 [libj9thr26.so+0x6014])
> 4XENATIVESTACK (0x090001222C60 [libj9thr26.so+0x5c60])
> 4XENATIVESTACK (0x09000116AE58 [libj9vm26.so+0xfe58])
> 4XENATIVESTACK (0x09000116B17C [libj9vm26.so+0x1017c])
> 4XENATIVESTACK (0x090001810528 [libjclscar_26.so+0x5c528])
> 4XENATIVESTACK (0x090001813B98 [libjclscar_26.so+0x5fb98])
> 4XENATIVESTACK (0x090001161764 [libj9vm26.so+0x6764])
> 4XENATIVESTACK (0x090001239CA0 [libj9prt26.so+0x2ca0])
> 4XENATIVESTACK (0x0900011615D4 [libj9vm26.so+0x65d4])
> 4XENATIVESTACK (0x09000121FAF4 [libj9thr26.so+0x2af4])
> 4XENATIVESTACK _pthread_body+0xf0 (0x097D4D34
> [libpthreads.a+0x3d34])
> NULL
> I have tried both -DAsyncLoggerConfig.WaitStrategy=Block, explicitly, and the
> default of Sleep (by removing the -D). I have not tried Yield.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.ap
[jira] [Commented] (LOG4J2-571) AsyncLoggerConfig-1 Thread consuming excessive CPU
[ https://issues.apache.org/jira/browse/LOG4J2-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940352#comment-13940352 ] Remko Popma commented on LOG4J2-571: I'm glad the problem is resolved. I also don't understand why Sleep would give this behaviour on AIX but not on other environments. (Out of interest: how many cores does your box have?) It looks like the Archive docs are wrong: they use a configuration that needs the -DAsyncLoggerConfig... options to configure, not the -DAsyncLogger... options. > AsyncLoggerConfig-1 Thread consuming excessive CPU > -- > > Key: LOG4J2-571 > URL: https://issues.apache.org/jira/browse/LOG4J2-571 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.0-rc1 > Environment: AIX 6.1 > oslevel -s: 6100-08-02-1316 > IBM WAS: 8.5.0.2 > IBM JRE/JDK: > /opt/IBM/WebSphere/AppServer/java/bin/java -version > java version "1.6.0" > Java(TM) SE Runtime Environment (build pap6460_26sr5fp2-20130423_01(SR5 FP2)) > IBM J9 VM (build 2.6, JRE 1.6.0 AIX ppc64-64 Compressed References > 20130419_145740 (JIT disabled, AOT disabled) > J9VM - R26_Java626_SR5_FP2_20130419_1420_B145740 > GC - R26_Java626_SR5_FP2_20130419_1420_B145740_CMPRSS > J9CL - 20130419_145740) > JCL - 20130419_01 >Reporter: Chris Graham > > In this instance, I'm an indirect used of log4j2 2.0-rc1, as it's in the web > app that I'm using, Apache Archiva 2.0.1. > The issue is that when running under WebSphere 8.5.0.2 (obviously on the IBM > JDK, 1.6) on AIX 6.1 TL8, Apache Archiva when it's doing nothing, is sitting > idle on around 50% CPU. > Using the native AIX perf/mon tools, I've traced the source of the issue > through to this Java thread. This is the relevant section from the heap dump. > 3XMTHREADINFO "AsyncLoggerConfig-1" J9VMThread:0x31D14600, > j9thread_t:0x0100137D8BD0, java/lang/Thread:0x4301C508, state:CW, > prio=5 > 3XMJAVALTHREAD(java/lang/Thread getId:0x6A, isDaemon:true) > 3XMTHREADINFO1(native thread ID:0x2BF00F9, native priority:0x5, > native policy:UNKNOWN) > 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) > 3XMTHREADINFO3 Java callstack: > 4XESTACKTRACEat sun/misc/Unsafe.park(Native Method) > 4XESTACKTRACEat > java/util/concurrent/locks/LockSupport.parkNanos(LockSupport.java:332) > 4XESTACKTRACEat > com/lmax/disruptor/SleepingWaitStrategy.applyWaitMethod(SleepingWaitStrategy.java:66) > 4XESTACKTRACEat > com/lmax/disruptor/SleepingWaitStrategy.waitFor(SleepingWaitStrategy.java:39) > 4XESTACKTRACEat > com/lmax/disruptor/ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:55) > 4XESTACKTRACEat > com/lmax/disruptor/BatchEventProcessor.run(BatchEventProcessor.java:115) > 4XESTACKTRACEat > java/util/concurrent/ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) > 4XESTACKTRACEat > java/util/concurrent/ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > 4XESTACKTRACEat java/lang/Thread.run(Thread.java:773) > 3XMTHREADINFO3 Native callstack: > 4XENATIVESTACK _event_wait+0x2b8 (0x097E7D3C > [libpthreads.a+0x16d3c]) > 4XENATIVESTACK _cond_wait_local+0x4e4 (0x097F5A48 > [libpthreads.a+0x24a48]) > 4XENATIVESTACK _cond_wait+0xbc (0x097F6020 > [libpthreads.a+0x25020]) > 4XENATIVESTACK pthread_cond_wait+0x1a8 (0x097F6C8C > [libpthreads.a+0x25c8c]) > 4XENATIVESTACK (0x090001223014 [libj9thr26.so+0x6014]) > 4XENATIVESTACK (0x090001222C60 [libj9thr26.so+0x5c60]) > 4XENATIVESTACK (0x09000116AE58 [libj9vm26.so+0xfe58]) > 4XENATIVESTACK (0x09000116B17C [libj9vm26.so+0x1017c]) > 4XENATIVESTACK (0x090001810528 [libjclscar_26.so+0x5c528]) > 4XENATIVESTACK (0x090001813B98 [libjclscar_26.so+0x5fb98]) > 4XENATIVESTACK (0x090001161764 [libj9vm26.so+0x6764]) > 4XENATIVESTACK (0x090001239CA0 [libj9prt26.so+0x2ca0]) > 4XENATIVESTACK (0x0900011615D4 [libj9vm26.so+0x65d4]) > 4XENATIVESTACK (0x09000121FAF4 [libj9thr26.so+0x2af4]) > 4XENATIVESTACK _pthread_body+0xf0 (0x097D4D34 > [libpthreads.a+0x3d34]) > NULL > I have tried both -DAsyncLoggerConfig.WaitStrategy=Block, explicitly, and the > default of Sleep (by removing the -D). I have not tried Yield. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org F
[jira] [Closed] (LOG4J2-571) AsyncLoggerConfig-1 Thread consuming excessive CPU
[ https://issues.apache.org/jira/browse/LOG4J2-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed LOG4J2-571. -- Resolution: Not A Problem Closing this issue. > AsyncLoggerConfig-1 Thread consuming excessive CPU > -- > > Key: LOG4J2-571 > URL: https://issues.apache.org/jira/browse/LOG4J2-571 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.0-rc1 > Environment: AIX 6.1 > oslevel -s: 6100-08-02-1316 > IBM WAS: 8.5.0.2 > IBM JRE/JDK: > /opt/IBM/WebSphere/AppServer/java/bin/java -version > java version "1.6.0" > Java(TM) SE Runtime Environment (build pap6460_26sr5fp2-20130423_01(SR5 FP2)) > IBM J9 VM (build 2.6, JRE 1.6.0 AIX ppc64-64 Compressed References > 20130419_145740 (JIT disabled, AOT disabled) > J9VM - R26_Java626_SR5_FP2_20130419_1420_B145740 > GC - R26_Java626_SR5_FP2_20130419_1420_B145740_CMPRSS > J9CL - 20130419_145740) > JCL - 20130419_01 >Reporter: Chris Graham > > In this instance, I'm an indirect used of log4j2 2.0-rc1, as it's in the web > app that I'm using, Apache Archiva 2.0.1. > The issue is that when running under WebSphere 8.5.0.2 (obviously on the IBM > JDK, 1.6) on AIX 6.1 TL8, Apache Archiva when it's doing nothing, is sitting > idle on around 50% CPU. > Using the native AIX perf/mon tools, I've traced the source of the issue > through to this Java thread. This is the relevant section from the heap dump. > 3XMTHREADINFO "AsyncLoggerConfig-1" J9VMThread:0x31D14600, > j9thread_t:0x0100137D8BD0, java/lang/Thread:0x4301C508, state:CW, > prio=5 > 3XMJAVALTHREAD(java/lang/Thread getId:0x6A, isDaemon:true) > 3XMTHREADINFO1(native thread ID:0x2BF00F9, native priority:0x5, > native policy:UNKNOWN) > 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) > 3XMTHREADINFO3 Java callstack: > 4XESTACKTRACEat sun/misc/Unsafe.park(Native Method) > 4XESTACKTRACEat > java/util/concurrent/locks/LockSupport.parkNanos(LockSupport.java:332) > 4XESTACKTRACEat > com/lmax/disruptor/SleepingWaitStrategy.applyWaitMethod(SleepingWaitStrategy.java:66) > 4XESTACKTRACEat > com/lmax/disruptor/SleepingWaitStrategy.waitFor(SleepingWaitStrategy.java:39) > 4XESTACKTRACEat > com/lmax/disruptor/ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:55) > 4XESTACKTRACEat > com/lmax/disruptor/BatchEventProcessor.run(BatchEventProcessor.java:115) > 4XESTACKTRACEat > java/util/concurrent/ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) > 4XESTACKTRACEat > java/util/concurrent/ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > 4XESTACKTRACEat java/lang/Thread.run(Thread.java:773) > 3XMTHREADINFO3 Native callstack: > 4XENATIVESTACK _event_wait+0x2b8 (0x097E7D3C > [libpthreads.a+0x16d3c]) > 4XENATIVESTACK _cond_wait_local+0x4e4 (0x097F5A48 > [libpthreads.a+0x24a48]) > 4XENATIVESTACK _cond_wait+0xbc (0x097F6020 > [libpthreads.a+0x25020]) > 4XENATIVESTACK pthread_cond_wait+0x1a8 (0x097F6C8C > [libpthreads.a+0x25c8c]) > 4XENATIVESTACK (0x090001223014 [libj9thr26.so+0x6014]) > 4XENATIVESTACK (0x090001222C60 [libj9thr26.so+0x5c60]) > 4XENATIVESTACK (0x09000116AE58 [libj9vm26.so+0xfe58]) > 4XENATIVESTACK (0x09000116B17C [libj9vm26.so+0x1017c]) > 4XENATIVESTACK (0x090001810528 [libjclscar_26.so+0x5c528]) > 4XENATIVESTACK (0x090001813B98 [libjclscar_26.so+0x5fb98]) > 4XENATIVESTACK (0x090001161764 [libj9vm26.so+0x6764]) > 4XENATIVESTACK (0x090001239CA0 [libj9prt26.so+0x2ca0]) > 4XENATIVESTACK (0x0900011615D4 [libj9vm26.so+0x65d4]) > 4XENATIVESTACK (0x09000121FAF4 [libj9thr26.so+0x2af4]) > 4XENATIVESTACK _pthread_body+0xf0 (0x097D4D34 > [libpthreads.a+0x3d34]) > NULL > I have tried both -DAsyncLoggerConfig.WaitStrategy=Block, explicitly, and the > default of Sleep (by removing the -D). I have not tried Yield. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13943949#comment-13943949
]
Remko Popma commented on LOG4J2-555:
I've started to review log4j-555-bbrouwer-2.patch. Still in progress, some
initial comments:
Advantages:
* simplified code, reduced duplication in AbstractLogger
* LoggerProvider interface removes need to cast to AbstractLogger when
extending/customizing Logger
* clearer distinction between "external" API {{log}} methods for users and
"internal" API {{logMessage}} method for extenders (but see below)
Drawbacks:
* in AbstractLogger the {{debug/trace/info/...(Object objMessage)}} methods now
call {{log(FQCN, Level.XXX, null, messageFactory.newMessage(message), null);}}
so a Message object may be created unnecessarily if {{isEnabled}} later returns
false
* the new (internal API) {{log}} methods introduced in the LoggerProvider
interface are confusingly similar to the external API {{log}} methods (same
method name, only the order of parameters is different). How about renaming
them to {{logIfEnabled}} or something else?
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
> Attachments: LOG4J2-555-delegate.patch, log4j2-555-bbrouwer-2.patch,
> log4j2-555-bbrouwer.patch
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
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-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13943949#comment-13943949
]
Remko Popma edited comment on LOG4J2-555 at 3/22/14 1:57 PM:
-
I've started to review log4j-555-bbrouwer-2.patch. Still in progress, some
initial comments:
Things I like:
* simplified code, reduced duplication in AbstractLogger
* LoggerProvider interface removes need to cast to AbstractLogger when
extending/customizing Logger
* clearer distinction between "external" API {{log}} methods for users and
"internal" API {{logMessage}} method for extenders (but see below)
TBD:
* -in AbstractLogger the {{debug/trace/info/...(Object objMessage)}} methods
now call {{log(FQCN, Level.XXX, null, messageFactory.newMessage(objMessage),
null);}} so a Message object may be created unnecessarily if {{isEnabled}}
later returns false.- EDIT: this looks like a mistake, not a design issue:
these methods can just call {{AbstractLogger.log(String, Level, Marker, Object,
Throwable)}} (line 1313 of patched AbstractLogger) without calling
messageFactory.newMessage(objMessage)
* the new (internal API) {{log}} methods introduced in the LoggerProvider
interface are confusingly similar to the external API {{log}} methods (same
method name, only the order of parameters is different). How about renaming
them to {{logIfEnabled}} or something else?
was (Author: rem...@yahoo.com):
I've started to review log4j-555-bbrouwer-2.patch. Still in progress, some
initial comments:
Advantages:
* simplified code, reduced duplication in AbstractLogger
* LoggerProvider interface removes need to cast to AbstractLogger when
extending/customizing Logger
* clearer distinction between "external" API {{log}} methods for users and
"internal" API {{logMessage}} method for extenders (but see below)
Drawbacks:
* in AbstractLogger the {{debug/trace/info/...(Object objMessage)}} methods now
call {{log(FQCN, Level.XXX, null, messageFactory.newMessage(message), null);}}
so a Message object may be created unnecessarily if {{isEnabled}} later returns
false
* the new (internal API) {{log}} methods introduced in the LoggerProvider
interface are confusingly similar to the external API {{log}} methods (same
method name, only the order of parameters is different). How about renaming
them to {{logIfEnabled}} or something else?
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
> Attachments: LOG4J2-555-delegate.patch, log4j2-555-bbrouwer-2.patch,
> log4j2-555-bbrouwer.patch
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
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-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13943949#comment-13943949
]
Remko Popma edited comment on LOG4J2-555 at 3/22/14 2:25 PM:
-
I've finished reviewing log4j-555-bbrouwer-2.patch.
Things I liked:
* simplified code, reduced duplication in AbstractLogger and
slf4j-impl.SLF4JLogger
* LoggerProvider interface removes need to cast to AbstractLogger when
extending/customizing Logger
* clearer distinction between "external" API {{log}} methods for users and
"internal" API {{logMessage}} method for extenders (but see below)
TBD:
* -in AbstractLogger the {{debug/trace/info/...(Object objMessage)}} methods
now call {{log(FQCN, Level.XXX, null, messageFactory.newMessage(objMessage),
null);}} so a Message object may be created unnecessarily if {{isEnabled}}
later returns false.- EDIT: this looks like a mistake, not a design issue:
these methods can just call {{AbstractLogger.log(String, Level, Marker, Object,
Throwable)}} (line 1313 of patched AbstractLogger) without calling
messageFactory.newMessage(objMessage)
* the new (internal API) {{log}} methods introduced in the LoggerProvider
interface are confusingly similar to the external API {{log}} methods (same
method name, only the order of parameters is different). How about renaming
them to {{logIfEnabled}} or something else?
was (Author: rem...@yahoo.com):
I've started to review log4j-555-bbrouwer-2.patch. Still in progress, some
initial comments:
Things I like:
* simplified code, reduced duplication in AbstractLogger
* LoggerProvider interface removes need to cast to AbstractLogger when
extending/customizing Logger
* clearer distinction between "external" API {{log}} methods for users and
"internal" API {{logMessage}} method for extenders (but see below)
TBD:
* -in AbstractLogger the {{debug/trace/info/...(Object objMessage)}} methods
now call {{log(FQCN, Level.XXX, null, messageFactory.newMessage(objMessage),
null);}} so a Message object may be created unnecessarily if {{isEnabled}}
later returns false.- EDIT: this looks like a mistake, not a design issue:
these methods can just call {{AbstractLogger.log(String, Level, Marker, Object,
Throwable)}} (line 1313 of patched AbstractLogger) without calling
messageFactory.newMessage(objMessage)
* the new (internal API) {{log}} methods introduced in the LoggerProvider
interface are confusingly similar to the external API {{log}} methods (same
method name, only the order of parameters is different). How about renaming
them to {{logIfEnabled}} or something else?
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
> Attachments: LOG4J2-555-delegate.patch, log4j2-555-bbrouwer-2.patch,
> log4j2-555-bbrouwer.patch, log4j2-555-gg-v3.diff
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional c
[jira] [Commented] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944095#comment-13944095
]
Remko Popma commented on LOG4J2-555:
Gary, looks like our messages crossed. :-) I agree with your solution to avoid
the potentially unnecessary call to {{messageFactory.newMessage}}.
Bruce, one more small thing I noticed: line 1160 of AbstractLogger in
log4j-555-bbrouwer-2.patch:
{code}
public void log(final Level level, final Marker marker, final Object message,
final Throwable t) {
if (isEnabled(level, marker, message, t)) {
logMessage(FQCN, level, marker, message, t);
}
}
{code}
Should this not be the below instead?
{code}
public void log(final Level level, final Marker marker, final Object message,
final Throwable t) {
log(FQCN, level, marker, message, t);
}
{code}
Finally, I strongly feel we should have a different name for the "internal API"
{{LoggerProvider.log}} methods (used by implementers/extenders) and the
"external API" {{Logger.log}} methods (used by users). I propose we rename the
LoggerProvider {{log}} methods to {{logIfEnabled}}. Other names would be fine
too, just not "log" :-)
If nobody objects I will rename the LoggerProvider {{log}} methods to
{{logIfEnabled}} and commit Bruce's "2" patch plus Gary's changes tomorrow (my
tomorrow, that is Saturday night US time).
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
> Attachments: LOG4J2-555-delegate.patch, log4j2-555-bbrouwer-2.patch,
> log4j2-555-bbrouwer.patch, log4j2-555-gg-v3.diff
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-547) Update LoggerStream API
[
https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944313#comment-13944313
]
Remko Popma commented on LOG4J2-547:
Interesting. This looks like a problem in the stack trace-walking logic to me:
it ignores the possibility that the FQCN appears multiple times and assumes the
first hit is the correct one. If the strack trace-walking logic were to read
_bottom-up_ it would correctly return
{{LoggerPrintStreamCallerInfoTest.print_chararray() line: 74}} as the location,
no?
> Update LoggerStream API
> ---
>
> Key: LOG4J2-547
> URL: https://issues.apache.org/jira/browse/LOG4J2-547
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Matt Sicker
>Assignee: Ralph Goers
> Fix For: 2.0
>
> Attachments: 0001-PrintStream-API-update.patch,
> log4j2-547-bbrouwer.patch, log4j2-loggerStream.patch
>
>
> I've got some ideas on how to improve the LoggerStream idea that I added a
> little while ago. The main thing I'd like to do is extract an interface from
> it, rename the default implementation to SimpleLoggerStream (part of the
> SimpleLogger stuff), and allow log4j implementations to specify a different
> implementation if desired.
> In doing this, I'm not sure where specifically I'd prefer the getStream
> methods to be. Right now, it's in Logger, but really, it could be in
> LoggerContext instead. I don't think I should be required to get a Logger
> just to get a LoggerStream.
> Now if only the java.io package used interfaces instead of classes. This
> would be so much easier to design!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-547) Update LoggerStream API
[
https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944333#comment-13944333
]
Remko Popma commented on LOG4J2-547:
FYI, this logic lives in
[Log4JLogEvent#calcLocation|http://logging.apache.org/log4j/2.x/log4j-core/xref/org/apache/logging/log4j/core/impl/Log4jLogEvent.html#311];
I think the expensive part of this method is the call to
{{Thread.currentThread().getStackTrace()}}, and looping over the resulting
array to do String comparisons is relatively cheap. So I suspect the
performance impact would be minimal. (On the other hand I have seen
Spring-based applications with ridiculously deep stack traces, and it does all
add up, so you could be right...)
About the corner case of LoggerPrintStream #1 (providing the FQCN) wrapping a
FilterOutputStream, wrapping another LoggerPrintStream #2 (also providing an
FQCN), wouldn't the stack trace look like the below, so only the bottom-up
approach would give correct results?
{code}
LoggerPrintStream.someMethod()
FilterOutputStream.someMethod()
LoggerPrintStream.someMethod()
ApplicationClass_TheCaller.theMethod() <-- the calling class we want to print
in location info
{code}
> Update LoggerStream API
> ---
>
> Key: LOG4J2-547
> URL: https://issues.apache.org/jira/browse/LOG4J2-547
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Matt Sicker
>Assignee: Ralph Goers
> Fix For: 2.0
>
> Attachments: 0001-PrintStream-API-update.patch,
> log4j2-547-bbrouwer.patch, log4j2-loggerStream.patch
>
>
> I've got some ideas on how to improve the LoggerStream idea that I added a
> little while ago. The main thing I'd like to do is extract an interface from
> it, rename the default implementation to SimpleLoggerStream (part of the
> SimpleLogger stuff), and allow log4j implementations to specify a different
> implementation if desired.
> In doing this, I'm not sure where specifically I'd prefer the getStream
> methods to be. Right now, it's in Logger, but really, it could be in
> LoggerContext instead. I don't think I should be required to get a Logger
> just to get a LoggerStream.
> Now if only the java.io package used interfaces instead of classes. This
> would be so much easier to design!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved LOG4J2-555.
Resolution: Fixed
Fixed in revision 1580445, based on log4j2-555-bbrouwer-2.patch with Gary's
changes.
I also modified log4j-1.2-api Category:
{{forcedLog}} (line 337) now calls {{logger.logMessage}} instead of
logger.logIfEnabled.
{{maybeLog}} (line 431) now calls {{logger.logMessage}} instead of
logger.logIfEnabled.
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
> Attachments: LOG4J2-555-delegate.patch, log4j2-555-bbrouwer-2.patch,
> log4j2-555-bbrouwer.patch, log4j2-555-gg-v3.diff
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
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-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944339#comment-13944339
]
Remko Popma edited comment on LOG4J2-555 at 3/23/14 5:14 AM:
-
Fixed in revision 1580445, based on log4j2-555-bbrouwer-2.patch with Gary's
changes.
I also modified log4j-1.2-api Category (slightly different from the patch):
{{forcedLog}} (line 337) now calls {{logger.logMessage}} instead of
logger.logIfEnabled.
{{maybeLog}} (line 431) now calls {{logger.logMessage}} instead of
logger.logIfEnabled.
was (Author: rem...@yahoo.com):
Fixed in revision 1580445, based on log4j2-555-bbrouwer-2.patch with Gary's
changes.
I also modified log4j-1.2-api Category:
{{forcedLog}} (line 337) now calls {{logger.logMessage}} instead of
logger.logIfEnabled.
{{maybeLog}} (line 431) now calls {{logger.logMessage}} instead of
logger.logIfEnabled.
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
> Attachments: LOG4J2-555-delegate.patch, log4j2-555-bbrouwer-2.patch,
> log4j2-555-bbrouwer.patch, log4j2-555-gg-v3.diff
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-574) Make Blocking the default WaitStrategy for Async Loggers
Remko Popma created LOG4J2-574: -- Summary: Make Blocking the default WaitStrategy for Async Loggers Key: LOG4J2-574 URL: https://issues.apache.org/jira/browse/LOG4J2-574 Project: Log4j 2 Issue Type: Improvement Components: Appenders Affects Versions: 2.0-rc1 Reporter: Remko Popma Assignee: Remko Popma Fix For: 2.0-rc2 With Asynchronous Loggers, the wait strategy determines what the consumer thread does when the queue is empty and it is waiting for events. The LMAX Disruptor offers several options, as some specialized apps want to avoid the latency of waking up a blocked thread. These options have different trade-offs, with busy spin on one end of the spectrum and blocking on the other. In log4j we only expose a limited set of these options (no busy spin), and originally chose SleepingWait as the default as it seemed to have the best performance in testing. It turned out that in some environments the current default of SleepingWaitStrategy may result in excessive CPU usage (LOG4J2-571). To avoid such problems this ticket proposes to change the default wait strategy for Async Loggers to BlockingWaitStrategy. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-574) Make Blocking the default WaitStrategy for Async Loggers
[ https://issues.apache.org/jira/browse/LOG4J2-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma resolved LOG4J2-574. Resolution: Fixed Fixed in revision 1580474. > Make Blocking the default WaitStrategy for Async Loggers > > > Key: LOG4J2-574 > URL: https://issues.apache.org/jira/browse/LOG4J2-574 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.0-rc1 >Reporter: Remko Popma >Assignee: Remko Popma > Fix For: 2.0-rc2 > > > With Asynchronous Loggers, the wait strategy determines what the consumer > thread does when the queue is empty and it is waiting for events. The LMAX > Disruptor offers several options, as some specialized apps want to avoid the > latency of waking up a blocked thread. These options have different > trade-offs, with busy spin on one end of the spectrum and blocking on the > other. > In log4j we only expose a limited set of these options (no busy spin), and > originally chose SleepingWait as the default as it seemed to have the best > performance in testing. > It turned out that in some environments the current default of > SleepingWaitStrategy may result in excessive CPU usage (LOG4J2-571). To avoid > such problems this ticket proposes to change the default wait strategy for > Async Loggers to BlockingWaitStrategy. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-574) Make Blocking the default WaitStrategy for Async Loggers
[ https://issues.apache.org/jira/browse/LOG4J2-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed LOG4J2-574. -- > Make Blocking the default WaitStrategy for Async Loggers > > > Key: LOG4J2-574 > URL: https://issues.apache.org/jira/browse/LOG4J2-574 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.0-rc1 >Reporter: Remko Popma >Assignee: Remko Popma > Fix For: 2.0-rc2 > > > With Asynchronous Loggers, the wait strategy determines what the consumer > thread does when the queue is empty and it is waiting for events. The LMAX > Disruptor offers several options, as some specialized apps want to avoid the > latency of waking up a blocked thread. These options have different > trade-offs, with busy spin on one end of the spectrum and blocking on the > other. > In log4j we only expose a limited set of these options (no busy spin), and > originally chose SleepingWait as the default as it seemed to have the best > performance in testing. > It turned out that in some environments the current default of > SleepingWaitStrategy may result in excessive CPU usage (LOG4J2-571). To avoid > such problems this ticket proposes to change the default wait strategy for > Async Loggers to BlockingWaitStrategy. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-571) AsyncLoggerConfig-1 Thread consuming excessive CPU
[ https://issues.apache.org/jira/browse/LOG4J2-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944383#comment-13944383 ] Remko Popma commented on LOG4J2-571: Raised LOG4J2-574 for the new default. This is fixed in trunk. > AsyncLoggerConfig-1 Thread consuming excessive CPU > -- > > Key: LOG4J2-571 > URL: https://issues.apache.org/jira/browse/LOG4J2-571 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.0-rc1 > Environment: AIX 6.1 > oslevel -s: 6100-08-02-1316 > IBM WAS: 8.5.0.2 > IBM JRE/JDK: > /opt/IBM/WebSphere/AppServer/java/bin/java -version > java version "1.6.0" > Java(TM) SE Runtime Environment (build pap6460_26sr5fp2-20130423_01(SR5 FP2)) > IBM J9 VM (build 2.6, JRE 1.6.0 AIX ppc64-64 Compressed References > 20130419_145740 (JIT disabled, AOT disabled) > J9VM - R26_Java626_SR5_FP2_20130419_1420_B145740 > GC - R26_Java626_SR5_FP2_20130419_1420_B145740_CMPRSS > J9CL - 20130419_145740) > JCL - 20130419_01 >Reporter: Chris Graham > > In this instance, I'm an indirect used of log4j2 2.0-rc1, as it's in the web > app that I'm using, Apache Archiva 2.0.1. > The issue is that when running under WebSphere 8.5.0.2 (obviously on the IBM > JDK, 1.6) on AIX 6.1 TL8, Apache Archiva when it's doing nothing, is sitting > idle on around 50% CPU. > Using the native AIX perf/mon tools, I've traced the source of the issue > through to this Java thread. This is the relevant section from the heap dump. > 3XMTHREADINFO "AsyncLoggerConfig-1" J9VMThread:0x31D14600, > j9thread_t:0x0100137D8BD0, java/lang/Thread:0x4301C508, state:CW, > prio=5 > 3XMJAVALTHREAD(java/lang/Thread getId:0x6A, isDaemon:true) > 3XMTHREADINFO1(native thread ID:0x2BF00F9, native priority:0x5, > native policy:UNKNOWN) > 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) > 3XMTHREADINFO3 Java callstack: > 4XESTACKTRACEat sun/misc/Unsafe.park(Native Method) > 4XESTACKTRACEat > java/util/concurrent/locks/LockSupport.parkNanos(LockSupport.java:332) > 4XESTACKTRACEat > com/lmax/disruptor/SleepingWaitStrategy.applyWaitMethod(SleepingWaitStrategy.java:66) > 4XESTACKTRACEat > com/lmax/disruptor/SleepingWaitStrategy.waitFor(SleepingWaitStrategy.java:39) > 4XESTACKTRACEat > com/lmax/disruptor/ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:55) > 4XESTACKTRACEat > com/lmax/disruptor/BatchEventProcessor.run(BatchEventProcessor.java:115) > 4XESTACKTRACEat > java/util/concurrent/ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) > 4XESTACKTRACEat > java/util/concurrent/ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > 4XESTACKTRACEat java/lang/Thread.run(Thread.java:773) > 3XMTHREADINFO3 Native callstack: > 4XENATIVESTACK _event_wait+0x2b8 (0x097E7D3C > [libpthreads.a+0x16d3c]) > 4XENATIVESTACK _cond_wait_local+0x4e4 (0x097F5A48 > [libpthreads.a+0x24a48]) > 4XENATIVESTACK _cond_wait+0xbc (0x097F6020 > [libpthreads.a+0x25020]) > 4XENATIVESTACK pthread_cond_wait+0x1a8 (0x097F6C8C > [libpthreads.a+0x25c8c]) > 4XENATIVESTACK (0x090001223014 [libj9thr26.so+0x6014]) > 4XENATIVESTACK (0x090001222C60 [libj9thr26.so+0x5c60]) > 4XENATIVESTACK (0x09000116AE58 [libj9vm26.so+0xfe58]) > 4XENATIVESTACK (0x09000116B17C [libj9vm26.so+0x1017c]) > 4XENATIVESTACK (0x090001810528 [libjclscar_26.so+0x5c528]) > 4XENATIVESTACK (0x090001813B98 [libjclscar_26.so+0x5fb98]) > 4XENATIVESTACK (0x090001161764 [libj9vm26.so+0x6764]) > 4XENATIVESTACK (0x090001239CA0 [libj9prt26.so+0x2ca0]) > 4XENATIVESTACK (0x0900011615D4 [libj9vm26.so+0x65d4]) > 4XENATIVESTACK (0x09000121FAF4 [libj9thr26.so+0x2af4]) > 4XENATIVESTACK _pthread_body+0xf0 (0x097D4D34 > [libpthreads.a+0x3d34]) > NULL > I have tried both -DAsyncLoggerConfig.WaitStrategy=Block, explicitly, and the > default of Sleep (by removing the -D). I have not tried Yield. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-537) application does not end.
[
https://issues.apache.org/jira/browse/LOG4J2-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944394#comment-13944394
]
Remko Popma commented on LOG4J2-537:
Gleb,
Sorry for the late response.
You seem to be using the Disruptor extensively in your application. When you
pass an Executor to your Disruptor instances, do you use a custom ThreadFactory
to ensure all threads are daemon threads? This is what we do in log4j2.
Is it possible that your application has other non-daemon threads still running
when the application ends? That would explain why the application does not end.
Moonumi:
In a standalone application (run from the command line) I cannot reproduce the
problem with the sample application you provided.
But, interestingly, I can reproduce the problem when running from Eclipse. In
Eclipse the application always hangs, whether I use Async loggers or not...
{code}
public static void main(String[] args) {
// uncomment below line to use Async Loggers
// System.setProperty("Log4jContextSelector",
"org.apache.logging.log4j.core.async.AsyncLoggerContextSelector");
Logger logger = LogManager.getLogger();
logger.info("Hello, World!");
}
{code}
> application does not end.
> -
>
> Key: LOG4J2-537
> URL: https://issues.apache.org/jira/browse/LOG4J2-537
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-beta9
> Environment: jdk1.6.0_45 64bit
>Reporter: moonumi
>Assignee: Remko Popma
> Labels: patch
>
> The helloworld program below does not end. (Process keeps running.)
> configuration:
> {code}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> source
> {code}
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class HelloWorld {
> private static Logger logger = LogManager.getLogger();
> public static void main(String[] args) {
> logger.info("Hello, World!");
> }
> }
> {code}
> libs:
> disruptor-3.2.0.jar
> log4j-api-beta9.jar
> log4j-core-beta9.jar
> delete file appender and change [AppenderRef ref="Console"] in [Root] work
> fine.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-570) Memory Leak
[ https://issues.apache.org/jira/browse/LOG4J2-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944601#comment-13944601 ] Remko Popma commented on LOG4J2-570: I haven't looked at the code, but would it be possible to detect if we're running in a web container before adding the shutdown hook and registering or not registering depending on that? > Memory Leak > --- > > Key: LOG4J2-570 > URL: https://issues.apache.org/jira/browse/LOG4J2-570 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.0-rc1 > Environment: Ubuntu 12.04 > Linux bos-lpuv7 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013 > x86_64 x86_64 x86_64 GNU/Linux > 8 GB RAM > java version "1.7.0_51" > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) > JAVA_OPTS=-Xmx1024m -Dsun.net.inetaddr.ttl=60 > -Dsun.net.inetaddr.negative.ttl=60 -Djava.net.preferIPv4Stack=true > -XX:PermSize=128m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC > -XX:+CMSClassUnloadingEnabled > 2.0-rc1 > log4j-api > log4j-core > log4j-jcl > Spring webmvc 4.0.2.RELEASE application (simple hello world) deployed in > tomcat7.0.52 container. >Reporter: Scott >Assignee: Matt Sicker >Priority: Blocker > Fix For: 2.0-rc2 > > Attachments: spring_log4j2_memory_leak.tbz2 > > > Dynamically loading a JAR that uses log4j2 results in a memory leak when the > JAR is unloaded. This can be observed by deploying a web application to > tomcat7 and exercising the stop, undeploy, or redeploy actions. The memory > leak is believed to be caused by log4j for the following reasons: > 1)Heap Dump reveals the classloader instance responsible for the WAR plugin > (of type org.apache.catalina.loader.WebappClassLoader) has 2 non weak/soft > reference which are of type > (org.apache.logging.log4j.core.LoggerContext$ShutdownThread) and > (org.apache.logging.log4j.core.jmx.LoggerContextAdmin) after the WAR has been > stopped or undeployed. > 2)Using SLF4J (slf4j-api, jcl-over-slf4j) to logback-classic logging output > is equivalent but all memory is gc as expected (the > org.apache.catalina.loader.WebappClassLoader which loaded the WAR is no > longer referenced by any hard references) > 3)Using the SLF4J NOP logger implementation all memory is gc as expected (the > org.apache.catalina.loader.WebappClassLoader which loaded the WAR is no > longer referenced by any hard references) > This may not be unique to 2.0rc-1 and I have seen similar behavior in > previous 2.0 beta releases. > This is reproducible with a very simple spring hello world application. Code > and/or heap dumps can be provided upon request. -- This message was sent by Atlassian JIRA (v6.2#6252) - 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-570) Memory Leak
[ https://issues.apache.org/jira/browse/LOG4J2-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944601#comment-13944601 ] Remko Popma edited comment on LOG4J2-570 at 3/23/14 10:06 PM: -- I haven't looked at the code, but would it be possible to detect if we're running in a web container before adding the shutdown hook and registering or not registering depending on that? I mean, if it is hard to do this cleanly, but it is important to do it, then we could use something ugly like setting a global flag in the web initialization logic... was (Author: rem...@yahoo.com): I haven't looked at the code, but would it be possible to detect if we're running in a web container before adding the shutdown hook and registering or not registering depending on that? > Memory Leak > --- > > Key: LOG4J2-570 > URL: https://issues.apache.org/jira/browse/LOG4J2-570 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.0-rc1 > Environment: Ubuntu 12.04 > Linux bos-lpuv7 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013 > x86_64 x86_64 x86_64 GNU/Linux > 8 GB RAM > java version "1.7.0_51" > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) > JAVA_OPTS=-Xmx1024m -Dsun.net.inetaddr.ttl=60 > -Dsun.net.inetaddr.negative.ttl=60 -Djava.net.preferIPv4Stack=true > -XX:PermSize=128m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC > -XX:+CMSClassUnloadingEnabled > 2.0-rc1 > log4j-api > log4j-core > log4j-jcl > Spring webmvc 4.0.2.RELEASE application (simple hello world) deployed in > tomcat7.0.52 container. >Reporter: Scott >Assignee: Matt Sicker >Priority: Blocker > Fix For: 2.0-rc2 > > Attachments: spring_log4j2_memory_leak.tbz2 > > > Dynamically loading a JAR that uses log4j2 results in a memory leak when the > JAR is unloaded. This can be observed by deploying a web application to > tomcat7 and exercising the stop, undeploy, or redeploy actions. The memory > leak is believed to be caused by log4j for the following reasons: > 1)Heap Dump reveals the classloader instance responsible for the WAR plugin > (of type org.apache.catalina.loader.WebappClassLoader) has 2 non weak/soft > reference which are of type > (org.apache.logging.log4j.core.LoggerContext$ShutdownThread) and > (org.apache.logging.log4j.core.jmx.LoggerContextAdmin) after the WAR has been > stopped or undeployed. > 2)Using SLF4J (slf4j-api, jcl-over-slf4j) to logback-classic logging output > is equivalent but all memory is gc as expected (the > org.apache.catalina.loader.WebappClassLoader which loaded the WAR is no > longer referenced by any hard references) > 3)Using the SLF4J NOP logger implementation all memory is gc as expected (the > org.apache.catalina.loader.WebappClassLoader which loaded the WAR is no > longer referenced by any hard references) > This may not be unique to 2.0rc-1 and I have seen similar behavior in > previous 2.0 beta releases. > This is reproducible with a very simple spring hello world application. Code > and/or heap dumps can be provided upon request. -- This message was sent by Atlassian JIRA (v6.2#6252) - 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-575) Log4J2 and Tomee Plus 7.0.47 not working
[
https://issues.apache.org/jira/browse/LOG4J2-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944652#comment-13944652
]
Remko Popma edited comment on LOG4J2-575 at 3/24/14 12:03 AM:
--
Alex, in your [stackoverflow
comments|http://stackoverflow.com/questions/22584530/log4j2-and-tomee-plus-7-0-47-not-working]
you mentioned that the problem only exists if the jars are in the Tomcat lib
folder, but the problem goes away if you put the jars inside WEB-INF/lib. Or
did I misunderstand that?
was (Author: rem...@yahoo.com):
Alex, in your stackoverflow comments you mentioned that the problem only exists
if the jars are in the Tomcat lib folder, but the problem goes away if you put
the jars inside WEB-INF/lib. Or did I misunderstand that?
> Log4J2 and Tomee Plus 7.0.47 not working
>
>
> Key: LOG4J2-575
> URL: https://issues.apache.org/jira/browse/LOG4J2-575
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-rc1
>Reporter: Alex Gout
> Labels: Log4j2, Logger, TomEE
>
> According to http://logging.apache.org/log4j/2.x/manual/webapp.html, Log4j2
> should work with Tomcat7.0.47. I'm using TomEE Plus 7.0.47.
> I have a webapplication deployed with a log4j2.xml in my web-inf/classes
> folder. This is the config:
> {code:xml}
>
>
>
>
>
>
>
>
> %d %p %C{1.} [%t] %m%n
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I have a logger declared in a class with name org.alex.util.JSON:
> private static final Logger LOG = LoggerFactory.getLogger(JSON.class);
> I'm using slf4j-api 1.7.5, and have the following libs added to the tomcat
> lib:
> slf4j-api-1.7.5.jar
> log4j-api-2.0-rc1.jar
> log4j-core-2.0-rc1.jar
> log4j-slf4j-impl-2.0-rc1.jar
> If I change the Configuration status to TRACE, I can see my configuration
> file being picked up and configuration happens as expected. Also I can see
> the MBeans being added.
> However, there's not one logging statement ending up in my logfile (although
> the file is created). I debugged into the log4j2 Logger, and see that the
> isEnabled(...) method return false because the logger (com.alex.util.JSON)
> has the level "ERROR" set, while the configuration set the package org.alex
> to TRACE.
> Further investigation shows it uses a DefaultConfiguration configured for
> level=ERROR, and only root is configured.
> Furthermore I noticed that the classloader for the instance of my logger that
> is created at configuration is org.apache.openejb.core.TempClassLoader, while
> the classloader of the Logger that is invoked is
> org.apache.catalina.loader.StandardClassLoader. I don't know enough of the
> whole mechanism to judge whether or not this is to be expected
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-575) Log4J2 and Tomee Plus 7.0.47 not working
[
https://issues.apache.org/jira/browse/LOG4J2-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944652#comment-13944652
]
Remko Popma commented on LOG4J2-575:
Alex, in your stackoverflow comments you mentioned that the problem only exists
if the jars are in the Tomcat lib folder, but the problem goes away if you put
the jars inside WEB-INF/lib. Or did I misunderstand that?
> Log4J2 and Tomee Plus 7.0.47 not working
>
>
> Key: LOG4J2-575
> URL: https://issues.apache.org/jira/browse/LOG4J2-575
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-rc1
>Reporter: Alex Gout
> Labels: Log4j2, Logger, TomEE
>
> According to http://logging.apache.org/log4j/2.x/manual/webapp.html, Log4j2
> should work with Tomcat7.0.47. I'm using TomEE Plus 7.0.47.
> I have a webapplication deployed with a log4j2.xml in my web-inf/classes
> folder. This is the config:
> {code:xml}
>
>
>
>
>
>
>
>
> %d %p %C{1.} [%t] %m%n
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I have a logger declared in a class with name org.alex.util.JSON:
> private static final Logger LOG = LoggerFactory.getLogger(JSON.class);
> I'm using slf4j-api 1.7.5, and have the following libs added to the tomcat
> lib:
> slf4j-api-1.7.5.jar
> log4j-api-2.0-rc1.jar
> log4j-core-2.0-rc1.jar
> log4j-slf4j-impl-2.0-rc1.jar
> If I change the Configuration status to TRACE, I can see my configuration
> file being picked up and configuration happens as expected. Also I can see
> the MBeans being added.
> However, there's not one logging statement ending up in my logfile (although
> the file is created). I debugged into the log4j2 Logger, and see that the
> isEnabled(...) method return false because the logger (com.alex.util.JSON)
> has the level "ERROR" set, while the configuration set the package org.alex
> to TRACE.
> Further investigation shows it uses a DefaultConfiguration configured for
> level=ERROR, and only root is configured.
> Furthermore I noticed that the classloader for the instance of my logger that
> is created at configuration is org.apache.openejb.core.TempClassLoader, while
> the classloader of the Logger that is invoked is
> org.apache.catalina.loader.StandardClassLoader. I don't know enough of the
> whole mechanism to judge whether or not this is to be expected
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-575) Log4J2 and Tomee Plus 7.0.47 not working
[
https://issues.apache.org/jira/browse/LOG4J2-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944660#comment-13944660
]
Remko Popma commented on LOG4J2-575:
Sorry, now I'm lost. This is my understanding, please correct me if I'm wrong:
*Scenario 1:* log4j2 jar files all inside the WAR under WEB-INF/lib (not in
tomcat shared lib folder)
Result: logging works correctly. We don't know which classloader is used.
*Scenario 2:* log4j2 jar files under tomcat shared lib folder (not in
WEB-INF/lib)
Result: Configuration finds log4j2.xml, initializes with this config using
{{org.apache.openejb.core.TempClassLoader}}, but then these loaded classes are
not visible to the web application (which uses the
{{org.apache.catalina.loader.StandardClassLoader}} class loader), and as a
result the application ends up with the DefaultConfiguration (level=ERROR).
> Log4J2 and Tomee Plus 7.0.47 not working
>
>
> Key: LOG4J2-575
> URL: https://issues.apache.org/jira/browse/LOG4J2-575
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-rc1
>Reporter: Alex Gout
> Labels: Log4j2, Logger, TomEE
>
> According to http://logging.apache.org/log4j/2.x/manual/webapp.html, Log4j2
> should work with Tomcat7.0.47. I'm using TomEE Plus 7.0.47.
> I have a webapplication deployed with a log4j2.xml in my web-inf/classes
> folder. This is the config:
> {code:xml}
>
>
>
>
>
>
>
>
> %d %p %C{1.} [%t] %m%n
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I have a logger declared in a class with name org.alex.util.JSON:
> private static final Logger LOG = LoggerFactory.getLogger(JSON.class);
> I'm using slf4j-api 1.7.5, and have the following libs added to the tomcat
> lib:
> slf4j-api-1.7.5.jar
> log4j-api-2.0-rc1.jar
> log4j-core-2.0-rc1.jar
> log4j-slf4j-impl-2.0-rc1.jar
> If I change the Configuration status to TRACE, I can see my configuration
> file being picked up and configuration happens as expected. Also I can see
> the MBeans being added.
> However, there's not one logging statement ending up in my logfile (although
> the file is created). I debugged into the log4j2 Logger, and see that the
> isEnabled(...) method return false because the logger (com.alex.util.JSON)
> has the level "ERROR" set, while the configuration set the package org.alex
> to TRACE.
> Further investigation shows it uses a DefaultConfiguration configured for
> level=ERROR, and only root is configured.
> Furthermore I noticed that the classloader for the instance of my logger that
> is created at configuration is org.apache.openejb.core.TempClassLoader, while
> the classloader of the Logger that is invoked is
> org.apache.catalina.loader.StandardClassLoader. I don't know enough of the
> whole mechanism to judge whether or not this is to be expected
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-547) Update LoggerStream API
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944679#comment-13944679 ] Remko Popma commented on LOG4J2-547: Micro-benchmarks can be tricky stuff. Do you get the same results if you first measure bottom-up, then top-down? Or start with recurse(500), and work down to recurse(100)? Things that make it tricky: * avoid measuring during the first 3-10 seconds after the JVM started, as JVM initialization is still taking place in parallel * Hotspot will compile "hot" code to native code. The default threshold is after 10,000 invocations. So in the example this will happen sometime while you are measuring. * During compilation, hotspot will look at places to optimize. The loop can be unrolled, and statements in the loop re-ordered. If hotspot determines the code has no side-effects (doesn't change any state) and doesn't return a value, it may decide to optimize by simply not executing that code... Same results, but a lot faster. :-) If you have time, please take a look at [JMH|http://openjdk.java.net/projects/code-tools/jmh/]. JHM is specifically designed to avoid these and other pitfalls. > Update LoggerStream API > --- > > Key: LOG4J2-547 > URL: https://issues.apache.org/jira/browse/LOG4J2-547 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker >Assignee: Ralph Goers > Fix For: 2.0-rc2 > > Attachments: 0001-PrintStream-API-update.patch, > PerfTestCalcLocation.java, log4j2-547-bbrouwer.patch, > log4j2-loggerStream.patch > > > I've got some ideas on how to improve the LoggerStream idea that I added a > little while ago. The main thing I'd like to do is extract an interface from > it, rename the default implementation to SimpleLoggerStream (part of the > SimpleLogger stuff), and allow log4j implementations to specify a different > implementation if desired. > In doing this, I'm not sure where specifically I'd prefer the getStream > methods to be. Right now, it's in Logger, but really, it could be in > LoggerContext instead. I don't think I should be required to get a Logger > just to get a LoggerStream. > Now if only the java.io package used interfaces instead of classes. This > would be so much easier to design! -- This message was sent by Atlassian JIRA (v6.2#6252) - 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-576) Add org.apache.logging.log4j.Logger.getLevel()
[
https://issues.apache.org/jira/browse/LOG4J2-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944718#comment-13944718
]
Remko Popma edited comment on LOG4J2-576 at 3/24/14 3:43 AM:
-
+1 Looks like a useful feature to me, especially if it helps with 1.2 -> 2
migration.
It might invite requests for a {{setLevel}} method, but that is a different
topic. :-)
was (Author: rem...@yahoo.com):
Looks like a useful feature to me, especially if it helps with 1.2 -> 2
migration.
It might invite requests for a {{setLevel}} method, but that is a different
topic.
> Add org.apache.logging.log4j.Logger.getLevel()
> --
>
> Key: LOG4J2-576
> URL: https://issues.apache.org/jira/browse/LOG4J2-576
> Project: Log4j 2
> Issue Type: Bug
> Components: API, SLF4J Bridge
>Affects Versions: 2.0-rc1
> Environment: Apache Maven 3.0.5
> (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 08:51:28-0500)
> Maven home: C:\Java\apache-maven-3.0.5\bin\..
> Java version: 1.7.0_51, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_51\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
> Attachments: log4j2-576-ggregory.diff
>
>
> Add org.apache.logging.log4j.Logger.getLevel().
> This will make is easier to port from 1.2.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-576) Add org.apache.logging.log4j.Logger.getLevel()
[
https://issues.apache.org/jira/browse/LOG4J2-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944718#comment-13944718
]
Remko Popma commented on LOG4J2-576:
Looks like a useful feature to me, especially if it helps with 1.2 -> 2
migration.
It might invite requests for a {{setLevel}} method, but that is a different
topic.
> Add org.apache.logging.log4j.Logger.getLevel()
> --
>
> Key: LOG4J2-576
> URL: https://issues.apache.org/jira/browse/LOG4J2-576
> Project: Log4j 2
> Issue Type: Bug
> Components: API, SLF4J Bridge
>Affects Versions: 2.0-rc1
> Environment: Apache Maven 3.0.5
> (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 08:51:28-0500)
> Maven home: C:\Java\apache-maven-3.0.5\bin\..
> Java version: 1.7.0_51, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_51\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
> Attachments: log4j2-576-ggregory.diff
>
>
> Add org.apache.logging.log4j.Logger.getLevel().
> This will make is easier to port from 1.2.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-570) Memory Leak
[ https://issues.apache.org/jira/browse/LOG4J2-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946143#comment-13946143 ] Remko Popma commented on LOG4J2-570: If I understand the above correctly, the shutdown hook is registered before log4j becomes aware that it is running in a web container. If that is the case, how about creating a new a method that _unregisters_ the shutdown hook, and call this method as soon as log4j knows it is running in a web container? > Memory Leak > --- > > Key: LOG4J2-570 > URL: https://issues.apache.org/jira/browse/LOG4J2-570 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.0-rc1 > Environment: Ubuntu 12.04 > Linux 3.2.0-58-generic x86_64 GNU/Linux > 8 GB RAM > java version "1.7.0_51" > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) > JAVA_OPTS=-Xmx1024m -Dsun.net.inetaddr.ttl=60 > -Dsun.net.inetaddr.negative.ttl=60 -Djava.net.preferIPv4Stack=true > -XX:PermSize=128m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC > -XX:+CMSClassUnloadingEnabled > 2.0-rc1 > log4j-api > log4j-core > log4j-jcl > Spring webmvc 4.0.2.RELEASE application (simple hello world) deployed in > tomcat7.0.52 container. >Reporter: Scott >Assignee: Matt Sicker >Priority: Blocker > Labels: memory_leak > Fix For: 2.0-rc2 > > Attachments: spring_log4j2_memory_leak.tbz2 > > > Dynamically loading a JAR that uses log4j2 results in a memory leak when the > JAR is unloaded. This can be observed by deploying a web application to > tomcat7 and exercising the stop, undeploy, or redeploy actions. The memory > leak is believed to be caused by log4j for the following reasons: > 1)Heap Dump reveals the classloader instance responsible for the WAR plugin > (of type org.apache.catalina.loader.WebappClassLoader) has 2 non weak/soft > reference which are of type > (org.apache.logging.log4j.core.LoggerContext$ShutdownThread) and > (org.apache.logging.log4j.core.jmx.LoggerContextAdmin) after the WAR has been > stopped or undeployed. > 2)Using SLF4J (slf4j-api, jcl-over-slf4j) to logback-classic logging output > is equivalent but all memory is gc as expected (the > org.apache.catalina.loader.WebappClassLoader which loaded the WAR is no > longer referenced by any hard references) > 3)Using the SLF4J NOP logger implementation all memory is gc as expected (the > org.apache.catalina.loader.WebappClassLoader which loaded the WAR is no > longer referenced by any hard references) > This may not be unique to 2.0rc-1 and I have seen similar behavior in > previous 2.0 beta releases. > This is reproducible with a very simple spring hello world application. Code > and/or heap dumps can be provided upon request. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-581) No header output in RollingRandomAccessFile
[
https://issues.apache.org/jira/browse/LOG4J2-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13948642#comment-13948642
]
Remko Popma commented on LOG4J2-581:
I can take a look, but it would be great if you could provide a patch. Do you
think you'll have time for that?
> No header output in RollingRandomAccessFile
> ---
>
> Key: LOG4J2-581
> URL: https://issues.apache.org/jira/browse/LOG4J2-581
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.0-rc1
>Reporter: Alexander Khokhlov
>
> No header output in RollingRandomAccessFile due to DummyOutputStream used
> when creating RollingRandomAccessFileManager.
> {code:title=RollingRandomAccessFileManager.java}
> ...
> 162:return new RollingRandomAccessFileManager(raf, name,
> data.pattern, +new DummyOutputStream()+, data.append,
> 163:data.immediateFlush, size, time, data.policy,
> data.strategy, data.advertiseURI, data.layout);
> {code}
> When the superclass constructor (OutputStreamManager) writes header, it
> outputs thus header to nowhere:
> {code:title=OutputStreamManager.java}
> 35:protected OutputStreamManager(final OutputStream os, final String
> streamName, final Layout layout) {
> 36:super(streamName);
> 37:this.os = os;
> 38:if (layout != null) {
> 39:this.footer = layout.getFooter();
> 40:this.header = layout.getHeader();
> 41:if (this.header != null) {
> 42:try {
> 43:!!! this.os.write(header, 0, header.length);
> 44:} catch (final IOException ioe) {
> 45:LOGGER.error("Unable to write header", ioe);
> 46:}
> 47:}
> 48:} else {
> 49:this.footer = null;
> 50:this.header = null;
> 51:}
> 52:}
> {code}
> The same fragment from RollingFileManager.java where header output works fine:
> {code:title=RollingFileManager.java}
> 306:os = new FileOutputStream(name, data.append);
> 307:if (data.bufferedIO) {
> 308:os = new BufferedOutputStream(os);
> 309:}
> 310:final long time = file.lastModified(); // LOG4J2-531
> create file first so time has valid value
> 311:return new RollingFileManager(name, data.pattern, +os+,
> data.append, size, time, data.policy,
> 312:data.strategy, data.advertiseURI, data.layout);
> {code}
> In this case the "os" variable is a real stream which points to the file.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Reopened] (LOG4J2-570) Memory Leak
[ https://issues.apache.org/jira/browse/LOG4J2-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma reopened LOG4J2-570: Reopened. (We haven't found a solution yet, but that's not a good reason to close the issue.) > Memory Leak > --- > > Key: LOG4J2-570 > URL: https://issues.apache.org/jira/browse/LOG4J2-570 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.0-rc1 > Environment: Ubuntu 12.04 > Linux 3.2.0-58-generic x86_64 GNU/Linux > 8 GB RAM > java version "1.7.0_51" > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) > JAVA_OPTS=-Xmx1024m -Dsun.net.inetaddr.ttl=60 > -Dsun.net.inetaddr.negative.ttl=60 -Djava.net.preferIPv4Stack=true > -XX:PermSize=128m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC > -XX:+CMSClassUnloadingEnabled > 2.0-rc1 > log4j-api > log4j-core > log4j-jcl > Spring webmvc 4.0.2.RELEASE application (simple hello world) deployed in > tomcat7.0.52 container. >Reporter: Scott >Assignee: Matt Sicker >Priority: Blocker > Labels: memory_leak > Fix For: 2.0-rc2 > > Attachments: spring_log4j2_memory_leak.tbz2 > > > Dynamically loading a JAR that uses log4j2 results in a memory leak when the > JAR is unloaded. This can be observed by deploying a web application to > tomcat7 and exercising the stop, undeploy, or redeploy actions. The memory > leak is believed to be caused by log4j for the following reasons: > 1)Heap Dump reveals the classloader instance responsible for the WAR plugin > (of type org.apache.catalina.loader.WebappClassLoader) has 2 non weak/soft > reference which are of type > (org.apache.logging.log4j.core.LoggerContext$ShutdownThread) and > (org.apache.logging.log4j.core.jmx.LoggerContextAdmin) after the WAR has been > stopped or undeployed. > 2)Using SLF4J (slf4j-api, jcl-over-slf4j) to logback-classic logging output > is equivalent but all memory is gc as expected (the > org.apache.catalina.loader.WebappClassLoader which loaded the WAR is no > longer referenced by any hard references) > 3)Using the SLF4J NOP logger implementation all memory is gc as expected (the > org.apache.catalina.loader.WebappClassLoader which loaded the WAR is no > longer referenced by any hard references) > This may not be unique to 2.0rc-1 and I have seen similar behavior in > previous 2.0 beta releases. > This is reproducible with a very simple spring hello world application. Code > and/or heap dumps can be provided upon request. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-593) INFO: Illegal access: this web application instance has been stopped already.
[ https://issues.apache.org/jira/browse/LOG4J2-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13957478#comment-13957478 ] Remko Popma commented on LOG4J2-593: Is this a log4j problem? Do you have a stack trace? We need more detail (what web container are you using, java version, steps to reproduce the issue)? This does not give us much to go on... > INFO: Illegal access: this web application instance has been stopped already. > - > > Key: LOG4J2-593 > URL: https://issues.apache.org/jira/browse/LOG4J2-593 > Project: Log4j 2 > Issue Type: Question >Reporter: Arul Anthony Sebastian >Priority: Critical > > INFO: Illegal access: this web application instance has been stopped already. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-406) JMX MBeans are not being unregistered when a tomcat web application that uses log4j is undeployed, leading to a permgen memory leak.
[ https://issues.apache.org/jira/browse/LOG4J2-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962398#comment-13962398 ] Remko Popma commented on LOG4J2-406: This ticket only mentions the stopgap solution. A more fine-grained solution was implemented with LOG4J2-500. > JMX MBeans are not being unregistered when a tomcat web application that uses > log4j is undeployed, leading to a permgen memory leak. > > > Key: LOG4J2-406 > URL: https://issues.apache.org/jira/browse/LOG4J2-406 > Project: Log4j 2 > Issue Type: Bug > Components: Core, JMX >Affects Versions: 2.0-beta9 > Environment: Java 1.7.0_17-b02, tomcat 7.0.34.0, NetBeans 7.3, > Windows 7 (64 bit) >Reporter: Kerrigan Joseph >Assignee: Remko Popma > Fix For: 2.0-rc1, 2.0 > > Attachments: PermGen.zip > > > When the log4j2 library is being used with a tomcat web application (included > in the web application's libraries, not in the container's libraries), tomcat > correctly discovers and initializes the Log4jServletContainerInitializer and > adds the Log4JServletContextListener as described in the > [manual|http://logging.apache.org/log4j/2.x/manual/webapp.html] (after > removing "log4j*.jar" from the jarsToSkip property as described on that > page). However, two MBeans that log4j registers (ContextSelector and > StatusLogger) are never unregistered when the web application is undeployed. > This prevents the entire web application from being garbage collected and > leads to a permgen memory leak and causes an OutOfMemoryError after a few > undeploy/redeploy cycles*. > We could work around this by taking the following steps: > # Added a context parameter to the web.xml file specifying a value for the > log4jContextName parameter. This seems to prevent > java.lang.ApplicationShutdownHooks from keeping a refernce to the log4j > LoggerContext, which was part of why the memory leak was occuring**. > # In addition, took one of the following measures: > #* Added the log4j2 libraries to tomcat's classpath. Regardless of whether or > not the libraries were in the web application's classpath, this seemed to > circumvent the entire issue. > #* Disabled jmx entirely, by adding -Dlog4j.disable.jmx=true to the JVM > options for tomcat. > #* Added a custom ServletContextListener which manually unregisters all log4j > MBeans upon the destruction of the context. > Any of the steps from 2 worked equally well, but none of them worked unless > we also took step 1. > \* We used jmap and jhat to confirm that the application was not being > unloaded from memory after being undeployed, and were able to narrow the > cause down to those MBeans by tracing a reference path from the > StandardClassloader through them to the WebappClassLoader. > \** We're unsure of what role ApplicationShutdownHooks plays in this > scenario, but we observed in jhat that the reference path between log4j and > ApplicationShutdownHooks disappeared after adding the log4jContextName > parameter, and that this was necessary to stop the permgen memory leak. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-578) JMX Memory Leak in Servlet Container
[
https://issues.apache.org/jira/browse/LOG4J2-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962409#comment-13962409
]
Remko Popma commented on LOG4J2-578:
Which version of Tomcat are you using when you see the memory leak?
The logic to have MBeans register/unregister for each LoggerContext (more
fine-grained than the stopgap solution of LOG4J2-500) was implemented in
LOG4J2-529, and tested with Tomcat 7.0.40, Tomcat 7.0.50, and Tomcat 8.0.1.
Special steps are necessary for Tomcat 7.0.40 because of a bug in Tomcat.
> JMX Memory Leak in Servlet Container
>
>
> Key: LOG4J2-578
> URL: https://issues.apache.org/jira/browse/LOG4J2-578
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-rc1
> Environment: Ubuntu 12.04
> Linux 3.2.0-58-generic x86_64 GNU/Linux
> 8 GB RAM
> java version "1.7.0_51"
> Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
> JAVA_OPTS=-Xmx1024m -Dsun.net.inetaddr.ttl=60
> -Dsun.net.inetaddr.negative.ttl=60 -Djava.net.preferIPv4Stack=true
> -XX:PermSize=128m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC
> -XX:+CMSClassUnloadingEnabled
>Reporter: Scott
>Priority: Critical
> Labels: memory_leak
>
> If JMX is enabled in Log4j2 (it is by default) and a web application is
> unloaded then Log4j2 creates a memory leak. This can be observed by deploying
> a web application to tomcat7 and exercising the stop, undeploy, or redeploy
> actions. The "unloaded" terminology is meant to be generic across servlet
> containers in that any action which is designed to make the web application
> classes eligible for GC. The memory leak is believed to be caused by log4j
> for the following reasons:
> 1)Heap Dump reveals the classloader instance responsible for the WAR plugin
> (for tomcat7 is of type
> {code}org.apache.catalina.loader.WebappClassLoader{code}) has 1 non weak/soft
> reference which is of type
> {code}org.apache.logging.log4j.core.jmx.LoggerContextAdmin{code} after the
> WAR has been stopped or undeployed.
> 2) Disabling JMX in Log4j2 (see
> [http://logging.apache.org/log4j/2.x/manual/jmx.html]) results in no memory
> leaks and all resources are GC as expected.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
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-578) JMX Memory Leak in Servlet Container
[
https://issues.apache.org/jira/browse/LOG4J2-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962409#comment-13962409
]
Remko Popma edited comment on LOG4J2-578 at 4/8/14 12:09 AM:
-
Which version of Tomcat are you using when you see the memory leak?
The logic to have MBeans register/unregister for each LoggerContext (more
fine-grained than the stopgap solution of LOG4J2-500) was implemented in
LOG4J2-529, and tested with Tomcat 7.0.40, Tomcat 7.0.50, and Tomcat 8.0.1.
Special steps are necessary for Tomcat 7.0.40 because of a bug in Tomcat.
Also, be careful that the version mentioned in {{web.xml}} (Servlet 2.4 or
3.0+) matches the container version. Log4J auto-initialization needs this
version to be correct. (See comments in LOG4J2-529 for details.)
was (Author: rem...@yahoo.com):
Which version of Tomcat are you using when you see the memory leak?
The logic to have MBeans register/unregister for each LoggerContext (more
fine-grained than the stopgap solution of LOG4J2-500) was implemented in
LOG4J2-529, and tested with Tomcat 7.0.40, Tomcat 7.0.50, and Tomcat 8.0.1.
Special steps are necessary for Tomcat 7.0.40 because of a bug in Tomcat.
> JMX Memory Leak in Servlet Container
>
>
> Key: LOG4J2-578
> URL: https://issues.apache.org/jira/browse/LOG4J2-578
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-rc1
> Environment: Ubuntu 12.04
> Linux 3.2.0-58-generic x86_64 GNU/Linux
> 8 GB RAM
> java version "1.7.0_51"
> Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
> JAVA_OPTS=-Xmx1024m -Dsun.net.inetaddr.ttl=60
> -Dsun.net.inetaddr.negative.ttl=60 -Djava.net.preferIPv4Stack=true
> -XX:PermSize=128m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC
> -XX:+CMSClassUnloadingEnabled
>Reporter: Scott
>Priority: Critical
> Labels: memory_leak
>
> If JMX is enabled in Log4j2 (it is by default) and a web application is
> unloaded then Log4j2 creates a memory leak. This can be observed by deploying
> a web application to tomcat7 and exercising the stop, undeploy, or redeploy
> actions. The "unloaded" terminology is meant to be generic across servlet
> containers in that any action which is designed to make the web application
> classes eligible for GC. The memory leak is believed to be caused by log4j
> for the following reasons:
> 1)Heap Dump reveals the classloader instance responsible for the WAR plugin
> (for tomcat7 is of type
> {code}org.apache.catalina.loader.WebappClassLoader{code}) has 1 non weak/soft
> reference which is of type
> {code}org.apache.logging.log4j.core.jmx.LoggerContextAdmin{code} after the
> WAR has been stopped or undeployed.
> 2) Disabling JMX in Log4j2 (see
> [http://logging.apache.org/log4j/2.x/manual/jmx.html]) results in no memory
> leaks and all resources are GC as expected.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-548) Log4j 2.0 with JBoss EAP 6.2
[ https://issues.apache.org/jira/browse/LOG4J2-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13977561#comment-13977561 ] Remko Popma commented on LOG4J2-548: If you say "should", did you test that the problem can no longer be reproduced? If not, we can ask the reporter to test with trunk but perhaps marking as resolved is too soon. > Log4j 2.0 with JBoss EAP 6.2 > - > > Key: LOG4J2-548 > URL: https://issues.apache.org/jira/browse/LOG4J2-548 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.0-rc1 > Environment: EJB 3.1 , JBoss EAP 6.2 , Windows 7 , Eclipse Kepler >Reporter: Shehata >Assignee: Ralph Goers > Fix For: 2.0-rc2 > > Original Estimate: 2h > Remaining Estimate: 2h > > When trying to use log4j 2.0-rc1 with EJB3.1 i got Error Message: > "ERROR StatusLogger Could not search jar file > 'jboss-eap-6.2\standalone\deployments\Log4J2Ear.ear\lib\log4j-core-2.0-rc1.jar\org\apache\logging\log4j\core' > for classes matching criteria: annotated with @Plugin file not found" > after debugging the application found that the problem is located in : > org.apache.logging.log4j.core.config.plugins.ResolverUtil > method: findInPackage --> line number 247 > the protocol used in the jar is vfs not vfszip -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-615) Why Rolling file appender writes to console also.
[
https://issues.apache.org/jira/browse/LOG4J2-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-615:
---
Description:
Rolling file appender writes to console also. java 7 is used. The configuration
is as below.
{code}
${sys:logPattern}
${sys:logfilepath}//$${date:-MM}//${sys:oft.appserver}-out-%d{-MM-dd}.log
${sys:logfilepath}//${sys:oft.appserver}-out.log
${patternUMP}
{code}
was:
Rolling file appender writes to console also. java 7 is used. The configuration
is as below.
${sys:logPattern}
${sys:logfilepath}//$${date:-MM}//${sys:oft.appserver}-out-%d{-MM-dd}.log
${sys:logfilepath}//${sys:oft.appserver}-out.log
${patternUMP}
Some more tips: usually it is a good idea to have a root logger to capture all
log events, and use named loggers for special cases.
Also, if you already use AsyncLoggers you don't need AsyncAppender.
> Why Rolling file appender writes to console also.
> -
>
> Key: LOG4J2-615
> URL: https://issues.apache.org/jira/browse/LOG4J2-615
> Project: Log4j 2
> Issue Type: Bug
> Environment: Java 7
>Reporter: sivan
>Priority: Critical
>
> Rolling file appender writes to console also. java 7 is used. The
> configuration is as below.
> {code}
>
>
>
> ${sys:logPattern}
>name="filePattern">${sys:logfilepath}//$${date:-MM}//${sys:oft.appserver}-out-%d{-MM-dd}.log
>name="fileName">${sys:logfilepath}//${sys:oft.appserver}-out.log
>
>
>filePattern="${filePattern}">
>
> ${patternUMP}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>includeLocation="true">
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-252) SMTPAppender: send multiple events in one mail
[ https://issues.apache.org/jira/browse/LOG4J2-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13984244#comment-13984244 ] Remko Popma commented on LOG4J2-252: Matej, no, I don't think anyone is working on this at the moment. If this is important to you, please consider submitting a patch. > SMTPAppender: send multiple events in one mail > -- > > Key: LOG4J2-252 > URL: https://issues.apache.org/jira/browse/LOG4J2-252 > Project: Log4j 2 > Issue Type: Wish >Reporter: Matej Vitásek > > I am using Log4j 2 for a Tomcat web application to send me an e-mail whenever > an ERROR occurs. Usually, more than one error is produced at one time, and I > get a lot of e-mails over a period of a few seconds. > It would be great if the SMTPAppender could cluster more events into one > mail. Of course, one has to be sure that Log4j 2 is not waiting too long to > send me the errors, which could be solved by a timeout setting. > So I propose the following: add a new timeout setting to the SMTPAppender. > Whenever an event that would trigger sending a mail occurs, wait for timeout > seconds and bundle whatever else events occur into this mail. Only then send > the mail. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-615) Why Rolling file appender writes to console also.
[
https://issues.apache.org/jira/browse/LOG4J2-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma closed LOG4J2-615.
--
Glad to hear that. I'll close this issue. Feel free to re-open or raise another
issue if necessary.
> Why Rolling file appender writes to console also.
> -
>
> Key: LOG4J2-615
> URL: https://issues.apache.org/jira/browse/LOG4J2-615
> Project: Log4j 2
> Issue Type: Bug
> Environment: Java 7
>Reporter: sivan
>Priority: Critical
>
> Rolling file appender writes to console also. java 7 is used. The
> configuration is as below.
> {code}
>
>
>
> ${sys:logPattern}
>name="filePattern">${sys:logfilepath}//$${date:-MM}//${sys:oft.appserver}-out-%d{-MM-dd}.log
>name="fileName">${sys:logfilepath}//${sys:oft.appserver}-out.log
>
>
>filePattern="${filePattern}">
>
> ${patternUMP}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>includeLocation="true">
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-626) ThreadContext for Asynchronous logger in multithreaded environmant is overwriting the values.
[ https://issues.apache.org/jira/browse/LOG4J2-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13985328#comment-13985328 ] Remko Popma commented on LOG4J2-626: Sorry but this is not enough information to even start investigating. Please update the problem description with: 1. Steps to reproduce the problem 2. What is actually happening 3. What you expect to happen > ThreadContext for Asynchronous logger in multithreaded environmant is > overwriting the values. > - > > Key: LOG4J2-626 > URL: https://issues.apache.org/jira/browse/LOG4J2-626 > Project: Log4j 2 > Issue Type: Question > Components: API >Affects Versions: 2.0-rc1 > Environment: java 7 >Reporter: sivan > > ThreadContext for Asynchronous loggers in multithreaded environmant is > overwriting the values. Is there is any way to use the custom key value pairs > in such an environment? -- This message was sent by Atlassian JIRA (v6.2#6252) - 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-626) ThreadContext for Asynchronous logger in multithreaded environmant is overwriting the values.
[ https://issues.apache.org/jira/browse/LOG4J2-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13985328#comment-13985328 ] Remko Popma edited comment on LOG4J2-626 at 4/30/14 12:36 PM: -- Log4j classes will _read_ values from the ThreadContext map or stack, but it will not modify them. I suspect this is a bug in the application... Can you reliably reproduce the problem? What are you seeing and what did you expect to see? Are all key value pairs modified or only some (which ones, when)? was (Author: rem...@yahoo.com): Sorry but this is not enough information to even start investigating. Please update the problem description with: 1. Steps to reproduce the problem 2. What is actually happening 3. What you expect to happen > ThreadContext for Asynchronous logger in multithreaded environmant is > overwriting the values. > - > > Key: LOG4J2-626 > URL: https://issues.apache.org/jira/browse/LOG4J2-626 > Project: Log4j 2 > Issue Type: Question > Components: API >Affects Versions: 2.0-rc1 > Environment: java 7 >Reporter: sivan > > ThreadContext for Asynchronous loggers in multithreaded environmant is > overwriting the values. Is there is any way to use the custom key value pairs > in such an environment? > The log4j2 document says that the values in threadcontext may overwrite by > asynchronous logging in multithreaded envirnment. We are implemented the > log4j2 asynchronous logging in our single sign on (SSO) framework and the > threadcontext is used to store some parameter values like sessionId, firm, > user etc and these values needs to be included in the log entry. At a time > many users will log into our site by using SSO. Is the threadcontext values > will change by asynchronous logging in multithreaded envirnment? If so, is > there any other way to store these values in thread safe manner? -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-628) Cannot set log4j.Clock with Async appender
[
https://issues.apache.org/jira/browse/LOG4J2-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986246#comment-13986246
]
Remko Popma commented on LOG4J2-628:
This is expected behaviour as of RC-1.
The use case for the Clock interface was to allow an extra performance
optimization for users who want to squeeze the last drop of performance out of
the logging subsystem. The trade-off is that the faster CachedClock
implementation shows jumps of 10-16 milliseconds, so you lose accuracy in the
log timestamps.
However this optimization only becomes visible after other bottlenecks have
been removed. The performance bottleneck of Async appender is on the queue, and
optimizing the timestamping mechanism would not make a visible difference in
performance.
If your use case for using a custom Clock is not performance related, can you
clarify what it is you are trying to achieve?
Perhaps it would make sense to use the Clock interface consistently everywhere
in Log4j.
> Cannot set log4j.Clock with Async appender
> --
>
> Key: LOG4J2-628
> URL: https://issues.apache.org/jira/browse/LOG4J2-628
> Project: Log4j 2
> Issue Type: Question
> Components: Appenders
>Affects Versions: 2.0-rc1
> Environment: Ubuntu 12.04 / Java 7
>Reporter: Bryan Hsueh
>
> I override log4j.Clock to support a "live" time vs a "simulated" time.
> System.setProperty("log4j.Clock", "teambh.trade.utils.MyClock");
> If I use asynchronous loggers, it works fine and calls my
> Clock:currentTimeMillis().
> If I switch to async appenders, currentTimeMillis() is not called.
> Is this expected behavior or a bug?
> Thanks
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-626) ThreadContext for Asynchronous logger in multithreaded environmant is overwriting the values.
[
https://issues.apache.org/jira/browse/LOG4J2-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986258#comment-13986258
]
Remko Popma commented on LOG4J2-626:
It should not matter whether you use asynchronous or synchronous logging. When
the application logs a message, Log4j will take a snapshot of the ThreadContext
map of that thread. The snapshot will not change even if the application later
modifies the ThreadContext map.
Depending on your configuration, you may see some or all of the ThreadContext
values in the resulting log file. What you see in the log are the values of the
ThreadContext at the time that the application called {{logger.log(message)}}
and Log4j took a ThreadContext map snapshot.
Does this match what you are seeing?
One thing to be aware of: if you are using a thread pool (and most web
application servers do), you are re-using threads. So it may be a good idea to
"clean" the ThreadContext from the thread after you are done with it.
> ThreadContext for Asynchronous logger in multithreaded environmant is
> overwriting the values.
> -
>
> Key: LOG4J2-626
> URL: https://issues.apache.org/jira/browse/LOG4J2-626
> Project: Log4j 2
> Issue Type: Question
> Components: API
>Affects Versions: 2.0-rc1
> Environment: java 7
>Reporter: sivan
>
> ThreadContext for Asynchronous loggers in multithreaded environmant is
> overwriting the values. Is there is any way to use the custom key value pairs
> in such an environment?
> The log4j2 document says that the values in threadcontext may overwrite by
> asynchronous logging in multithreaded envirnment. We are implemented the
> log4j2 asynchronous logging in our single sign on (SSO) framework and the
> threadcontext is used to store some parameter values like sessionId, firm,
> user etc and these values needs to be included in the log entry. At a time
> many users will log into our site by using SSO. Is the threadcontext values
> will change by asynchronous logging in multithreaded envirnment? If so, is
> there any other way to store these values in thread safe manner?
> Log4j2 will not modify this. that is OK. But when many users at a time uses
> single sign on then what will happen to the key value pairs in the
> threadcontext. Is they will modify in multithreaded environment by
> asynchronous logger?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-628) Cannot set log4j.Clock with Async appender
[
https://issues.apache.org/jira/browse/LOG4J2-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma reassigned LOG4J2-628:
--
Assignee: Remko Popma
> Cannot set log4j.Clock with Async appender
> --
>
> Key: LOG4J2-628
> URL: https://issues.apache.org/jira/browse/LOG4J2-628
> Project: Log4j 2
> Issue Type: Question
> Components: Appenders
>Affects Versions: 2.0-rc1
> Environment: Ubuntu 12.04 / Java 7
>Reporter: Bryan Hsueh
>Assignee: Remko Popma
>
> I override log4j.Clock to support a "live" time vs a "simulated" time.
> System.setProperty("log4j.Clock", "teambh.trade.utils.MyClock");
> If I use asynchronous loggers, it works fine and calls my
> Clock:currentTimeMillis().
> If I switch to async appenders, currentTimeMillis() is not called.
> Is this expected behavior or a bug?
> Thanks
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-628) Cannot set log4j.Clock with Async appender
[
https://issues.apache.org/jira/browse/LOG4J2-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988426#comment-13988426
]
Remko Popma commented on LOG4J2-628:
Understood. We are thinking about modifying log4j to use the Clock interface to
generate timestamps for all log events, not just the log events generated by
Async Loggers.
Question: do you also want to use that Clock interface to determine the
rollover time in the RolloverAppender?
> Cannot set log4j.Clock with Async appender
> --
>
> Key: LOG4J2-628
> URL: https://issues.apache.org/jira/browse/LOG4J2-628
> Project: Log4j 2
> Issue Type: Question
> Components: Appenders
>Affects Versions: 2.0-rc1
> Environment: Ubuntu 12.04 / Java 7
>Reporter: Bryan Hsueh
>Assignee: Remko Popma
>
> I override log4j.Clock to support a "live" time vs a "simulated" time.
> System.setProperty("log4j.Clock", "teambh.trade.utils.MyClock");
> If I use asynchronous loggers, it works fine and calls my
> Clock:currentTimeMillis().
> If I switch to async appenders, currentTimeMillis() is not called.
> Is this expected behavior or a bug?
> Thanks
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-628) Cannot set log4j.Clock with Async appender
[
https://issues.apache.org/jira/browse/LOG4J2-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988580#comment-13988580
]
Remko Popma commented on LOG4J2-628:
I agree. Also, using the Clock interface for rollover would introduce some
interesting scenarios like the clock going back in time etc that the rollover
logic was not designed for. It may work, but I would prefer to keep the scope
of this change limited to just the log event timestamps for now.
> Cannot set log4j.Clock with Async appender
> --
>
> Key: LOG4J2-628
> URL: https://issues.apache.org/jira/browse/LOG4J2-628
> Project: Log4j 2
> Issue Type: Question
> Components: Appenders
>Affects Versions: 2.0-rc1
> Environment: Ubuntu 12.04 / Java 7
>Reporter: Bryan Hsueh
>Assignee: Remko Popma
>
> I override log4j.Clock to support a "live" time vs a "simulated" time.
> System.setProperty("log4j.Clock", "teambh.trade.utils.MyClock");
> If I use asynchronous loggers, it works fine and calls my
> Clock:currentTimeMillis().
> If I switch to async appenders, currentTimeMillis() is not called.
> Is this expected behavior or a bug?
> Thanks
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-629) Document the system properties that can be used to modify Log4j 2's behaviour
Remko Popma created LOG4J2-629: -- Summary: Document the system properties that can be used to modify Log4j 2's behaviour Key: LOG4J2-629 URL: https://issues.apache.org/jira/browse/LOG4J2-629 Project: Log4j 2 Issue Type: Improvement Components: Documentation Affects Versions: 2.0-rc1 Reporter: Remko Popma Assignee: Remko Popma Fix For: 2.0-rc2 Provide a list of system properties that can be used to modify Log4j 2's behaviour. Ideally include default value, valid values, and description. Include this list in the Configuration manual page. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-629) Document the system properties that can be used to modify Log4j 2's behaviour
[ https://issues.apache.org/jira/browse/LOG4J2-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed LOG4J2-629. -- Resolution: Fixed Fixed in revision 1592221. > Document the system properties that can be used to modify Log4j 2's behaviour > - > > Key: LOG4J2-629 > URL: https://issues.apache.org/jira/browse/LOG4J2-629 > Project: Log4j 2 > Issue Type: Improvement > Components: Documentation >Affects Versions: 2.0-rc1 >Reporter: Remko Popma >Assignee: Remko Popma > Fix For: 2.0-rc2 > > > Provide a list of system properties that can be used to modify Log4j 2's > behaviour. Ideally include default value, valid values, and description. > Include this list in the Configuration manual page. -- This message was sent by Atlassian JIRA (v6.2#6252) - 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-629) Document the system properties that can be used to modify Log4j 2's behaviour
[ https://issues.apache.org/jira/browse/LOG4J2-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988715#comment-13988715 ] Remko Popma edited comment on LOG4J2-629 at 5/3/14 3:52 PM: Fixed in revision 1592221 and revision 1592232. was (Author: rem...@yahoo.com): Fixed in revision 1592221. > Document the system properties that can be used to modify Log4j 2's behaviour > - > > Key: LOG4J2-629 > URL: https://issues.apache.org/jira/browse/LOG4J2-629 > Project: Log4j 2 > Issue Type: Improvement > Components: Documentation >Affects Versions: 2.0-rc1 >Reporter: Remko Popma >Assignee: Remko Popma > Fix For: 2.0-rc2 > > > Provide a list of system properties that can be used to modify Log4j 2's > behaviour. Ideally include default value, valid values, and description. > Include this list in the Configuration manual page. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-629) Document the system properties that can be used to modify Log4j 2's behaviour
[ https://issues.apache.org/jira/browse/LOG4J2-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed LOG4J2-629. -- Resolution: Fixed > Document the system properties that can be used to modify Log4j 2's behaviour > - > > Key: LOG4J2-629 > URL: https://issues.apache.org/jira/browse/LOG4J2-629 > Project: Log4j 2 > Issue Type: Improvement > Components: Documentation >Affects Versions: 2.0-rc1 >Reporter: Remko Popma >Assignee: Remko Popma > Fix For: 2.0-rc2 > > > Provide a list of system properties that can be used to modify Log4j 2's > behaviour. Ideally include default value, valid values, and description. > Include this list in the Configuration manual page. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Reopened] (LOG4J2-629) Document the system properties that can be used to modify Log4j 2's behaviour
[ https://issues.apache.org/jira/browse/LOG4J2-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma reopened LOG4J2-629: > Document the system properties that can be used to modify Log4j 2's behaviour > - > > Key: LOG4J2-629 > URL: https://issues.apache.org/jira/browse/LOG4J2-629 > Project: Log4j 2 > Issue Type: Improvement > Components: Documentation >Affects Versions: 2.0-rc1 >Reporter: Remko Popma >Assignee: Remko Popma > Fix For: 2.0-rc2 > > > Provide a list of system properties that can be used to modify Log4j 2's > behaviour. Ideally include default value, valid values, and description. > Include this list in the Configuration manual page. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-628) Cannot set log4j.Clock with Async appender
[
https://issues.apache.org/jira/browse/LOG4J2-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved LOG4J2-628.
Resolution: Fixed
Fix Version/s: 2.0-rc2
Fixed in revision 1592242.
The Clock interface is now used to generate all log event timestamps, not just
for Async Loggers.
Please verify and close.
> Cannot set log4j.Clock with Async appender
> --
>
> Key: LOG4J2-628
> URL: https://issues.apache.org/jira/browse/LOG4J2-628
> Project: Log4j 2
> Issue Type: Question
> Components: Appenders
>Affects Versions: 2.0-rc1
> Environment: Ubuntu 12.04 / Java 7
>Reporter: Bryan Hsueh
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
>
> I override log4j.Clock to support a "live" time vs a "simulated" time.
> System.setProperty("log4j.Clock", "teambh.trade.utils.MyClock");
> If I use asynchronous loggers, it works fine and calls my
> Clock:currentTimeMillis().
> If I switch to async appenders, currentTimeMillis() is not called.
> Is this expected behavior or a bug?
> Thanks
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-520) RollingRandomAccessFile with Async Appender skip logs
[
https://issues.apache.org/jira/browse/LOG4J2-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988948#comment-13988948
]
Remko Popma commented on LOG4J2-520:
Andre, I've started to look at this issue again.
With your AppenderOverwhelmer program, and the log4j2.xml file attached to this
issue, I can reproduce the issue.
So far, I've found that the application thread does wait correctly until there
are no more log events in the ringbuffer. Only after the ringbuffer is empty
does the program go ahead and shut down the disruptor.
Interestingly, even though the queue is empty, the ConsoleAppender only prints
out 730,000-740,000 events (out of 1,000,000) before the application exits. I
added a counter to this appender and this counter confirms not all events have
reached the appender. What I don't understand yet is why the ringbuffer reports
it is empty: this should not happen unless all events have been consumed...
What is also interesting is that I cannot reproduce the problem with a
RandomAccessFileAppender. If I replace the ConsoleAppender with a
RandomAccessFileAppender and run the ApplicationOverwhelmer the resulting log
file has all 1,000,000 events without dropping a single event.
I need to look at this some more.
> RollingRandomAccessFile with Async Appender skip logs
> -
>
> Key: LOG4J2-520
> URL: https://issues.apache.org/jira/browse/LOG4J2-520
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.0-beta9, 2.0-rc1
> Environment: JDK 1.6, Eclipse
>Reporter: JavaTech
>Assignee: Remko Popma
> Attachments: log4j2.xml
>
>
> I have written a sample code which will write DEBUG, INFO , WARN logs in a
> single flile, I have written a logs in FOR loop printing numbers from 1 to 99.
> sometime it print numbers incomplete sequence, like 1 to 67, 1 to 89 etc.
> log4j2.xml
> {code:xml}
>
>
>
>fileName="logs/app.log"
> filePattern="logs/$${date:-MM}/app-%d{MM-dd-}-%i.log"
> immediateFlush="false" append="true" ignoreExceptions="false">
>
> %d %-5p [%t] (%F:%L) - %m%n
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Sample Java Code
> {code}
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> public class LoggerUtil {
> public static Logger logger = LoggerFactory.getLogger(LoggerUtil.class);
> public static void main(String[] args) {
> System.out.println("start");
> logger.debug("debug log");
> logger.info("info log");
> logger.error("error log");
> for(int i = 0; i < 99; i++) {
> logger.warn("{}",i);
> System.out.println("I : - " + i);
> }
> logger.error("finish printing logs");
> System.out.println("end");
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-520) RollingRandomAccessFile with Async Appender skip logs
[
https://issues.apache.org/jira/browse/LOG4J2-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13989002#comment-13989002
]
Remko Popma commented on LOG4J2-520:
You were right: this is related to the fix for LOG4J2-392 and that fix is the
culprit.
The problem with the current implementation is that appenders are removed
before the ringbuffer has had a chance to drain.
I hope to have a better implementation soon.
> RollingRandomAccessFile with Async Appender skip logs
> -
>
> Key: LOG4J2-520
> URL: https://issues.apache.org/jira/browse/LOG4J2-520
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.0-beta9, 2.0-rc1
> Environment: JDK 1.6, Eclipse
>Reporter: JavaTech
>Assignee: Remko Popma
> Attachments: log4j2.xml
>
>
> I have written a sample code which will write DEBUG, INFO , WARN logs in a
> single flile, I have written a logs in FOR loop printing numbers from 1 to 99.
> sometime it print numbers incomplete sequence, like 1 to 67, 1 to 89 etc.
> log4j2.xml
> {code:xml}
>
>
>
>fileName="logs/app.log"
> filePattern="logs/$${date:-MM}/app-%d{MM-dd-}-%i.log"
> immediateFlush="false" append="true" ignoreExceptions="false">
>
> %d %-5p [%t] (%F:%L) - %m%n
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Sample Java Code
> {code}
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> public class LoggerUtil {
> public static Logger logger = LoggerFactory.getLogger(LoggerUtil.class);
> public static void main(String[] args) {
> System.out.println("start");
> logger.debug("debug log");
> logger.info("info log");
> logger.error("error log");
> for(int i = 0; i < 99; i++) {
> logger.warn("{}",i);
> System.out.println("I : - " + i);
> }
> logger.error("finish printing logs");
> System.out.println("end");
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Reopened] (LOG4J2-392) Intermittent errors with appenders
[ https://issues.apache.org/jira/browse/LOG4J2-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma reopened LOG4J2-392: Re-opening as the current fix may result in dropped events in case of slow appenders (LOG4J2-520). > Intermittent errors with appenders > -- > > Key: LOG4J2-392 > URL: https://issues.apache.org/jira/browse/LOG4J2-392 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.0-beta8, 2.0-beta9 > Environment: Windows 7 SP1 64bit >Reporter: ilynaf >Assignee: Remko Popma > Fix For: 2.0-rc1 > > Attachments: AppenderOverwhelmer.java, Log4J2.zip, log4j2.xml > > > I intermittently receive following errors after upgrading to beta 8. > EVERYTHING was working well with beta 6: > * 1st error (happens most frequently) > 2013-09-05 10:48:37,722 ERROR Attempted to append to non-started appender > LogFile > * 2nd error: > 2013-09-05 10:49:38,268 ERROR Attempted to append to non-started appender > LogFile > 2013-09-05 10:49:38,268 ERROR Unable to write to stream > log/ui-selenium-tests.log for appender LogFile > 2013-09-05 10:49:38,269 ERROR An exception occurred processing Appender > LogFile org.apache.logging.log4j.core.appender.AppenderRuntimeException: > Error writing to RandomAccessFile log/ui-selenium-tests.log > at > org.apache.logging.log4j.core.appender.rolling.FastRollingFileManager.flush(FastRollingFileManager.java:108) > at > org.apache.logging.log4j.core.appender.rolling.FastRollingFileManager.write(FastRollingFileManager.java:89) > at > org.apache.logging.log4j.core.appender.OutputStreamManager.write(OutputStreamManager.java:129) > at > org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:115) > at > org.apache.logging.log4j.core.appender.FastRollingFileAppender.append(FastRollingFileAppender.java:97) > at > org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:102) > at > org.apache.logging.log4j.core.appender.AsyncAppender$AsyncThread.run(AsyncAppender.java:228) > Caused by: java.io.IOException: Write error > at java.io.RandomAccessFile.writeBytes(Native Method) > at java.io.RandomAccessFile.write(Unknown Source) > at > org.apache.logging.log4j.core.appender.rolling.FastRollingFileManager.flush(FastRollingFileManager.java:105) > ... 6 more -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-521) RollingRandomAccessFile + Async Appender skip logs sometimes (while logging into same file and while switching to another log file)
[ https://issues.apache.org/jira/browse/LOG4J2-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed LOG4J2-521. -- Resolution: Duplicate No reaction from the user, closing this issue as a duplicate of LOG4J2-520. Please re-open with more information if this is a separate issue. > RollingRandomAccessFile + Async Appender skip logs sometimes (while logging > into same file and while switching to another log file) > --- > > Key: LOG4J2-521 > URL: https://issues.apache.org/jira/browse/LOG4J2-521 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.0-beta9 > Environment: JDK 1.6, Eclipse >Reporter: JavaTech > -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-392) Intermittent errors with appenders
[ https://issues.apache.org/jira/browse/LOG4J2-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma resolved LOG4J2-392. Resolution: Fixed Fix Version/s: (was: 2.0-rc1) 2.1 2.0-rc2 The previous solution cleared the appenders from the logger config too soon. The new solution first signals to all AsyncLoggerConfig instances that the application is being stopped. When all AsyncLoggerConfig instances are signalled, and the usage count drops to zero, the shared Disruptor is shut down. (It will process all enqueued events before actually stopping.) Only after all enqueued events have been processed are the appenders stopped and cleared from the logger configs. Fixed in revision 1592463. Please verify and close. > Intermittent errors with appenders > -- > > Key: LOG4J2-392 > URL: https://issues.apache.org/jira/browse/LOG4J2-392 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.0-beta8, 2.0-beta9 > Environment: Windows 7 SP1 64bit >Reporter: ilynaf >Assignee: Remko Popma > Fix For: 2.0-rc2, 2.1 > > Attachments: AppenderOverwhelmer.java, Log4J2.zip, log4j2.xml > > > I intermittently receive following errors after upgrading to beta 8. > EVERYTHING was working well with beta 6: > * 1st error (happens most frequently) > 2013-09-05 10:48:37,722 ERROR Attempted to append to non-started appender > LogFile > * 2nd error: > 2013-09-05 10:49:38,268 ERROR Attempted to append to non-started appender > LogFile > 2013-09-05 10:49:38,268 ERROR Unable to write to stream > log/ui-selenium-tests.log for appender LogFile > 2013-09-05 10:49:38,269 ERROR An exception occurred processing Appender > LogFile org.apache.logging.log4j.core.appender.AppenderRuntimeException: > Error writing to RandomAccessFile log/ui-selenium-tests.log > at > org.apache.logging.log4j.core.appender.rolling.FastRollingFileManager.flush(FastRollingFileManager.java:108) > at > org.apache.logging.log4j.core.appender.rolling.FastRollingFileManager.write(FastRollingFileManager.java:89) > at > org.apache.logging.log4j.core.appender.OutputStreamManager.write(OutputStreamManager.java:129) > at > org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:115) > at > org.apache.logging.log4j.core.appender.FastRollingFileAppender.append(FastRollingFileAppender.java:97) > at > org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:102) > at > org.apache.logging.log4j.core.appender.AsyncAppender$AsyncThread.run(AsyncAppender.java:228) > Caused by: java.io.IOException: Write error > at java.io.RandomAccessFile.writeBytes(Native Method) > at java.io.RandomAccessFile.write(Unknown Source) > at > org.apache.logging.log4j.core.appender.rolling.FastRollingFileManager.flush(FastRollingFileManager.java:105) > ... 6 more -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-520) RollingRandomAccessFile with Async Appender skip logs
[
https://issues.apache.org/jira/browse/LOG4J2-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13989407#comment-13989407
]
Remko Popma commented on LOG4J2-520:
I revisited the fix for LOG4J2-392 and confirmed that this solves the problem
with AsyncLoggerConfig. The new fix is available in trunk.
Unfortunately I can still reproduce the problem with AsyncAppender using the
ApplicationOverwhelmer test program. I will investigate this next.
> RollingRandomAccessFile with Async Appender skip logs
> -
>
> Key: LOG4J2-520
> URL: https://issues.apache.org/jira/browse/LOG4J2-520
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.0-beta9, 2.0-rc1
> Environment: JDK 1.6, Eclipse
>Reporter: JavaTech
>Assignee: Remko Popma
> Attachments: log4j2.xml
>
>
> I have written a sample code which will write DEBUG, INFO , WARN logs in a
> single flile, I have written a logs in FOR loop printing numbers from 1 to 99.
> sometime it print numbers incomplete sequence, like 1 to 67, 1 to 89 etc.
> log4j2.xml
> {code:xml}
>
>
>
>fileName="logs/app.log"
> filePattern="logs/$${date:-MM}/app-%d{MM-dd-}-%i.log"
> immediateFlush="false" append="true" ignoreExceptions="false">
>
> %d %-5p [%t] (%F:%L) - %m%n
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Sample Java Code
> {code}
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> public class LoggerUtil {
> public static Logger logger = LoggerFactory.getLogger(LoggerUtil.class);
> public static void main(String[] args) {
> System.out.println("start");
> logger.debug("debug log");
> logger.info("info log");
> logger.error("error log");
> for(int i = 0; i < 99; i++) {
> logger.warn("{}",i);
> System.out.println("I : - " + i);
> }
> logger.error("finish printing logs");
> System.out.println("end");
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-520) RollingRandomAccessFile with Async Appender skip logs
[
https://issues.apache.org/jira/browse/LOG4J2-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13989463#comment-13989463
]
Remko Popma commented on LOG4J2-520:
I think I got it. It took a bit of debugging, but it turns out that after the
shutdown signal is sent to AsyncAppender.AsyncThread, all events that were
still on the queue are not sent to the underlying appenders.
Here is the relevant code of AsyncAppender:
{code}
public final class AsyncAppender extends AbstractAppender {
...
209private class AsyncThread extends Thread {
...
223public void run() {
...
248// Process any remaining items in the queue.
249while (!queue.isEmpty()) {
250try {
251final Serializable s = queue.take();
252if (s instanceof Log4jLogEvent) { // <- This is wrong
253final Log4jLogEvent event =
Log4jLogEvent.deserialize(s);
254event.setEndOfBatch(queue.isEmpty());
255callAppenders(event);
256}
257} catch (final InterruptedException ex) {
258// May have been interrupted to shut down.
259}
260}
261}
{code}
Note that the instanceof check on line 252 means that only elements whose class
is {{Log4jLogEvent}} are processed. It turns out that what is on the queue is
objects of class Log4jLogEvent$LogEventProxy. So the check returns {{false}}
and everything that was still on the queue is ignored.
Looks like this check was introduced in revision 1460984. The commit comment
says "LOG4J2-146 Avoid IllegalArgumentException in AsynchAppender".
How to fix this? Remove the instanceof check altogether or keep the check but
make it work correctly?
I'm not sure what the instanceof check is trying to protect against, so I'm not
sure that removing it is a good idea.
To keep the check, we can add a method to Log4jLogEvent:
{code}
public static boolean canDeserialize(Serializable s) {
return s instanceof LogEventProxy;
}
{code}
Note that we cannot change the existing AsyncAppender code to {{if (s
instanceof Log4jLogEvent$LogEventProxy)}} because Log4jLogEvent$LogEventProxy
is a private inner class and is invisible to AsyncAppender.
I think I'll go with the {{canDeserialize}} method.
> RollingRandomAccessFile with Async Appender skip logs
> -
>
> Key: LOG4J2-520
> URL: https://issues.apache.org/jira/browse/LOG4J2-520
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.0-beta9, 2.0-rc1
> Environment: JDK 1.6, Eclipse
>Reporter: JavaTech
>Assignee: Remko Popma
> Attachments: log4j2.xml
>
>
> I have written a sample code which will write DEBUG, INFO , WARN logs in a
> single flile, I have written a logs in FOR loop printing numbers from 1 to 99.
> sometime it print numbers incomplete sequence, like 1 to 67, 1 to 89 etc.
> log4j2.xml
> {code:xml}
>
>
>
>fileName="logs/app.log"
> filePattern="logs/$${date:-MM}/app-%d{MM-dd-}-%i.log"
> immediateFlush="false" append="true" ignoreExceptions="false">
>
> %d %-5p [%t] (%F:%L) - %m%n
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Sample Java Code
> {code}
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> public class LoggerUtil {
> public static Logger logger = LoggerFactory.getLogger(LoggerUtil.class);
> public static void main(String[] args) {
> System.out.println("start");
> logger.debug("debug log");
> logger.info("info log");
> logger.error("error log");
> for(int i = 0; i < 99; i++) {
> logger.warn("{}",i);
> System.out.println("I : - " + i);
> }
> logger.error("finish printing logs");
> System.out.println("end");
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-520) RollingRandomAccessFile with Async Appender skip logs
[
https://issues.apache.org/jira/browse/LOG4J2-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved LOG4J2-520.
Resolution: Fixed
Fix Version/s: 2.0-rc2
Fixed in revision 1592522.
Please verify and close.
> RollingRandomAccessFile with Async Appender skip logs
> -
>
> Key: LOG4J2-520
> URL: https://issues.apache.org/jira/browse/LOG4J2-520
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.0-beta9, 2.0-rc1
> Environment: JDK 1.6, Eclipse
>Reporter: JavaTech
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
> Attachments: log4j2.xml
>
>
> I have written a sample code which will write DEBUG, INFO , WARN logs in a
> single flile, I have written a logs in FOR loop printing numbers from 1 to 99.
> sometime it print numbers incomplete sequence, like 1 to 67, 1 to 89 etc.
> log4j2.xml
> {code:xml}
>
>
>
>fileName="logs/app.log"
> filePattern="logs/$${date:-MM}/app-%d{MM-dd-}-%i.log"
> immediateFlush="false" append="true" ignoreExceptions="false">
>
> %d %-5p [%t] (%F:%L) - %m%n
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Sample Java Code
> {code}
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> public class LoggerUtil {
> public static Logger logger = LoggerFactory.getLogger(LoggerUtil.class);
> public static void main(String[] args) {
> System.out.println("start");
> logger.debug("debug log");
> logger.info("info log");
> logger.error("error log");
> for(int i = 0; i < 99; i++) {
> logger.warn("{}",i);
> System.out.println("I : - " + i);
> }
> logger.error("finish printing logs");
> System.out.println("end");
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-537) application does not end.
[
https://issues.apache.org/jira/browse/LOG4J2-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13989512#comment-13989512
]
Remko Popma commented on LOG4J2-537:
Moonumi, Gleb,
Is this still a problem?
> application does not end.
> -
>
> Key: LOG4J2-537
> URL: https://issues.apache.org/jira/browse/LOG4J2-537
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-beta9
> Environment: jdk1.6.0_45 64bit
>Reporter: moonumi
>Assignee: Remko Popma
> Labels: patch
>
> The helloworld program below does not end. (Process keeps running.)
> configuration:
> {code}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> source
> {code}
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class HelloWorld {
> private static Logger logger = LogManager.getLogger();
> public static void main(String[] args) {
> logger.info("Hello, World!");
> }
> }
> {code}
> libs:
> disruptor-3.2.0.jar
> log4j-api-beta9.jar
> log4j-core-beta9.jar
> delete file appender and change [AppenderRef ref="Console"] in [Root] work
> fine.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-566) Configure RollingRandomAccessFileAppender buffer size
[ https://issues.apache.org/jira/browse/LOG4J2-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma resolved LOG4J2-566. Resolution: Fixed Fixed in revision 1592539. Please verify and close. > Configure RollingRandomAccessFileAppender buffer size > - > > Key: LOG4J2-566 > URL: https://issues.apache.org/jira/browse/LOG4J2-566 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.0-rc1 >Reporter: Remko Popma >Assignee: Remko Popma > Fix For: 2.0-rc2 > > Attachments: LOG4J2-566.patch, RollingRandomAccessFile.zip > > > Make buffer size of RollingRandomAccessFileAppender configurable similar to > what was done for RandomAccessFileAppender in LOG4J2-402. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-628) Cannot set log4j.Clock with Async appender
[
https://issues.apache.org/jira/browse/LOG4J2-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13990093#comment-13990093
]
Remko Popma commented on LOG4J2-628:
Bryan, good to hear that.
About the error, we are currently refactoring the code base to move web stuff
into a separate module (and separate jar).
Apparently there are still issues with that.
> Cannot set log4j.Clock with Async appender
> --
>
> Key: LOG4J2-628
> URL: https://issues.apache.org/jira/browse/LOG4J2-628
> Project: Log4j 2
> Issue Type: Question
> Components: Appenders
>Affects Versions: 2.0-rc1
> Environment: Ubuntu 12.04 / Java 7
>Reporter: Bryan Hsueh
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
>
> I override log4j.Clock to support a "live" time vs a "simulated" time.
> System.setProperty("log4j.Clock", "teambh.trade.utils.MyClock");
> If I use asynchronous loggers, it works fine and calls my
> Clock:currentTimeMillis().
> If I switch to async appenders, currentTimeMillis() is not called.
> Is this expected behavior or a bug?
> Thanks
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-520) RollingRandomAccessFile with Async Appender skip logs
[
https://issues.apache.org/jira/browse/LOG4J2-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13990486#comment-13990486
]
Remko Popma commented on LOG4J2-520:
Thanks for the confirmation!
> RollingRandomAccessFile with Async Appender skip logs
> -
>
> Key: LOG4J2-520
> URL: https://issues.apache.org/jira/browse/LOG4J2-520
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.0-beta9, 2.0-rc1
> Environment: JDK 1.6, Eclipse
>Reporter: JavaTech
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
> Attachments: log4j2.xml
>
>
> I have written a sample code which will write DEBUG, INFO , WARN logs in a
> single flile, I have written a logs in FOR loop printing numbers from 1 to 99.
> sometime it print numbers incomplete sequence, like 1 to 67, 1 to 89 etc.
> log4j2.xml
> {code:xml}
>
>
>
>fileName="logs/app.log"
> filePattern="logs/$${date:-MM}/app-%d{MM-dd-}-%i.log"
> immediateFlush="false" append="true" ignoreExceptions="false">
>
> %d %-5p [%t] (%F:%L) - %m%n
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Sample Java Code
> {code}
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> public class LoggerUtil {
> public static Logger logger = LoggerFactory.getLogger(LoggerUtil.class);
> public static void main(String[] args) {
> System.out.println("start");
> logger.debug("debug log");
> logger.info("info log");
> logger.error("error log");
> for(int i = 0; i < 99; i++) {
> logger.warn("{}",i);
> System.out.println("I : - " + i);
> }
> logger.error("finish printing logs");
> System.out.println("end");
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-392) Intermittent errors with appenders
[ https://issues.apache.org/jira/browse/LOG4J2-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13990484#comment-13990484 ] Remko Popma commented on LOG4J2-392: Great, thanks for the confirmation. Get well soon! > Intermittent errors with appenders > -- > > Key: LOG4J2-392 > URL: https://issues.apache.org/jira/browse/LOG4J2-392 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.0-beta8, 2.0-beta9 > Environment: Windows 7 SP1 64bit >Reporter: ilynaf >Assignee: Remko Popma > Fix For: 2.0-rc2, 2.1 > > Attachments: AppenderOverwhelmer.java, Log4J2.zip, log4j2.xml > > > I intermittently receive following errors after upgrading to beta 8. > EVERYTHING was working well with beta 6: > * 1st error (happens most frequently) > 2013-09-05 10:48:37,722 ERROR Attempted to append to non-started appender > LogFile > * 2nd error: > 2013-09-05 10:49:38,268 ERROR Attempted to append to non-started appender > LogFile > 2013-09-05 10:49:38,268 ERROR Unable to write to stream > log/ui-selenium-tests.log for appender LogFile > 2013-09-05 10:49:38,269 ERROR An exception occurred processing Appender > LogFile org.apache.logging.log4j.core.appender.AppenderRuntimeException: > Error writing to RandomAccessFile log/ui-selenium-tests.log > at > org.apache.logging.log4j.core.appender.rolling.FastRollingFileManager.flush(FastRollingFileManager.java:108) > at > org.apache.logging.log4j.core.appender.rolling.FastRollingFileManager.write(FastRollingFileManager.java:89) > at > org.apache.logging.log4j.core.appender.OutputStreamManager.write(OutputStreamManager.java:129) > at > org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:115) > at > org.apache.logging.log4j.core.appender.FastRollingFileAppender.append(FastRollingFileAppender.java:97) > at > org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:102) > at > org.apache.logging.log4j.core.appender.AsyncAppender$AsyncThread.run(AsyncAppender.java:228) > Caused by: java.io.IOException: Write error > at java.io.RandomAccessFile.writeBytes(Native Method) > at java.io.RandomAccessFile.write(Unknown Source) > at > org.apache.logging.log4j.core.appender.rolling.FastRollingFileManager.flush(FastRollingFileManager.java:105) > ... 6 more -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-628) Cannot set log4j.Clock with Async appender
[
https://issues.apache.org/jira/browse/LOG4J2-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13990631#comment-13990631
]
Remko Popma commented on LOG4J2-628:
Bryan, SocketServer has been refactored and renamed to AbstractSocketServer in
the same (core.net) package.
The error message you mention has been modified to an info-level message
yesterday. If you check out trunk again the error should go away.
> Cannot set log4j.Clock with Async appender
> --
>
> Key: LOG4J2-628
> URL: https://issues.apache.org/jira/browse/LOG4J2-628
> Project: Log4j 2
> Issue Type: Question
> Components: Appenders
>Affects Versions: 2.0-rc1
> Environment: Ubuntu 12.04 / Java 7
>Reporter: Bryan Hsueh
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
>
> I override log4j.Clock to support a "live" time vs a "simulated" time.
> System.setProperty("log4j.Clock", "teambh.trade.utils.MyClock");
> If I use asynchronous loggers, it works fine and calls my
> Clock:currentTimeMillis().
> If I switch to async appenders, currentTimeMillis() is not called.
> Is this expected behavior or a bug?
> Thanks
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-631) Cannot use formatter logger and standard logger with same name
[
https://issues.apache.org/jira/browse/LOG4J2-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13994468#comment-13994468
]
Remko Popma commented on LOG4J2-631:
Alexandre, are you aware of this option: you can get a standard logger (with
the standard MessageFactory), but for the occasional log statement where you
want to use a formatter message format, you can call one of the
{{Logger.printf}} methods.
For example:
{code}
Logger logger = LogManager.getLogger(MyClass.class);
logger.info("My {} parameterized message", "standard");
logger.printf(Level.INFO, "Special formatting: int maxval=%+,d, pi=%10.3f",
Integer.MAX_VALUE, Math.PI);
{code}
> Cannot use formatter logger and standard logger with same name
> --
>
> Key: LOG4J2-631
> URL: https://issues.apache.org/jira/browse/LOG4J2-631
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.0-rc1
>Reporter: Alexandre Gattiker
>
> {code}
> public class Example {
> private final static Logger FORMATTER_LOGGER =
> LogManager.getFormatterLogger(Example.class);
> private final static Logger LOGGER =
> LogManager.getLogger(Example.class);
> public static void main(String[] args) {
> LOGGER.log(ERROR, "{} happened", "Something");
> FORMATTER_LOGGER.log(ERROR, "%s happened", "Something");
> }
> }
> {code}
> {noformat}
> 13:40:35.401 [main] ERROR com.example.Example - {} happened
> 13:40:35.404 [main] ERROR com.example.Example - Something happened
> {noformat}
> After inverting the two constant declarations:
> {noformat}
> 13:41:13.730 [main] ERROR com.example.Example - Something happened
> 13:41:13.732 [main] ERROR com.example.Example - %s happened
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-636) IOException: Stream Closed RollingRandomAccessFile
[ https://issues.apache.org/jira/browse/LOG4J2-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13998855#comment-13998855 ] Remko Popma commented on LOG4J2-636: Could you post your full configuration? Also, does the application just use the Logger interface (the debug(), info(), warn() etc methods) or does it do anything more complex? > IOException: Stream Closed RollingRandomAccessFile > -- > > Key: LOG4J2-636 > URL: https://issues.apache.org/jira/browse/LOG4J2-636 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.0-rc1 > Environment: Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 > GNU/Linux >Reporter: Adrian Wilford > > After some time, RollingRandomAccessFile can no longer write logging events > (have not run out of disk space). > 2014-05-13 10:05:18,284 ERROR Unable to write to stream logs/CALEEBaskets.log > for appender RollingRandomAccessFile > 2014-05-13 10:05:18,284 ERROR An exception occurred processing Appender > RollingRandomAccessFile > org.apache.logging.log4j.core.appender.AppenderLoggingException: Error > writing to RandomAccessFile logs/CALEEBaskets.log > at > org.apache.logging.log4j.core.appender.rolling.RollingRandomAccessFileManager.flush(RollingRandomAccessFileManager.java:109) > at > org.apache.logging.log4j.core.appender.rolling.RollingRandomAccessFileManager.write(RollingRandomAccessFileManager.java:90) > at > org.apache.logging.log4j.core.appender.OutputStreamManager.write(OutputStreamManager.java:129) > at > org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:120) > at > org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender.append(RollingRandomAccessFileAppender.java:96) > at > org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:97) > at > org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:425) > at > org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:406) > at > org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:367) > at org.apache.logging.log4j.core.Logger.log(Logger.java:112) > at > org.apache.logging.log4j.spi.AbstractLogger.debug(AbstractLogger.java:338) > at > com.corticalSystems.CALEE.algorithms.baskets.persistence.orderLogging.OrderLoggingDAL.createNewOrder(OrderLoggingDAL.java:163) > at > com.corticalSystems.CALEE.algorithms.baskets.logic.ConstituentLogicThread.sendNewOrder(ConstituentLogicThread.java:1087) > at > com.corticalSystems.CALEE.algorithms.baskets.logic.ConstituentLogicThread.run(ConstituentLogicThread.java:1587) > at java.lang.Thread.run(Thread.java:744) > Caused by: java.io.IOException: Stream Closed > at java.io.RandomAccessFile.writeBytes0(Native Method) > at java.io.RandomAccessFile.writeBytes(RandomAccessFile.java:520) > at java.io.RandomAccessFile.write(RandomAccessFile.java:550) > at > org.apache.logging.log4j.core.appender.rolling.RollingRandomAccessFileManager.flush(RollingRandomAccessFileManager.java:106) > ... 14 more -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
