[jira] [Updated] (LOG4J2-1523) Log4j 1 appenders

[Gary Gregory (JIRA)]

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

Gary Gregory updated LOG4J2-1523:
-
Description: 
Support all appenders in Log4j 1 to the extent possible and reasonable.

All appenders in Log4j 1:
* AsyncAppender
* RewriteAppender
(/) NullAppender
(/) ConsoleAppender
(/) FileAppender
(/) RollingFileAppender Classic (org.apache.log4j.RollingFileAppender)
* RollingFileAppender Extras (org.apache.log4j.rolling RollingFileAppender)
* DailyRollingFileAppender
* ExternallyRolledFileAppender
* JDBCAppender
* JMSAppender
* SMTPAppender
* SocketAppender
* SocketHubAppender
* SyslogAppender
* TelnetAppender
(-) NTEventLogAppender
(-) WriterAppender
(-) VectorAppender
(-) LF5Appender


  was:
Support all appenders in Log4j 1 to the extent possible and reasonable.

All appenders in Log4j 1:
* AsyncAppender
* RewriteAppender
(/) NullAppender
(/) ConsoleAppender
(/) FileAppender
* RollingFileAppender
* DailyRollingFileAppender
* ExternallyRolledFileAppender
* JDBCAppender
* JMSAppender
* SMTPAppender
* SocketAppender
* SocketHubAppender
* SyslogAppender
* TelnetAppender
(-) NTEventLogAppender
(-) WriterAppender
(-) VectorAppender
(-) LF5Appender



> Log4j 1 appenders
> -
>
> Key: LOG4J2-1523
> URL: https://issues.apache.org/jira/browse/LOG4J2-1523
> Project: Log4j 2
>  Issue Type: Sub-task
>  Components: Appenders
>Reporter: Mikael Ståldal
>Assignee: Mikael Ståldal
>
> Support all appenders in Log4j 1 to the extent possible and reasonable.
> All appenders in Log4j 1:
> * AsyncAppender
> * RewriteAppender
> (/) NullAppender
> (/) ConsoleAppender
> (/) FileAppender
> (/) RollingFileAppender Classic (org.apache.log4j.RollingFileAppender)
> * RollingFileAppender Extras (org.apache.log4j.rolling RollingFileAppender)
> * DailyRollingFileAppender
> * ExternallyRolledFileAppender
> * JDBCAppender
> * JMSAppender
> * SMTPAppender
> * SocketAppender
> * SocketHubAppender
> * SyslogAppender
> * TelnetAppender
> (-) NTEventLogAppender
> (-) WriterAppender
> (-) VectorAppender
> (-) LF5Appender



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: ThreadContextMapFilter performance

[Remko Popma]

This issue should be resolved now. 

Sent from my iPhone

> On 2016/09/20, at 15:33, Ralph Goers  wrote:
> 
> I started the release process tonight but stopped it when I noticed that the 
> FilterPerformanceComparison test is now taking over 200 seconds to complete. 
> Where it used to be faster than Logback it is now from 3 to 60 times slower 
> depending on the number of threads.  I am assuming this is due to the changes 
> to add support for the ThreadContextInjector.  If this cannot be addressed 
> then I am going to have to ask that this feature be removed.
> 
> In the meantime a 2.7 release is on hold.
> 
> Ralph
> 
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
> 

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

[jira] [Updated] (LOG4J2-1523) Log4j 1 appenders

[Gary Gregory (JIRA)]

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

Gary Gregory updated LOG4J2-1523:
-
Description: 
Support all appenders in Log4j 1 to the extent possible and reasonable.

All appenders in Log4j 1:
* AsyncAppender
* RewriteAppender
(/) NullAppender
(/) ConsoleAppender
(/) FileAppender
* RollingFileAppender
* DailyRollingFileAppender
* ExternallyRolledFileAppender
* JDBCAppender
* JMSAppender
* SMTPAppender
* SocketAppender
* SocketHubAppender
* SyslogAppender
* TelnetAppender
(-) NTEventLogAppender
(-) WriterAppender
(-) VectorAppender
(-) LF5Appender


  was:
Support all appenders in Log4j 1 to the extent possible and reasonable.

All appenders in Log4j 1:
* AsyncAppender
* RewriteAppender
* NullAppender
(/) ConsoleAppender
(/) FileAppender
* RollingFileAppender
* DailyRollingFileAppender
* ExternallyRolledFileAppender
* JDBCAppender
* JMSAppender
* SMTPAppender
* SocketAppender
* SocketHubAppender
* SyslogAppender
* TelnetAppender
(-) NTEventLogAppender
(-) WriterAppender
(-) VectorAppender
(-) LF5Appender



> Log4j 1 appenders
> -
>
> Key: LOG4J2-1523
> URL: https://issues.apache.org/jira/browse/LOG4J2-1523
> Project: Log4j 2
>  Issue Type: Sub-task
>  Components: Appenders
>Reporter: Mikael Ståldal
>Assignee: Mikael Ståldal
>
> Support all appenders in Log4j 1 to the extent possible and reasonable.
> All appenders in Log4j 1:
> * AsyncAppender
> * RewriteAppender
> (/) NullAppender
> (/) ConsoleAppender
> (/) FileAppender
> * RollingFileAppender
> * DailyRollingFileAppender
> * ExternallyRolledFileAppender
> * JDBCAppender
> * JMSAppender
> * SMTPAppender
> * SocketAppender
> * SocketHubAppender
> * SyslogAppender
> * TelnetAppender
> (-) NTEventLogAppender
> (-) WriterAppender
> (-) VectorAppender
> (-) LF5Appender



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (LOG4J2-1010) Injectable context properties

[Remko Popma (JIRA)]

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

Remko Popma resolved LOG4J2-1010.
-
Resolution: Fixed

Fixed the issue by returning a constant empty map instead of creating a new 
empty instance for each call to {{getMutableContextData}}.

This brings performance in line with slf4j.

*Empty ThreadContext*
{noformat}
t=1
Benchmark  (size)Mode  
Samples   Score   Error  Units
o.a.l.l.p.j.MDCFilterBenchmark.log4jThreadContextFilter 0  sample
59275  46.046 ± 2.354  ns/op
o.a.l.l.p.j.MDCFilterBenchmark.slf4jMDCFilter   0  sample
74809  27.697 ± 1.562  ns/op

t=2
Benchmark  (size)Mode  
Samples   Score   Error  Units
o.a.l.l.p.j.MDCFilterBenchmark.log4jThreadContextFilter 0  sample   
144048  48.797 ± 1.444  ns/op
o.a.l.l.p.j.MDCFilterBenchmark.slf4jMDCFilter   0  sample   
115524  43.704 ± 1.527  ns/op

t=4
Benchmark  (size)Mode  
SamplesScore Error  Units
o.a.l.l.p.j.MDCFilterBenchmark.log4jThreadContextFilter 0  sample   
256148   69.658 ±   4.635  ns/op
o.a.l.l.p.j.MDCFilterBenchmark.slf4jMDCFilter   0  sample   
291767   60.737 ±   1.212  ns/op
{noformat}

*ThreadContext with 4 elements*
{noformat}
t=1
Benchmark  (size)Mode  
SamplesScore Error  Units
o.a.l.l.p.j.MDCFilterBenchmark.log4jThreadContextFilter 4  sample
81807  49.223 ± 1.992  ns/op
o.a.l.l.p.j.MDCFilterBenchmark.slf4jMDCFilter   4  sample
69460  86.525 ± 2.642  ns/op

t=2
Benchmark  (size)Mode  
SamplesScore Error  Units
o.a.l.l.p.j.MDCFilterBenchmark.log4jThreadContextFilter 4  sample   
103624  88.992 ± 2.531  ns/op
o.a.l.l.p.j.MDCFilterBenchmark.slf4jMDCFilter   4  sample   
108786  87.334 ± 2.152  ns/op

t=4
Benchmark  (size)Mode  
SamplesScore Error  Units
o.a.l.l.p.j.MDCFilterBenchmark.log4jThreadContextFilter 4  sample   
335807   91.768 ±   1.245  ns/op
o.a.l.l.p.j.MDCFilterBenchmark.slf4jMDCFilter   4  sample   
326588   94.174 ±   1.308  ns/op
{noformat}


> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> is not so useful since JVM threads might not be coupled to the logical flow 
> of the application.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LOG4J2-1522) Log4j 1 layouts

[Gary Gregory (JIRA)]

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

Gary Gregory updated LOG4J2-1522:
-
Description: 
Support all layouts in Log4j 1 to the extent possible an reasonable.

* {{PatternLayout}} and {{EnhancedPatternLayout}} are mapped to 
{{PatternLayout}}. We provide two new pattern conversions for the Log4j 1 
format of NDC and MDC.
* {{SimpleLayout}} is mapped to {{PatternLayout}} "%level - %m%n"
* {{TTCCLayout}} is mapped to {{PatternLayout}}
* {{HTMLLayout}} is mapped to {{HtmlLayout}} (will not look exactly the same, 
but close enough)
* {{XMLLayout}} is ported ({{XmlLayout}} in Log4j 2 is different and will not 
work)

  was:
Support all layouts in Log4j 1 to the extent possible an reasonable.

* PatternLayout and EnhancedPatternLayout are mapped to PatternLayout. We 
provide two new pattern conversions for the Log4j 1 format of NDC and MDC.
* SimpleLayout is mapped to PatternLayout "%level - %m%n"
* TTCCLayout is mapped to PatternLayout
* HTMLLayout is mapped to HtmlLayout (will not look exactly the same, but close 
enough)
* XMLLayout is ported (XmlLayout in Log4j 2 is different and will not work)


> Log4j 1 layouts
> ---
>
> Key: LOG4J2-1522
> URL: https://issues.apache.org/jira/browse/LOG4J2-1522
> Project: Log4j 2
>  Issue Type: Sub-task
>  Components: Layouts
>Reporter: Mikael Ståldal
>Assignee: Mikael Ståldal
> Fix For: 2.7
>
>
> Support all layouts in Log4j 1 to the extent possible an reasonable.
> * {{PatternLayout}} and {{EnhancedPatternLayout}} are mapped to 
> {{PatternLayout}}. We provide two new pattern conversions for the Log4j 1 
> format of NDC and MDC.
> * {{SimpleLayout}} is mapped to {{PatternLayout}} "%level - %m%n"
> * {{TTCCLayout}} is mapped to {{PatternLayout}}
> * {{HTMLLayout}} is mapped to {{HtmlLayout}} (will not look exactly the same, 
> but close enough)
> * {{XMLLayout}} is ported ({{XmlLayout}} in Log4j 2 is different and will not 
> work)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
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-1604) Log4j2 TcpSocketServer in background

[Gary Gregory (JIRA)]

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

Gary Gregory edited comment on LOG4J2-1604 at 9/22/16 12:50 AM:


[~colinh],

I've redone the servers so that they have a proper command line instead of the 
positional arguments at fixed indices.

The new way to use the servers is:

{noformat}
Usage: org.apache.logging.log4j.core.net.server.TcpSocketServer [options]
  Options:
--backlog, -b
   Server socket backlog.
   Default: 50
--config, -c
   Log4j configuration file location (path or URL).
--help, -?, -h
   Prints this help.
   Default: false
--interactive, -i
   Accepts commands on standard input ("exit" is the only command).
   Default: false
--localbindaddress, -a
   Server socket local bind address.
--port, -p
   Server socket port.
   Default: 0
{noformat}

and:

{noformat}
Usage: org.apache.logging.log4j.core.net.server.UdpSocketServer [options]
  Options:
--config, -c
   Configuration file location (path or URL).
--help, -?, -h
   Prints this help.
   Default: false
--interactive, -i
   Accepts commands on standard input ("exit" is the only command).
   Default: false
--localbindaddress, -a
   Socket server port. See 
http://docs.oracle.com/javase/7/docs/api/java/net/ServerSocket.html#ServerSocket(int,%20int)
--port, -p
   Socket server port. See 
http://docs.oracle.com/javase/7/docs/api/java/net/ServerSocket.html#ServerSocket(int,%20int)
   Default: 0
{noformat}

This requires the addition of JCommander on the classpath:

{noformat}
  
com.beust
jcommander
1.48
  
{noformat}

Please try with the latest 2.6.3-SNAPSHOT from 
https://repository.apache.org/content/repositories/snapshots/

If that works for you, please close this ticket.


was (Author: garydgregory):
[~colinh],

I've redone the servers so that they have a proper command line instead of the 
positional arguments at fixed indices.

The new way to use the servers is:

{noformat}
Usage: org.apache.logging.log4j.core.net.server.TcpSocketServer [options]
  Options:
--config, -c
   Configuration file location (path or URL).
--help, -?, -h
   Prints this help.
   Default: false
--interactive, -i
   Accepts commands on standard input ("exit" is the only command).
   Default: false
--localbindaddress, -a
   Socket server port. See 
http://docs.oracle.com/javase/7/docs/api/java/net/ServerSocket.html#ServerSocket(int,%20int)
--port, -p
   Socket server port. See 
http://docs.oracle.com/javase/7/docs/api/java/net/ServerSocket.html#ServerSocket(int,%20int)
   Default: 0
{noformat}

and:

{noformat}
Usage: org.apache.logging.log4j.core.net.server.UdpSocketServer [options]
  Options:
--config, -c
   Configuration file location (path or URL).
--help, -?, -h
   Prints this help.
   Default: false
--interactive, -i
   Accepts commands on standard input ("exit" is the only command).
   Default: false
--localbindaddress, -a
   Socket server port. See 
http://docs.oracle.com/javase/7/docs/api/java/net/ServerSocket.html#ServerSocket(int,%20int)
--port, -p
   Socket server port. See 
http://docs.oracle.com/javase/7/docs/api/java/net/ServerSocket.html#ServerSocket(int,%20int)
   Default: 0
{noformat}

This requires the addition of JCommander on the classpath:

{noformat}
  
com.beust
jcommander
1.48
  
{noformat}

Please try with the latest 2.6.3-SNAPSHOT from 
https://repository.apache.org/content/repositories/snapshots/

If that works for you, please close this ticket.

> Log4j2 TcpSocketServer in background
> 
>
> Key: LOG4J2-1604
> URL: https://issues.apache.org/jira/browse/LOG4J2-1604
> Project: Log4j 2
>  Issue Type: Question
>  Components: Core
>Affects Versions: 2.6.2
> Environment: Linux geotst01 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec 
> 17 01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Colin Hillman
>Assignee: Gary Gregory
>Priority: Minor
>
> I've been using the log4j version 1 SocketServer in background without 
> problem. Changing to the TcpSocketServer works in foreground, but when I put 
> it in the background, it shuts down. I've managed to get it working 
> redirecting input from /dev/zero but as this will give continuous nulls, I'm 
> not sure it's an ideal solution:
> exec $JAVA_HOME/bin/java -cp 
> $LIB_DIR/log4j-api-2.6.2.jar:$LIB_DIR/log4j-core-2.6.2.jar \
> org.apache.logging.log4j.core.net.server.TcpSocketServer \
> $\{LOGPORT} $\{BASEDIR}/etc/log4j2.xml  /dev/null 2>&1 &
> Is the code intended to be used in background 

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on Tomcat shutdown

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1259:
--

OK, sounds good.

> Log4j threads are leaking on Tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on Tomcat shutdown

[Gabriel Stanek (JIRA)]

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

Gabriel Stanek commented on LOG4J2-1259:


The logs that I have been pasting from shutdown are output to catalina.out and 
configured via the Tomcat logging.properties file, which at this point has 
default configurations.  I'll have to spend more time getting the right 
settings in place to see more detail on the shutdown.  My day is ending here 
and I'm off tomorrow. I'll try to look at this again on Friday.  I'll provide 
more detail when I have it.

> Log4j threads are leaking on Tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Reopened] (LOG4J2-1259) Log4j threads are leaking on Tomcat shutdown

[Gary Gregory (JIRA)]

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

Gary Gregory reopened LOG4J2-1259:
--

> Log4j threads are leaking on Tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
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-1259) Log4j threads are leaking on Tomcat shutdown

[Gary Gregory (JIRA)]

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

Gary Gregory edited comment on LOG4J2-1259 at 9/21/16 7:50 PM:
---

In your Log4j configuration file, please set status to TRACE and lets see what 
comes out on the console. 

For example:

{code:xml}

...
{code}

Gary



was (Author: garydgregory):
In your Log4j configuration file, please set status to TRACE and lets see what 
comes out on the console. 

For example:

{code:xml}

...
{code}

Gary


> Log4j threads are leaking on Tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on Tomcat shutdown

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1259:
--

In your Log4j configuration file, please set status to TRACE and lets see what 
comes out on the console. 

For example:

{code:xml}

...
{code}

Gary


> Log4j threads are leaking on Tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on Tomcat shutdown

[Gabriel Stanek (JIRA)]

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

Gabriel Stanek commented on LOG4J2-1259:


Good catch on the log4j-web module.  It appears I did not read far enough down 
on the maven page to see the additional module was needed.  Unfortunately, even 
with the module included, I still see similar exceptions.  I included the 
module as a runtime dependency:
{code:xml}

org.apache.logging.log4j
log4j-web
2.6.3-SNAPSHOT
runtime

{code}

When looking at the lib folder of the generated war, I do see one extra log4j 
related jar: log4j-1.2.16
That jar is brought in from a dependency.  I don't anticipate that it would 
cause a conflict, but wanted to point it out in case you think it would.

Latest log output on app shutdown (Tomcat still running):
{code:xml}
Sep 21, 2016 11:32:34 AM org.apache.catalina.startup.HostConfig undeploy
INFO: Undeploying context [/webs-pub-subscription-usage-api]
Sep 21, 2016 11:32:34 AM org.apache.catalina.loader.WebappClassLoader 
clearReferencesJdbc
SEVERE: The web application [/webs-pub-subscription-usage-api] registered the 
JDBC driver [oracle.jdbc.OracleDriver] but failed to unregister it when the web 
application was stopped. To prevent a memory leak, the JDBC Driver has been 
forcibly unregistered.
Sep 21, 2016 11:32:34 AM org.apache.catalina.loader.WebappClassLoader 
clearReferencesThreads
SEVERE: The web application [/webs-pub-subscription-usage-api] appears to have 
started a thread named [Log4j2-TF-3-Scheduled-1] but has failed to stop it. 
This is very likely to create a memory leak.
Sep 21, 2016 11:32:34 AM org.apache.catalina.loader.WebappClassLoader 
clearReferencesThreads
SEVERE: The web application [/webs-pub-subscription-usage-api] appears to have 
started a thread named [Log4j2-TF-4-AsyncLoggerConfig-2] but has failed to stop 
it. This is very likely to create a memory leak.
Sep 21, 2016 11:32:52 AM org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already.  
Could not load 
org.apache.logging.log4j.core.config.ConfiguratonFileWatcher$ReconfigurationWorker.
  The eventual following stack trace is caused by an error thrown for debugging 
purposes as well as to attempt to terminate the thread which caused the illegal 
access, and has no functional impact.
java.lang.IllegalStateException
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1614)
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1573)
at 
org.apache.logging.log4j.core.config.ConfiguratonFileWatcher.fileModified(ConfiguratonFileWatcher.java:46)
at 
org.apache.logging.log4j.core.util.WatchManager$WatchWorker.run(WatchManager.java:103)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}

The "SEVERE" entries related to Log4j2 occur nearly immediately after the 
shutdown process initiates, so it seems the delay is not taking affect. 

> Log4j threads are leaking on Tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> 

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on Tomcat shutdown

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1259:
--

I notice that you are not using the {{log4j-web}} module. See 
https://logging.apache.org/log4j/2.x/log4j-web/index.html and 
https://logging.apache.org/log4j/2.x/manual/webapp.html. 

Can you try that with the latest SNAPSHOT build?

I uploaded a new snapshot with updates to the log4j-web module to allow for a 
more orderly shutdown.

The commit adds two servlet init parameters called {{log4j.stop.timeout}}
and {{log4j.stop.timeout.timeunit}} with defaults of 30 and
TimeUnit.SECONDS.

Before this code, I am thinking that when the container shuts down Log4j and 
unloads the classes, some Log4j code is left running in sleeping threads and 
causes problems like "Could not load 
org.apache.logging.log4j.core.config.ConfiguratonFileWatcher$ReconfigurationWorker."

The new shutdown code causes Log4j to wait up to the timeout for resources like 
thread pools to shutdown after requesting the cancellation of scheduled jobs, 
which the ReconfigurationWorker is. (Detail: I renamed ReconfigurationWorker to 
ReconfigurationRunnable)

Without the timeout request, Log4j shutsdown immediately but does not wait for 
jobs to complete.


> Log4j threads are leaking on Tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1588) Console or File Logger caches thread name, but not in older log4j2 versions

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1588:
--

Hello Rainer,

I'm not sure playing with thread names is such a good idea here.

Can you explain what you are trying to achieve from a higher level POV?

Would you also be able to use 2.6.2 or our Git master?

Thank you,
Gary

> Console or File Logger caches thread name, but not in older log4j2 versions
> ---
>
> Key: LOG4J2-1588
> URL: https://issues.apache.org/jira/browse/LOG4J2-1588
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.6.2
> Environment: Windows, Grizzly HTTP container, SLF4J API, Log4j2
>Reporter: Rainer Schnitker
>
> Log4j2 2.6.x seems to cache the thread name. A revert to version 2.4.1. 
> works! This affects synchronous logger: console, RollingFile
> My sample code (JAX-RS Filter):
> {code}
> import java.io.IOException;
> import javax.annotation.Priority;
> import javax.inject.Inject;
> import javax.ws.rs.container.ContainerRequestContext;
> import javax.ws.rs.container.ContainerRequestFilter;
> import javax.ws.rs.ext.Provider;
> import org.glassfish.grizzly.http.server.Request;
> import org.slf4j.LoggerFactory;
> @Provider
> @Priority(Integer.MIN_VALUE)
> public class GrizzlyRequestFilter implements ContainerRequestFilter {
> @Inject
> javax.inject.Provider< Request > provider;
> @Override
> public void filter( ContainerRequestContext requestContext ) throws 
> IOException {
> Request request = this.provider.get();
> Thread thread = Thread.currentThread();
> thread.setName( request.getRemoteHost() + '/' + thread.getId() );
> 
> // oops: logger thread name != expected
> LoggerFactory.getLogger(GrizzlyRequestFilter.class)
> .info( "expected thread name:" + request.getRemoteHost() + '/' + 
> thread.getId() );
> 
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on Tomcat shutdown

[Gabriel Stanek (JIRA)]

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

Gabriel Stanek commented on LOG4J2-1259:


My test so far have not been successful.  I've used the following dependencies:
{code:xml}

org.apache.logging.log4j
log4j-api
2.6.3-SNAPSHOT


org.apache.logging.log4j
log4j-core
2.6.3-SNAPSHOT


org.apache.logging.log4j
log4j-slf4j-impl
2.6.2


org.slf4j 
slf4j-api
1.7.21


com.lmax
disruptor
3.3.5

{code}

but, when I delete my war to undeploy the app, I see the following:

{code:xml}
Sep 21, 2016 8:37:30 AM org.apache.catalina.startup.HostConfig undeploy
INFO: Undeploying context [/webs-pub-subscription-usage-api]
Sep 21, 2016 8:37:30 AM org.apache.catalina.loader.WebappClassLoader 
clearReferencesJdbc
SEVERE: The web application [/webs-pub-subscription-usage-api] registered the 
JDBC driver [oracle.jdbc.OracleDriver] but failed to unregister it when the web 
application was stopped. To prevent a memory leak, the JDBC Driver has been 
forcibly unregistered.
Sep 21, 2016 8:37:30 AM org.apache.catalina.loader.WebappClassLoader 
clearReferencesThreads
SEVERE: The web application [/webs-pub-subscription-usage-api] appears to have 
started a thread named [Log4j2-TF-3-Scheduled-1] but has failed to stop it. 
This is very likely to create a memory leak.
Sep 21, 2016 8:37:30 AM org.apache.catalina.loader.WebappClassLoader 
clearReferencesThreads
SEVERE: The web application [/webs-pub-subscription-usage-api] appears to have 
started a thread named [Log4j2-TF-4-AsyncLoggerConfig-2] but has failed to stop 
it. This is very likely to create a memory leak.
Sep 21, 2016 8:37:30 AM org.apache.catalina.loader.WebappClassLoader 
clearReferencesThreads
SEVERE: The web application [/webs-pub-subscription-usage-api] appears to have 
started a thread named [Thread-53] but has failed to stop it. This is very 
likely to create a memory leak.
Sep 21, 2016 8:37:30 AM org.apache.catalina.loader.WebappClassLoader 
checkThreadLocalMapForLeaks
SEVERE: The web application [/webs-pub-subscription-usage-api] created a 
ThreadLocal with key of type [org.springframework.core.NamedThreadLocal] (value 
[Locale context]) and a value of type 
[org.springframework.context.i18n.SimpleLocaleContext] (value [en_US]) 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.
Sep 21, 2016 8:37:30 AM org.apache.catalina.loader.WebappClassLoader 
checkThreadLocalMapForLeaks
SEVERE: The web application [/webs-pub-subscription-usage-api] created a 
ThreadLocal with key of type [com.intuit.platform.webs.aop.KpiLogging$1] (value 
[com.intuit.platform.webs.aop.KpiLogging$1@20cec9a5]) and a value of type 
[java.util.HashMap] (value [{}]) 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.
Sep 21, 2016 8:37:45 AM org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already.  
Could not load 
org.apache.logging.log4j.core.config.ConfiguratonFileWatcher$ReconfigurationWorker.
  The eventual following stack trace is caused by an error thrown for debugging 
purposes as well as to attempt to terminate the thread which caused the illegal 
access, and has no functional impact.
java.lang.IllegalStateException
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1614)
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1573)
at 
org.apache.logging.log4j.core.config.ConfiguratonFileWatcher.fileModified(ConfiguratonFileWatcher.java:46)
at 
org.apache.logging.log4j.core.util.WatchManager$WatchWorker.run(WatchManager.java:103)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 

[jira] [Commented] (LOG4J2-1588) Console or File Logger caches thread name, but not in older log4j2 versions

[Rainer Schnitker (JIRA)]

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

Rainer Schnitker commented on LOG4J2-1588:
--

A test with log4j 2.5 was ok. This issure affects only 2.6.

> Console or File Logger caches thread name, but not in older log4j2 versions
> ---
>
> Key: LOG4J2-1588
> URL: https://issues.apache.org/jira/browse/LOG4J2-1588
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.6.2
> Environment: Windows, Grizzly HTTP container, SLF4J API, Log4j2
>Reporter: Rainer Schnitker
>
> Log4j2 2.6.x seems to cache the thread name. A revert to version 2.4.1. 
> works! This affects synchronous logger: console, RollingFile
> My sample code (JAX-RS Filter):
> {code}
> import java.io.IOException;
> import javax.annotation.Priority;
> import javax.inject.Inject;
> import javax.ws.rs.container.ContainerRequestContext;
> import javax.ws.rs.container.ContainerRequestFilter;
> import javax.ws.rs.ext.Provider;
> import org.glassfish.grizzly.http.server.Request;
> import org.slf4j.LoggerFactory;
> @Provider
> @Priority(Integer.MIN_VALUE)
> public class GrizzlyRequestFilter implements ContainerRequestFilter {
> @Inject
> javax.inject.Provider< Request > provider;
> @Override
> public void filter( ContainerRequestContext requestContext ) throws 
> IOException {
> Request request = this.provider.get();
> Thread thread = Thread.currentThread();
> thread.setName( request.getRemoteHost() + '/' + thread.getId() );
> 
> // oops: logger thread name != expected
> LoggerFactory.getLogger(GrizzlyRequestFilter.class)
> .info( "expected thread name:" + request.getRemoteHost() + '/' + 
> thread.getId() );
> 
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Bit twiddling in org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()

[Remko Popma]

Is there really a problem to solve here? The code to compute the hashCode for a 
long is actually the canonical way to do this, documented in Effective Java. 
FindBugs is complaining about nothing...

Sent from my iPhone

> On 2016/09/21, at 18:02, Gary Gregory  wrote:
> 
> But that generates lots of temp arrays... it's just as easy to use an IDE 
> code generator to create the methods... I'll try that tomorrow [AFK ATM]
> 
> Gary
> 
> 
>> On Sep 21, 2016 12:23 AM, "Greg Thomas"  wrote:
>> Though, on reflection, (no pun intended), the Objects class *is* in Java 7; 
>> https://docs.oracle.com/javase/7/docs/api/java/util/Objects.html
>> 
>> It makes implement .equals and .hashcode trivial; 
>> 
>> Assuming a TestClass with three fields, foo, bar and foobar, you have ...
>> 
>> @Override
>> public int hashCode() {
>> return Objects.hash(foo, bar, foobar);
>> }
>> and ...
>> 
>> @Override
>> public boolean equals(final Object o) {
>> if (!o == instanceof TestClass ) {
>> return false;
>> }
>> 
>> final TestClass that = (TestClass) o;
>> return Objects.equals(this.foo, that.foo) && Objects.equals(this.bar, 
>> that.bar) && Objects.equals(this.foobar, that.foobar);
>> }
>>  
>> 
>>> On 21 September 2016 at 03:17, Remko Popma  wrote:
>>> Sorry I was thinking of Long.hashCode(long), but I see now that this was 
>>> introduced in java 1.8...
>>> 
>>> Sent from my iPhone
>>> 
 On 2016/09/21, at 10:09, Gary Gregory  wrote:
 
 Where do you see such a method?
 
 Gary
 
> On Tue, Sep 20, 2016 at 4:43 PM, Remko Popma  
> wrote:
> Objects.hashCode(long) does exactly the same, but is certainly easier to 
> read. Go for it!
> 
> Sent from my iPhone
> 
>> On 2016/09/21, at 5:06, Greg Thomas  wrote:
>> 
>> Could you use simply
>> 
>> return Objects.hashcode(...)
>> 
>> To avoid the maths In the first place ??
>> -- 
>> Sent from my iPhone
>> 
>>> On 20 Sep 2016, at 19:53, Gary Gregory  wrote:
>>> 
>>> I see a Findbugs error in:
>>> 
>>> org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()
>>> 
>>> for:
>>> 
>>> result = 31 * result + (threadPriority ^ (threadPriority >>> 
>>> 32));
>>> 
>>> "The code performs shift of a 32 bit int by a constant amount outside 
>>> the range -31..31. The effect of this is to use the lower 5 bits of the 
>>> integer value to decide how much to shift by (e.g., shifting by 40 bits 
>>> is the same as shifting by 8 bits, and shifting by 32 bits is the same 
>>> as shifting by zero bits). This probably isn't what was expected, and 
>>> it is at least confusing."
>>> 
>>> Thoughts?
>>> 
>>> Gary
>>> 
>>> -- 
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com 
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
 
 
 
 -- 
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
 Java Persistence with Hibernate, Second Edition
 JUnit in Action, Second Edition
 Spring Batch in Action
 Blog: http://garygregory.wordpress.com 
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

Re: Bit twiddling in org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()

[Gary Gregory]

But that generates lots of temp arrays... it's just as easy to use an IDE
code generator to create the methods... I'll try that tomorrow [AFK ATM]

Gary

On Sep 21, 2016 12:23 AM, "Greg Thomas"  wrote:

> Though, on reflection, (no pun intended), the Objects class *is* in Java
> 7; https://docs.oracle.com/javase/7/docs/api/java/util/Objects.html
>
> It makes implement .equals and .hashcode trivial;
>
> Assuming a TestClass with three fields, foo, bar and foobar, you have ...
>
> @Override
> public int hashCode() {
> return Objects.hash(foo, bar, foobar);
> }
>
> and ...
>
> @Override
> public boolean equals(final Object o) {
> if (!o == instanceof TestClass ) {
> return false;
> }
>
> final TestClass that = (TestClass) o;
> return Objects.equals(this.foo, that.foo) && Objects.equals(this.bar, 
> that.bar) && Objects.equals(this.foobar, that.foobar);
> }
>
>
>
> On 21 September 2016 at 03:17, Remko Popma  wrote:
>
>> Sorry I was thinking of Long.hashCode(long), but I see now that this was
>> introduced in java 1.8...
>>
>> Sent from my iPhone
>>
>> On 2016/09/21, at 10:09, Gary Gregory  wrote:
>>
>> Where do you see such a method?
>>
>> Gary
>>
>> On Tue, Sep 20, 2016 at 4:43 PM, Remko Popma 
>> wrote:
>>
>>> Objects.hashCode(long) does exactly the same, but is certainly easier to
>>> read. Go for it!
>>>
>>> Sent from my iPhone
>>>
>>> On 2016/09/21, at 5:06, Greg Thomas  wrote:
>>>
>>> Could you use simply
>>>
>>> return Objects.hashcode(...)
>>>
>>> To avoid the maths In the first place ??
>>> --
>>> Sent from my iPhone
>>>
>>> On 20 Sep 2016, at 19:53, Gary Gregory  wrote:
>>>
>>> I see a Findbugs error in:
>>>
>>> org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()
>>>
>>> for:
>>>
>>> result = 31 * result + (threadPriority ^ (threadPriority >>>
>>> 32));
>>>
>>> "The code performs shift of a 32 bit int by a constant amount outside
>>> the range -31..31. The effect of this is to use the lower 5 bits of the
>>> integer value to decide how much to shift by (e.g., shifting by 40 bits is
>>> the same as shifting by 8 bits, and shifting by 32 bits is the same as
>>> shifting by zero bits). This probably isn't what was expected, and it is at
>>> least confusing."
>>>
>>> Thoughts?
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> 
>>> JUnit in Action, Second Edition 
>>> Spring Batch in Action 
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>

[jira] [Assigned] (LOG4J2-1604) Log4j2 TcpSocketServer in background

[Gary Gregory (JIRA)]

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

Gary Gregory reassigned LOG4J2-1604:


Assignee: Gary Gregory

> Log4j2 TcpSocketServer in background
> 
>
> Key: LOG4J2-1604
> URL: https://issues.apache.org/jira/browse/LOG4J2-1604
> Project: Log4j 2
>  Issue Type: Question
>  Components: Core
>Affects Versions: 2.6.2
> Environment: Linux geotst01 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec 
> 17 01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Colin Hillman
>Assignee: Gary Gregory
>Priority: Minor
>
> I've been using the log4j version 1 SocketServer in background without 
> problem. Changing to the TcpSocketServer works in foreground, but when I put 
> it in the background, it shuts down. I've managed to get it working 
> redirecting input from /dev/zero but as this will give continuous nulls, I'm 
> not sure it's an ideal solution:
> exec $JAVA_HOME/bin/java -cp 
> $LIB_DIR/log4j-api-2.6.2.jar:$LIB_DIR/log4j-core-2.6.2.jar \
> org.apache.logging.log4j.core.net.server.TcpSocketServer \
> $\{LOGPORT} $\{BASEDIR}/etc/log4j2.xml  /dev/null 2>&1 &
> Is the code intended to be used in background and, if yes what's the 
> recommended way to launch TcpSocketServer? Could a parameter be added to make 
> it a daemon not needing input?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1604) Log4j2 TcpSocketServer in background

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1604:
--

That sounds do-able.

> Log4j2 TcpSocketServer in background
> 
>
> Key: LOG4J2-1604
> URL: https://issues.apache.org/jira/browse/LOG4J2-1604
> Project: Log4j 2
>  Issue Type: Question
>  Components: Core
>Affects Versions: 2.6.2
> Environment: Linux geotst01 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec 
> 17 01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Colin Hillman
>Priority: Minor
>
> I've been using the log4j version 1 SocketServer in background without 
> problem. Changing to the TcpSocketServer works in foreground, but when I put 
> it in the background, it shuts down. I've managed to get it working 
> redirecting input from /dev/zero but as this will give continuous nulls, I'm 
> not sure it's an ideal solution:
> exec $JAVA_HOME/bin/java -cp 
> $LIB_DIR/log4j-api-2.6.2.jar:$LIB_DIR/log4j-core-2.6.2.jar \
> org.apache.logging.log4j.core.net.server.TcpSocketServer \
> $\{LOGPORT} $\{BASEDIR}/etc/log4j2.xml  /dev/null 2>&1 &
> Is the code intended to be used in background and, if yes what's the 
> recommended way to launch TcpSocketServer? Could a parameter be added to make 
> it a daemon not needing input?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (LOG4J2-1605) Improve error messages for TcpSocketServer and UdpSocketServer.

[Gary Gregory (JIRA)]

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

Gary Gregory closed LOG4J2-1605.

Resolution: Fixed

In Git master.

> Improve error messages for TcpSocketServer and UdpSocketServer.
> ---
>
> Key: LOG4J2-1605
> URL: https://issues.apache.org/jira/browse/LOG4J2-1605
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> Improve error messages for TcpSocketServer and UdpSocketServer to show the 
> values of the parameters in error: a bad port number and incorrect number of 
> arguments.
> Affects:
> - {{org.apache.logging.log4j.core.net.server.TcpSocketServer}}
> - {{org.apache.logging.log4j.core.net.server.UdpSocketServer}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LOG4J2-1605) Improve error messages for TcpSocketServer and UdpSocketServer.

[Gary Gregory (JIRA)]

Gary Gregory created LOG4J2-1605:


 Summary: Improve error messages for TcpSocketServer and 
UdpSocketServer.
 Key: LOG4J2-1605
 URL: https://issues.apache.org/jira/browse/LOG4J2-1605
 Project: Log4j 2
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.6.2
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 2.7


Improve error messages for TcpSocketServer and UdpSocketServer to show the 
values of the parameters in error: a bad port number and incorrect number of 
arguments.

Affects:
- {{org.apache.logging.log4j.core.net.server.TcpSocketServer}}
- {{org.apache.logging.log4j.core.net.server.UdpSocketServer}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Bit twiddling in org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()

[Greg Thomas]

Though, on reflection, (no pun intended), the Objects class *is* in Java 7;
https://docs.oracle.com/javase/7/docs/api/java/util/Objects.html

It makes implement .equals and .hashcode trivial;

Assuming a TestClass with three fields, foo, bar and foobar, you have ...

@Override
public int hashCode() {
return Objects.hash(foo, bar, foobar);
}

and ...

@Override
public boolean equals(final Object o) {
if (!o == instanceof TestClass ) {
return false;
}

final TestClass that = (TestClass) o;
return Objects.equals(this.foo, that.foo) &&
Objects.equals(this.bar, that.bar) && Objects.equals(this.foobar,
that.foobar);
}



On 21 September 2016 at 03:17, Remko Popma  wrote:

> Sorry I was thinking of Long.hashCode(long), but I see now that this was
> introduced in java 1.8...
>
> Sent from my iPhone
>
> On 2016/09/21, at 10:09, Gary Gregory  wrote:
>
> Where do you see such a method?
>
> Gary
>
> On Tue, Sep 20, 2016 at 4:43 PM, Remko Popma 
> wrote:
>
>> Objects.hashCode(long) does exactly the same, but is certainly easier to
>> read. Go for it!
>>
>> Sent from my iPhone
>>
>> On 2016/09/21, at 5:06, Greg Thomas  wrote:
>>
>> Could you use simply
>>
>> return Objects.hashcode(...)
>>
>> To avoid the maths In the first place ??
>> --
>> Sent from my iPhone
>>
>> On 20 Sep 2016, at 19:53, Gary Gregory  wrote:
>>
>> I see a Findbugs error in:
>>
>> org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()
>>
>> for:
>>
>> result = 31 * result + (threadPriority ^ (threadPriority >>> 32));
>>
>> "The code performs shift of a 32 bit int by a constant amount outside the
>> range -31..31. The effect of this is to use the lower 5 bits of the integer
>> value to decide how much to shift by (e.g., shifting by 40 bits is the same
>> as shifting by 8 bits, and shifting by 32 bits is the same as shifting by
>> zero bits). This probably isn't what was expected, and it is at least
>> confusing."
>>
>> Thoughts?
>>
>> Gary
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>

[jira] [Updated] (LOG4J2-1604) Log4j2 TcpSocketServer in background

[Colin Hillman (JIRA)]

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

Colin Hillman updated LOG4J2-1604:
--
Description: 
I've been using the log4j version 1 SocketServer in background without problem. 
Changing to the TcpSocketServer works in foreground, but when I put it in the 
background, it shuts down. I've managed to get it working redirecting input 
from /dev/zero but as this will give continuous nulls, I'm not sure it's an 
ideal solution:

exec $JAVA_HOME/bin/java -cp 
$LIB_DIR/log4j-api-2.6.2.jar:$LIB_DIR/log4j-core-2.6.2.jar \
org.apache.logging.log4j.core.net.server.TcpSocketServer \
$\{LOGPORT} $\{BASEDIR}/etc/log4j2.xml  /dev/null 2>&1 &

Is the code intended to be used in background and, if yes what's the 
recommended way to launch TcpSocketServer? Could a parameter be added to make 
it a daemon not needing input?

  was:
I've been using the log4j version 1 SocketServer in background without problem. 
Changing to the TcpSocketServer works in foreground, but when I put it in the 
background, it shuts down. I've managed to get it working redirecting input 
from /dev/zero but as this will give continuous nulls, I'm not sure it's an 
ideal solution:

exec $JAVA_HOME/bin/java -cp 
$LIB_DIR/log4j-api-2.6.2.jar:$LIB_DIR/log4j-core-2.6.2.jar \
org.apache.logging.log4j.core.net.server.TcpSocketServer \
${LOGPORT} ${BASEDIR}/etc/log4j2.xml  /dev/null 2>&1 &

Is the code intended to be used in background and, if yes what's the 
recommended way to launch TcpSocketServer? Could a parameter be added to make 
it a daemon not needing input?


> Log4j2 TcpSocketServer in background
> 
>
> Key: LOG4J2-1604
> URL: https://issues.apache.org/jira/browse/LOG4J2-1604
> Project: Log4j 2
>  Issue Type: Question
>  Components: Core
>Affects Versions: 2.6.2
> Environment: Linux geotst01 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec 
> 17 01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Colin Hillman
>
> I've been using the log4j version 1 SocketServer in background without 
> problem. Changing to the TcpSocketServer works in foreground, but when I put 
> it in the background, it shuts down. I've managed to get it working 
> redirecting input from /dev/zero but as this will give continuous nulls, I'm 
> not sure it's an ideal solution:
> exec $JAVA_HOME/bin/java -cp 
> $LIB_DIR/log4j-api-2.6.2.jar:$LIB_DIR/log4j-core-2.6.2.jar \
> org.apache.logging.log4j.core.net.server.TcpSocketServer \
> $\{LOGPORT} $\{BASEDIR}/etc/log4j2.xml  /dev/null 2>&1 &
> Is the code intended to be used in background and, if yes what's the 
> recommended way to launch TcpSocketServer? Could a parameter be added to make 
> it a daemon not needing input?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LOG4J2-1604) Log4j2 TcpSocketServer in background

[Colin Hillman (JIRA)]

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

Colin Hillman updated LOG4J2-1604:
--
Priority: Minor  (was: Major)

> Log4j2 TcpSocketServer in background
> 
>
> Key: LOG4J2-1604
> URL: https://issues.apache.org/jira/browse/LOG4J2-1604
> Project: Log4j 2
>  Issue Type: Question
>  Components: Core
>Affects Versions: 2.6.2
> Environment: Linux geotst01 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec 
> 17 01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Colin Hillman
>Priority: Minor
>
> I've been using the log4j version 1 SocketServer in background without 
> problem. Changing to the TcpSocketServer works in foreground, but when I put 
> it in the background, it shuts down. I've managed to get it working 
> redirecting input from /dev/zero but as this will give continuous nulls, I'm 
> not sure it's an ideal solution:
> exec $JAVA_HOME/bin/java -cp 
> $LIB_DIR/log4j-api-2.6.2.jar:$LIB_DIR/log4j-core-2.6.2.jar \
> org.apache.logging.log4j.core.net.server.TcpSocketServer \
> $\{LOGPORT} $\{BASEDIR}/etc/log4j2.xml  /dev/null 2>&1 &
> Is the code intended to be used in background and, if yes what's the 
> recommended way to launch TcpSocketServer? Could a parameter be added to make 
> it a daemon not needing input?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LOG4J2-1604) Log4j2 TcpSocketServer in background

[Colin Hillman (JIRA)]

Colin Hillman created LOG4J2-1604:
-

 Summary: Log4j2 TcpSocketServer in background
 Key: LOG4J2-1604
 URL: https://issues.apache.org/jira/browse/LOG4J2-1604
 Project: Log4j 2
  Issue Type: Question
  Components: Core
Affects Versions: 2.6.2
 Environment: Linux geotst01 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec 
17 01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Colin Hillman


I've been using the log4j version 1 SocketServer in background without problem. 
Changing to the TcpSocketServer works in foreground, but when I put it in the 
background, it shuts down. I've managed to get it working redirecting input 
from /dev/zero but as this will give continuous nulls, I'm not sure it's an 
ideal solution:

exec $JAVA_HOME/bin/java -cp 
$LIB_DIR/log4j-api-2.6.2.jar:$LIB_DIR/log4j-core-2.6.2.jar \
org.apache.logging.log4j.core.net.server.TcpSocketServer \
${LOGPORT} ${BASEDIR}/etc/log4j2.xml  /dev/null 2>&1 &

Is the code intended to be used in background and, if yes what's the 
recommended way to launch TcpSocketServer? Could a parameter be added to make 
it a daemon not needing input?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1051) NoClassDefFoundError when starting app on Google App Engine

[Frank Conover (JIRA)]

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

Frank Conover commented on LOG4J2-1051:
---

My mistake. I needed the core jar.
https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-core/2.6.3-SNAPSHOT/

It works. Thank you. I'll update my post.

On Wed, Sep 21, 2016 at 1:31 AM, Frank Conover 



> NoClassDefFoundError when starting app on Google App Engine
> ---
>
> Key: LOG4J2-1051
> URL: https://issues.apache.org/jira/browse/LOG4J2-1051
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
> Environment: master branch, JDK7, Google App Engine, Apache Struts 2.5
>Reporter: Lukasz Lenart
>Assignee: Remko Popma
> Fix For: 2.4, 2.7
>
>
> I have an app that uses
> - log4j-api
> - log4j-core
> - log4j-web
> and after deploying it to GAE I see such exception in the logs
> {noformat}
> 2015-06-10 23:01:05.768
> Uncaught exception from servlet
> java.lang.NoClassDefFoundError: Could not initialize class 
> org.apache.logging.log4j.core.util.Loader
>   at 
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:114)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.(AbstractConfiguration.java:105)
>   at 
> org.apache.logging.log4j.core.config.NullConfiguration.(NullConfiguration.java:30)
>   at 
> org.apache.logging.log4j.core.LoggerContext.(LoggerContext.java:62)
>   at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoaderContextSelector.java:145)
>   at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:70)
>   at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:57)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:142)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:42)
>   at org.apache.logging.log4j.LogManager.getContext(LogManager.java:175)
>   at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:426)
>   at 
> org.apache.struts2.tiles.StrutsTilesListener.(StrutsTilesListener.java:50)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
>   at java.lang.Class.newInstance(Class.java:375)
>   at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.newListenerInstance(WebXmlConfiguration.java:650)
>   at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.initListener(WebXmlConfiguration.java:631)
>   at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.initWebXmlElement(WebXmlConfiguration.java:368)
>   at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:289)
>   at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:222)
>   at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.configureWebApp(WebXmlConfiguration.java:180)
>   at 
> org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1247)
>   at 
> org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
>   at 
> org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
>   at 
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>   at 
> com.google.apphosting.runtime.jetty.AppVersionHandlerMap.createHandler(AppVersionHandlerMap.java:199)
>   at 
> com.google.apphosting.runtime.jetty.AppVersionHandlerMap.getHandler(AppVersionHandlerMap.java:174)
>   at 
> com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:134)
>   at 
> com.google.apphosting.runtime.JavaRuntime$RequestRunnable.run(JavaRuntime.java:527)
>   at 
> com.google.tracing.TraceContext$TraceContextRunnable.runInContext(TraceContext.java:437)
>   at 
> com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:444)
>   at 
> com.google.tracing.CurrentContext.runInContext(CurrentContext.java:230)
>   at 
> com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:308)
>   at 
> com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:300)
>   at 
>