[GitHub] logging-log4j2 issue #163: Add KeyValueLayout which outputs log messages as ...

[rgoers]

Github user rgoers commented on the issue:

https://github.com/apache/logging-log4j2/pull/163
  
Is there a Jira issue for this?


---

[jira] [Commented] (LOG4J2-2321) AsyncLogger without specifying a level always uses ERROR

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-2321:
-

Is this a bug fix or an enhancement? If it is a bug fix it should also be 
applied to the release-2.x branch.

> AsyncLogger without specifying a level always uses ERROR
> 
>
> Key: LOG4J2-2321
> URL: https://issues.apache.org/jira/browse/LOG4J2-2321
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Configurators
>Affects Versions: 2.11.0
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 3.0.0
>
>
> An AsyncLogger definitions without a level defined always have "ERROR" level 
> set, where Logger definitions defer to the parent config, error is only set 
> for the root logger.
> For example:
> {noformat}
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> {noformat}
> Logger "com.foo" level should be trace, inherited from the root logger, 
> however it will currently be error.
> The same config using "Logger" and "Root" rather than their asynchronous 
> counterparts will produce the expected behavior.
>  



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

[jira] [Commented] (LOG4J2-2318) AsyncQueueFullMessageUtil causes unparsable message output

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-2318:
-

Is this a bug fix or an enhancement? If it is a bug fix it should also be 
applied to the release-2.x branch.

> AsyncQueueFullMessageUtil causes unparsable message output
> --
>
> Key: LOG4J2-2318
> URL: https://issues.apache.org/jira/browse/LOG4J2-2318
> 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
>
>
> AsyncQueueFullMessageUtil.transform modifies message format, dropping message 
> format and parameters, and concatenates text to the formatted output.
> It's a fairly common workflow to write a message implementation which outputs 
> json or some other structured data (e.g. request logs) which are parsed by 
> another mechanism. This often uses PatternLayout with pattern "%m%n". The 
> current implementation of AsyncQueueFullMessageUtil concatenates a warning to 
> the formatted message, which can break parsers.
> Proposal: Avoid modifying the message itself in favor of using 
> StatusLogger.warn when messages may be logged out of order.



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

[jira] [Commented] (LOG4J2-2317) getNonNullImmutableMessage should retain format and parameters

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-2317:
-

Is this a bug fix or an enhancement? If it is an bug fix it should be applied 
to the release-2.x branch.

> getNonNullImmutableMessage should retain format and parameters
> --
>
> Key: LOG4J2-2317
> URL: https://issues.apache.org/jira/browse/LOG4J2-2317
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.11.0
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
>
> This works properly in RingBufferLogEvent, but not MutableLogEvent or 
> Log4jLogEvent, which create a SimpleMessage.



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

[jira] [Assigned] (LOG4J2-2314) SortedArrayStringMap does allow only filterable ObjectInputStreams

[Ralph Goers (JIRA)]

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

Ralph Goers reassigned LOG4J2-2314:
---

Assignee: Ralph Goers

> SortedArrayStringMap does allow only filterable ObjectInputStreams
> --
>
> Key: LOG4J2-2314
> URL: https://issues.apache.org/jira/browse/LOG4J2-2314
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.11.0
> Environment: * JAVA 8 1.8.0_151
>  * Hibernate 5.2.16 (JPA 2.1)
>  * Log4j2-core 2.11.0
>  * Log4j2-jpa 2.11.0
>Reporter: Sebastian Poxhofer
>Assignee: Ralph Goers
>Priority: Major
>  Labels: newbie
> Attachments: log4j2.xml, persistence.xml, stacktrace.txt
>
>
> When using the JPA Appender it is not anymore possible to use Hibernate.
> During the write process on the appender log4j2 detects a incompatible 
> instance of ObjectInputStream.
>  
> The root of the problem seems to be this change.
> [https://github.com/apache/logging-log4j2/commit/ce7d3fb6d2b20cea0b43db3e9ca3eb286699ca8c#diff-8cb9cfc9b0a2fb37c17778fb0b846ce1L581]
>  
> A full stack trace and config files can be found in the attachments.



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

[jira] [Commented] (LOG4J2-2322) Custom Async ContextSelectors should disable location by default

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-2322:
-

Is this a bug fix or an enhancement? If it is a bug fix it should also be 
applied to the release-2.x branch.

> Custom Async ContextSelectors should disable location by default
> 
>
> Key: LOG4J2-2322
> URL: https://issues.apache.org/jira/browse/LOG4J2-2322
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 3.0.0
>
>
> When AsyncLoggerContextSelector is selected, we modify the default value of 
> LoggerConfig.includeLocation from true to false.
> Custom asynchronous ContextSelector implementations should also trigger this 
> logic to avoid unnecessarily work.



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

[jira] [Commented] (LOG4J2-2269) Memory leaking of replacement parameters in case of enableThreadlocals=true

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-2269:
-

Is there a reason the fix wasn't merged to the release-2.x branch?

> Memory leaking of replacement parameters in case of enableThreadlocals=true
> ---
>
> Key: LOG4J2-2269
> URL: https://issues.apache.org/jira/browse/LOG4J2-2269
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Reporter: Dmitry Konstantinov
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: heap_dump_references.png, 
> heap_dump_threadLocals_false.hprof.zip, 
> heap_dump_threadLocals_true.hprof.zip, test_to_reproduce.zip
>
>
> Use case:
> 1) I have a thread pool with quite large number of threads (around 100)
> 2) Threads from the pool sometimes process some heavy objects. Threads are 
> not actively writing into logs (so, a thread may process a task and does not 
> log any message).
> 3) As a part of processing for some objects in some non-frequently used 
> branch a thread logged a message with heavy replacement parameters 
> (parameterized log message is used).
> In this case such heavy replacement parameters are not garbage collected 
> until another message will not written within the same thread because 
> thread-local ReusableParameterizedMessage and MutableLogEvent objects keep 
> references to the replacement parameters.
> Is it possible to cleanup such references when a message is released (for 
> example as a part of 
> org.apache.logging.log4j.message.ReusableMessageFactory#release and 
> org.apache.logging.log4j.core.impl.ReusableLogEventFactory#release) to avoid 
> such kind of leaks?



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

Jenkins build is unstable: Log4j 2 3.x #73

[Apache Jenkins Server]

See 

[jira] [Resolved] (LOG4J2-2269) Memory leaking of replacement parameters in case of enableThreadlocals=true

[Carter Kozak (JIRA)]

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

Carter Kozak resolved LOG4J2-2269.
--
   Resolution: Fixed
Fix Version/s: 3.0.0

Fix has merged, [~dnk] would you like to verify and close out this ticket?

 

Thanks!

> Memory leaking of replacement parameters in case of enableThreadlocals=true
> ---
>
> Key: LOG4J2-2269
> URL: https://issues.apache.org/jira/browse/LOG4J2-2269
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Reporter: Dmitry Konstantinov
>Assignee: Remko Popma
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: heap_dump_references.png, 
> heap_dump_threadLocals_false.hprof.zip, 
> heap_dump_threadLocals_true.hprof.zip, test_to_reproduce.zip
>
>
> Use case:
> 1) I have a thread pool with quite large number of threads (around 100)
> 2) Threads from the pool sometimes process some heavy objects. Threads are 
> not actively writing into logs (so, a thread may process a task and does not 
> log any message).
> 3) As a part of processing for some objects in some non-frequently used 
> branch a thread logged a message with heavy replacement parameters 
> (parameterized log message is used).
> In this case such heavy replacement parameters are not garbage collected 
> until another message will not written within the same thread because 
> thread-local ReusableParameterizedMessage and MutableLogEvent objects keep 
> references to the replacement parameters.
> Is it possible to cleanup such references when a message is released (for 
> example as a part of 
> org.apache.logging.log4j.message.ReusableMessageFactory#release and 
> org.apache.logging.log4j.core.impl.ReusableLogEventFactory#release) to avoid 
> such kind of leaks?



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

[jira] [Commented] (LOG4J2-2269) Memory leaking of replacement parameters in case of enableThreadlocals=true

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2269:


Github user cakofony closed the pull request at:

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


> Memory leaking of replacement parameters in case of enableThreadlocals=true
> ---
>
> Key: LOG4J2-2269
> URL: https://issues.apache.org/jira/browse/LOG4J2-2269
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Reporter: Dmitry Konstantinov
>Assignee: Remko Popma
>Priority: Major
> Attachments: heap_dump_references.png, 
> heap_dump_threadLocals_false.hprof.zip, 
> heap_dump_threadLocals_true.hprof.zip, test_to_reproduce.zip
>
>
> Use case:
> 1) I have a thread pool with quite large number of threads (around 100)
> 2) Threads from the pool sometimes process some heavy objects. Threads are 
> not actively writing into logs (so, a thread may process a task and does not 
> log any message).
> 3) As a part of processing for some objects in some non-frequently used 
> branch a thread logged a message with heavy replacement parameters 
> (parameterized log message is used).
> In this case such heavy replacement parameters are not garbage collected 
> until another message will not written within the same thread because 
> thread-local ReusableParameterizedMessage and MutableLogEvent objects keep 
> references to the replacement parameters.
> Is it possible to cleanup such references when a message is released (for 
> example as a part of 
> org.apache.logging.log4j.message.ReusableMessageFactory#release and 
> org.apache.logging.log4j.core.impl.ReusableLogEventFactory#release) to avoid 
> such kind of leaks?



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

[jira] [Commented] (LOG4J2-2269) Memory leaking of replacement parameters in case of enableThreadlocals=true

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2269:


Github user cakofony commented on the issue:

https://github.com/apache/logging-log4j2/pull/165
  
merged


> Memory leaking of replacement parameters in case of enableThreadlocals=true
> ---
>
> Key: LOG4J2-2269
> URL: https://issues.apache.org/jira/browse/LOG4J2-2269
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Reporter: Dmitry Konstantinov
>Assignee: Remko Popma
>Priority: Major
> Attachments: heap_dump_references.png, 
> heap_dump_threadLocals_false.hprof.zip, 
> heap_dump_threadLocals_true.hprof.zip, test_to_reproduce.zip
>
>
> Use case:
> 1) I have a thread pool with quite large number of threads (around 100)
> 2) Threads from the pool sometimes process some heavy objects. Threads are 
> not actively writing into logs (so, a thread may process a task and does not 
> log any message).
> 3) As a part of processing for some objects in some non-frequently used 
> branch a thread logged a message with heavy replacement parameters 
> (parameterized log message is used).
> In this case such heavy replacement parameters are not garbage collected 
> until another message will not written within the same thread because 
> thread-local ReusableParameterizedMessage and MutableLogEvent objects keep 
> references to the replacement parameters.
> Is it possible to cleanup such references when a message is released (for 
> example as a part of 
> org.apache.logging.log4j.message.ReusableMessageFactory#release and 
> org.apache.logging.log4j.core.impl.ReusableLogEventFactory#release) to avoid 
> such kind of leaks?



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

[GitHub] logging-log4j2 pull request #165: LOG4J2-2269: ReusableLogEventFactory.relea...

[cakofony]

Github user cakofony closed the pull request at:

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


---

[jira] [Commented] (LOG4J2-2269) Memory leaking of replacement parameters in case of enableThreadlocals=true

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LOG4J2-2269:
-

Commit b28496e325663f770bc0889d7f5ed2e07505851d in logging-log4j2's branch 
refs/heads/master from [~ckozak]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=b28496e ]

LOG4J2-2269: ReusableLogEventFactory.release clears MutableLogEvent

Fixes a memory leak where parameter references were held beyond
MutableLogEvent usage.


> Memory leaking of replacement parameters in case of enableThreadlocals=true
> ---
>
> Key: LOG4J2-2269
> URL: https://issues.apache.org/jira/browse/LOG4J2-2269
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Reporter: Dmitry Konstantinov
>Assignee: Remko Popma
>Priority: Major
> Attachments: heap_dump_references.png, 
> heap_dump_threadLocals_false.hprof.zip, 
> heap_dump_threadLocals_true.hprof.zip, test_to_reproduce.zip
>
>
> Use case:
> 1) I have a thread pool with quite large number of threads (around 100)
> 2) Threads from the pool sometimes process some heavy objects. Threads are 
> not actively writing into logs (so, a thread may process a task and does not 
> log any message).
> 3) As a part of processing for some objects in some non-frequently used 
> branch a thread logged a message with heavy replacement parameters 
> (parameterized log message is used).
> In this case such heavy replacement parameters are not garbage collected 
> until another message will not written within the same thread because 
> thread-local ReusableParameterizedMessage and MutableLogEvent objects keep 
> references to the replacement parameters.
> Is it possible to cleanup such references when a message is released (for 
> example as a part of 
> org.apache.logging.log4j.message.ReusableMessageFactory#release and 
> org.apache.logging.log4j.core.impl.ReusableLogEventFactory#release) to avoid 
> such kind of leaks?



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

[jira] [Commented] (LOG4J2-1705) Kotlin wrapper for Log4j 2 API

[Matt Sicker (JIRA)]

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

Matt Sicker commented on LOG4J2-1705:
-

I'm always posting on the dev list ;)

I'll start the vote thread once we can successfully build the site and I can 
put together a release candidate from it.

> Kotlin wrapper for Log4j 2 API
> --
>
> Key: LOG4J2-1705
> URL: https://issues.apache.org/jira/browse/LOG4J2-1705
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: API
>Reporter: Raman Gupta
>Assignee: Matt Sicker
>Priority: Major
>
> Similar to LOG4J2-1181 for Scala, provide a Kotlin wrapper for the Log4j 2 
> API that makes use of Kotlin features like delegates and string interpolation.
> If there is interest in this, I'd like to contribute a patch.



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

[jira] [Commented] (LOG4J2-1705) Kotlin wrapper for Log4j 2 API

[Raman Gupta (JIRA)]

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

Raman Gupta commented on LOG4J2-1705:
-

[~jvz] README pull request created. I have no idea why the site generation is 
not working. I've signed up on the dev mailing list. Will you be posting there, 
or shall I?

> Kotlin wrapper for Log4j 2 API
> --
>
> Key: LOG4J2-1705
> URL: https://issues.apache.org/jira/browse/LOG4J2-1705
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: API
>Reporter: Raman Gupta
>Assignee: Matt Sicker
>Priority: Major
>
> Similar to LOG4J2-1181 for Scala, provide a Kotlin wrapper for the Log4j 2 
> API that makes use of Kotlin features like delegates and string interpolation.
> If there is interest in this, I'd like to contribute a patch.



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