[jira] [Created] (LOG4J2-2315) LevelRangeFilter min and max values are behaving opposit

2018-04-11 Thread JIGNESH S SHUKLA (JIRA) 
JIGNESH S SHUKLA created LOG4J2-2315:


 Summary: LevelRangeFilter min and max values are behaving opposit
 Key: LOG4J2-2315
 URL: https://issues.apache.org/jira/browse/LOG4J2-2315
 Project: Log4j 2
  Issue Type: Bug
  Components: Filters
Affects Versions: 2.10.0
Reporter: JIGNESH S SHUKLA


LevelRangeFilter's minLevel and maxLevel are behaving opposite then it's 
previous (log4j 1.2.X) versions. 

For example, if you set minLevel=DEBUG and maxLevel=INFO, I would expect both 
DEBUG and INFO logs should be in the targeted output and all the other levels 
should be filtered. That's how it used to work in log4j 1.2.x version). 

However, in log4j2, it doesn't really output anything (i.e. it filters out all 
the levels). If you swap the value of minLevel and maxLevel then (i.e. 
minLevel=INFO and maxLevel=DEBUG),  it works as expected. This is very 
confusing. 

Looking at the documentation and code, I think this is happening due to 
following:
 # In Log4j 1.x, the priority value of levels were in ascending order. It means 
INFO will have higher value than DEBUG.  However, in  log4j2.x, the concept is 
different. There is an associated intValue with each level and according to 
documentation, intValues are in descending order. it means DEBUG's intValue 
(500) is higher than INFO's (400). 

2. With this change of priority/intValues from ascending to descending, 
following logic in Level.java never returns true for a minLevel=DEBUG and 
maxLevel=INFO in Log4j2. 

 *public boolean isInRange(final Level minLevel, final Level maxLevel) {*
 *{color:#d04437}return this.intLevel >= minLevel.intLevel && this.intLevel <= 
maxLevel.intLevel;{color}*
 *}*

I think this needs to be corrected as the meaning of minLevel and maxLevel are 
very intuitive and current implement is totally opposite of it and makes it 
very confusing. 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Work started] (LOG4J2-2301) gc-free mixed async loging loses parameter values after the first appender

2018-04-11 Thread Carter Kozak (JIRA) 

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

Work on LOG4J2-2301 started by Carter Kozak.

> gc-free mixed async loging loses parameter values after the first appender
> --
>
> Key: LOG4J2-2301
> URL: https://issues.apache.org/jira/browse/LOG4J2-2301
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.11.0
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
>
> When gc-free logging is used with mixed synchronous/asynchronous loggers, 
> parameter values are replaced with "null" after the first AsyncLoggerConfig.
> The message format is still present, as well as the parameter count, however 
> all values are nulls.
> It appears that Log4jEventWrapperHandler.onEvent invokes 
> MutableLogEvent.clear, which nulls out the parameter array.
> I have constructed a failing test (which I need to clean up and deduplicate 
> some code from the fix for LOG4J2-2299):
> https://github.com/cakofony/logging-log4j2/commit/b9c03f5c6881bfe778f8e2d75d046ce6e021c4f1



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2301) gc-free mixed async loging loses parameter values after the first appender

2018-04-11 Thread Carter Kozak (JIRA) 

[ 
https://issues.apache.org/jira/browse/LOG4J2-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434795#comment-16434795
 ] 

Carter Kozak commented on LOG4J2-2301:
--

Alright, I've refactored AsyncLoggerConfig and managed to get the test passing. 
I'd really appreciate review when you have time [~rem...@yahoo.com]!

I've pushed the change to github for ease of sharing: 
[https://github.com/apache/logging-log4j2/pull/164]

> gc-free mixed async loging loses parameter values after the first appender
> --
>
> Key: LOG4J2-2301
> URL: https://issues.apache.org/jira/browse/LOG4J2-2301
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.11.0
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
>
> When gc-free logging is used with mixed synchronous/asynchronous loggers, 
> parameter values are replaced with "null" after the first AsyncLoggerConfig.
> The message format is still present, as well as the parameter count, however 
> all values are nulls.
> It appears that Log4jEventWrapperHandler.onEvent invokes 
> MutableLogEvent.clear, which nulls out the parameter array.
> I have constructed a failing test (which I need to clean up and deduplicate 
> some code from the fix for LOG4J2-2299):
> https://github.com/cakofony/logging-log4j2/commit/b9c03f5c6881bfe778f8e2d75d046ce6e021c4f1



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2299) Using "asyncLogger" with AsyncLoggerContextSelector loses some event data

2018-04-11 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LOG4J2-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434787#comment-16434787
 ] 

ASF GitHub Bot commented on LOG4J2-2299:


GitHub user cakofony opened a pull request:

https://github.com/apache/logging-log4j2/pull/164

[LOG4J2-2299] Mixed async loggers no longer forget parameter values

Previously each AsyncLoggerConfig would individually enqueue an
event on the async delegate disruptor. In practice this caused
us to trade reusable message parameters away at the first
AsyncLoggerConfig in our path, causing the rest to get an array
of nulls.

Now we begin by traversing the configuration and logging to all
synchronous loggers first, then enqueue the event to the highest
level asynchronous logger allowing the asynchronous loggers to be
traversed on the background thread.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cakofony/logging-log4j2 LOG4J2-2301

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/logging-log4j2/pull/164.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #164


commit eefef2b841710efa4651e448f0e4a9ff1b54ac3d
Author: Carter Kozak 
Date:   2018-04-11T22:53:01Z

[LOG4J2-2299] Mixed async loggers no longer forget parameter values

Previously each AsyncLoggerConfig would individually enqueue an
event on the async delegate disruptor. In practice this caused
us to trade reusable message parameters away at the first
AsyncLoggerConfig in our path, causing the rest to get an array
of nulls.

Now we begin by traversing the configuration and logging to all
synchronous loggers first, then enqueue the event to the highest
level asynchronous logger allowing the asynchronous loggers to be
traversed on the background thread.




> Using "asyncLogger" with AsyncLoggerContextSelector loses some event data
> -
>
> Key: LOG4J2-2299
> URL: https://issues.apache.org/jira/browse/LOG4J2-2299
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.11.0
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 3.0.0
>
>
> Using mixed style "asyncLogger" definitions when AsyncLoggerContextSelector 
> is selected and reusable messages are enabled causes parameterized message 
> data to be lost (Guessing we memento the message handing it off between 
> disruptors).
> Proposal:
> Would it be objectionable to parse AsyncLoggerConfigs as standard 
> LoggerConfig when global async mode is enabled?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] logging-log4j2 pull request #164: [LOG4J2-2299] Mixed async loggers no longe...

2018-04-11 Thread cakofony 
GitHub user cakofony opened a pull request:

https://github.com/apache/logging-log4j2/pull/164

[LOG4J2-2299] Mixed async loggers no longer forget parameter values

Previously each AsyncLoggerConfig would individually enqueue an
event on the async delegate disruptor. In practice this caused
us to trade reusable message parameters away at the first
AsyncLoggerConfig in our path, causing the rest to get an array
of nulls.

Now we begin by traversing the configuration and logging to all
synchronous loggers first, then enqueue the event to the highest
level asynchronous logger allowing the asynchronous loggers to be
traversed on the background thread.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cakofony/logging-log4j2 LOG4J2-2301

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/logging-log4j2/pull/164.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #164


commit eefef2b841710efa4651e448f0e4a9ff1b54ac3d
Author: Carter Kozak 
Date:   2018-04-11T22:53:01Z

[LOG4J2-2299] Mixed async loggers no longer forget parameter values

Previously each AsyncLoggerConfig would individually enqueue an
event on the async delegate disruptor. In practice this caused
us to trade reusable message parameters away at the first
AsyncLoggerConfig in our path, causing the rest to get an array
of nulls.

Now we begin by traversing the configuration and logging to all
synchronous loggers first, then enqueue the event to the highest
level asynchronous logger allowing the asynchronous loggers to be
traversed on the background thread.




---