date:20140430


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

Ralph Goers reopened LOG4J2-625:



After looking at this again this is not a duplicate of LOG4J2-542. That has to 
do with deserialization on a different server where the Exception class may not 
be available.  I'm not sure what the cause of this is.  

 Serialization error with SocketAppender and Asynch Logger
 -

 Key: LOG4J2-625
 URL: https://issues.apache.org/jira/browse/LOG4J2-625
 Project: Log4j 2
  Issue Type: Question
  Components: Appenders
Affects Versions: 2.0-rc1
 Environment: Ubuntu 12.04, Java 7
Reporter: Bryan Hsueh

 I'm testing a simple SocketAppender, which works fine until I switch to 
 asynchronous loggers.  Once I turn on async logging, I get:
 2014-04-29 21:17:26,029 ERROR Serialization of LogEvent failed. 
 java.io.NotSerializableException: 
 org.apache.logging.log4j.core.Logger$PrivateConfig
   at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1183)
   at 
 java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1547)
   at 
 java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1508)
   at 
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1431)
   at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1177)
   at 
 java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1547)
   at 
 java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1508)
   at 
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1431)
   at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1177)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
   at 
 org.apache.logging.log4j.core.layout.SerializedLayout.toByteArray(SerializedLayout.java:64)
   at 
 org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:118)
   at 
 org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:97)
   at 
 org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:425)
   at 
 org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:406)
   at 
 org.apache.logging.log4j.core.Logger$PrivateConfig.logEvent(Logger.java:275)
   at 
 org.apache.logging.log4j.core.async.AsyncLogger.actualAsyncLog(AsyncLogger.java:289)
   at 
 org.apache.logging.log4j.core.async.RingBufferLogEvent.execute(RingBufferLogEvent.java:99)
   at 
 org.apache.logging.log4j.core.async.RingBufferLogEventHandler.onEvent(RingBufferLogEventHandler.java:43)
   at 
 org.apache.logging.log4j.core.async.RingBufferLogEventHandler.onEvent(RingBufferLogEventHandler.java:28)
   at 
 com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
   at java.lang.Thread.run(Thread.java:744)
  My client is configured with:
 ?xml version=1.0 encoding=UTF-8?
 Configuration status=INFO
   Appenders
 Console name=MyConsole target=SYSTEM_OUT
   PatternLayout pattern=%d{HH:mm:ss.SSS}{EST} %-5level- %msg%n/
 /Console
 Socket name=MySocket host=localhost port=
   SerializedLayout /
 /Socket
   /Appenders
   Loggers
 Root level=INFO
   AppenderRef ref=MyConsole/
   AppenderRef ref=MySocket/
 /Root
   /Loggers
 /Configuration
 My server is configured with:
 ?xml version=1.0 encoding=UTF-8?
 Configuration status=INFO
   Appenders
 Console name=MyConsole target=SYSTEM_OUT
   PatternLayout pattern=%d{HH:mm:ss.SSS}{EST} %-5level- %msg%n/
 /Console
   /Appenders
   Loggers
 Root level=INFO
   AppenderRef ref=MyConsole/
 /Root
   /Loggers
 /Configuration
 The client just does a LogManager.getLogger().info({}, hello).
 The server just creates a SocketServer:
 SocketServer server = new SocketServer();
 server.run();
 All works fine until I add this into the client:
 System.setProperty(Log4jContextSelector,
 org.apache.logging.log4j.core.async.AsyncLoggerContextSelector);
 Am I missing something?  Please advise.
 Thanks




--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (LOG4J2-626) ThreadContext for Asynchronous logger in multithreaded environmant is overwriting the values.

sivan created LOG4J2-626:


 Summary: ThreadContext for Asynchronous logger in multithreaded 
environmant is overwriting the values.
 Key: LOG4J2-626
 URL: https://issues.apache.org/jira/browse/LOG4J2-626
 Project: Log4j 2
  Issue Type: Question
  Components: API
Affects Versions: 2.0-rc1
 Environment: java 7
Reporter: sivan


ThreadContext for Asynchronous loggers in multithreaded environmant is 
overwriting the values. Is there is any way to use the custom key value pairs 
in such an environment?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (LOG4J2-624) Better structure of Thread Context Stack in JSONLayout


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

Mikael Ståldal updated LOG4J2-624:
--

Description: 
The Thread Context Stack is currently represented like this in JSONLayout:

{code:JavaScript|title=Current}
  ndc:[foo, bar]
{code}

This is not correct JSON syntax, and does not make proper use of the JSON data 
format. The Thread Context Stack should be represented as a JSON array:

{code:JavaScript|title=Suggested}
  ndc: [foo, bar]
{code}


  was:
The Thread Context Stack is currently represented like this in JSONLayout:

{code:JavaScript:title=Current}
  ndc:[foo, bar]
{code}

This is not correct JSON syntax, and does not make proper use of the JSON data 
format. The Thread Context Stack should be represented as a JSON array:

{code:JavaScript:title=Suggested}
  ndc: [foo, bar]
{code}



 Better structure of Thread Context Stack in JSONLayout
 --

 Key: LOG4J2-624
 URL: https://issues.apache.org/jira/browse/LOG4J2-624
 Project: Log4j 2
  Issue Type: Improvement
  Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Priority: Minor

 The Thread Context Stack is currently represented like this in JSONLayout:
 {code:JavaScript|title=Current}
   ndc:[foo, bar]
 {code}
 This is not correct JSON syntax, and does not make proper use of the JSON 
 data format. The Thread Context Stack should be represented as a JSON array:
 {code:JavaScript|title=Suggested}
   ndc: [foo, bar]
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (LOG4J2-627) Better structure of Thread Context Stack in XMLLayout

Mikael Ståldal created LOG4J2-627:
-

 Summary: Better structure of Thread Context Stack in XMLLayout
 Key: LOG4J2-627
 URL: https://issues.apache.org/jira/browse/LOG4J2-627
 Project: Log4j 2
  Issue Type: Improvement
  Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Priority: Minor


The Thread Context Stack is currently represented like this in XMLLayout:

{code:xml|title=Current}
log4j:NDC![CDATA[[foo, bar]]]/log4j:NDC
{code}

This does not make proper use of the XML data format.

{code:xml|title=Suggested}
log4j:NDC
log4j:NDCEntry![CDATA[[foo]]]/log4j:NDCEntry
log4j:NDCEntry![CDATA[[bar]]]/log4j:NDCEntry
/log4j:NDC
{code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LOG4J2-626) ThreadContext for Asynchronous logger in multithreaded environmant is overwriting the values.


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

Remko Popma commented on LOG4J2-626:


Sorry but this is not enough information to even start investigating. 
Please update the problem description with:
1. Steps to reproduce the problem
2. What is actually happening
3. What you expect to happen

 ThreadContext for Asynchronous logger in multithreaded environmant is 
 overwriting the values.
 -

 Key: LOG4J2-626
 URL: https://issues.apache.org/jira/browse/LOG4J2-626
 Project: Log4j 2
  Issue Type: Question
  Components: API
Affects Versions: 2.0-rc1
 Environment: java 7
Reporter: sivan

 ThreadContext for Asynchronous loggers in multithreaded environmant is 
 overwriting the values. Is there is any way to use the custom key value pairs 
 in such an environment?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (LOG4J2-626) ThreadContext for Asynchronous logger in multithreaded environmant is overwriting the values.

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

sivan updated LOG4J2-626:
-

Description:
ThreadContext for Asynchronous loggers in multithreaded environmant is
overwriting the values. Is there is any way to use the custom key value pairs
in such an environment?

The log4j2 document says that the values in threadcontext may overwrite by
asynchronous logging in multithreaded envirnment. We are implemented the log4j2
asynchronous logging in our single sign on (SSO) framework and the
threadcontext is used to store some parameter values like sessionId, firm, user
etc and these values needs to be included in the log entry. At a time many
users will log into our site by using SSO. Is the threadcontext values will
change by asynchronous logging in multithreaded envirnment? If so, is there any
other way to store these values in thread safe manner?

was:ThreadContext for Asynchronous loggers in multithreaded environmant is
overwriting the values. Is there is any way to use the custom key value pairs
in such an environment?

ThreadContext for Asynchronous logger in multithreaded environmant is
overwriting the values.
-

Key: LOG4J2-626
URL: https://issues.apache.org/jira/browse/LOG4J2-626
Project: Log4j 2
Issue Type: Question
Components: API
Affects Versions: 2.0-rc1
Environment: java 7
Reporter: sivan

ThreadContext for Asynchronous loggers in multithreaded environmant is
overwriting the values. Is there is any way to use the custom key value pairs
in such an environment?
The log4j2 document says that the values in threadcontext may overwrite by
asynchronous logging in multithreaded envirnment. We are implemented the
log4j2 asynchronous logging in our single sign on (SSO) framework and the
threadcontext is used to store some parameter values like sessionId, firm,
user etc and these values needs to be included in the log entry. At a time
many users will log into our site by using SSO. Is the threadcontext values
will change by asynchronous logging in multithreaded envirnment? If so, is
there any other way to store these values in thread safe manner?

--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Comment Edited] (LOG4J2-626) ThreadContext for Asynchronous logger in multithreaded environmant is overwriting the values.

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

Remko Popma edited comment on LOG4J2-626 at 4/30/14 12:36 PM:
--

Log4j classes will _read_ values from the ThreadContext map or stack, but it
will not modify them.
I suspect this is a bug in the application...

Can you reliably reproduce the problem? What are you seeing and what did you
expect to see? Are all key value pairs modified or only some (which ones, when)?

was (Author: rem...@yahoo.com):
Sorry but this is not enough information to even start investigating.
Please update the problem description with:
1. Steps to reproduce the problem
2. What is actually happening
3. What you expect to happen

ThreadContext for Asynchronous logger in multithreaded environmant is
overwriting the values.
-

Key: LOG4J2-626
URL: https://issues.apache.org/jira/browse/LOG4J2-626
Project: Log4j 2
Issue Type: Question
Components: API
Affects Versions: 2.0-rc1
Environment: java 7
Reporter: sivan

--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LOG4J2-626) ThreadContext for Asynchronous logger in multithreaded environmant is overwriting the values.

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

sivan commented on LOG4J2-626:
--

Log4j2 will not modify this. that is OK. But when many users at a time uses
single sign on then what will happen to the key value pairs in the
threadcontext. Is they will modify in multithreaded environment by asynchronous
logger?

ThreadContext for Asynchronous logger in multithreaded environmant is
overwriting the values.
-

Key: LOG4J2-626
URL: https://issues.apache.org/jira/browse/LOG4J2-626
Project: Log4j 2
Issue Type: Question
Components: API
Affects Versions: 2.0-rc1
Environment: java 7
Reporter: sivan

--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (LOG4J2-626) ThreadContext for Asynchronous logger in multithreaded environmant is overwriting the values.

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

sivan updated LOG4J2-626:
-

Description:
ThreadContext for Asynchronous loggers in multithreaded environmant is
overwriting the values. Is there is any way to use the custom key value pairs
in such an environment?

was:
ThreadContext for Asynchronous loggers in multithreaded environmant is
overwriting the values. Is there is any way to use the custom key value pairs
in such an environment?

ThreadContext for Asynchronous logger in multithreaded environmant is
overwriting the values.
-

Key: LOG4J2-626
URL: https://issues.apache.org/jira/browse/LOG4J2-626
Project: Log4j 2
Issue Type: Question
Components: API
Affects Versions: 2.0-rc1
Environment: java 7
Reporter: sivan

--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

Re: Log4j Project Guidelines

2014-04-30 Thread Matt Sicker

So it's a good idea to set up your IDE to warn if you override a
synchronized method with an unsynchronized method? I remember seeing that
one somewhere.


On 30 April 2014 00:35, Remko Popma remko.po...@gmail.com wrote:

 Agreed that unless the synchronization is part of the public API it is
 better to lock on an internal object (e.g. private Object lock = new
 Object(); ).

 On the other hand, OutputStreamManager and subclasses have some
 synchronized public/protected methods and in this case the synchronization
 on this is part of the public API.



 On Wed, Apr 30, 2014 at 1:24 PM, Matt Sicker boa...@gmail.com wrote:

 If you want more than one condition monitor, it's also better to use
 Lock. I'll definitely agree on the simplicity of synchronizing on an
 internal Object instance, though. Locking on this, however, is generally a
 bad idea because any other code can synchronize on the object as well by
 accident and cause weird problems.


 On 29 April 2014 20:51, Gary Gregory garydgreg...@gmail.com wrote:

 I like the KISS approach for now as well.

 Gary


 On Tue, Apr 29, 2014 at 9:45 PM, Remko Popma remko.po...@gmail.comwrote:

 This should be a separate thread, but anyway...

 I would oppose using fair locks. Not only will throughput be much less,
 the benefits are debatable, since fairness of locks does not guarantee
 fairness of thread scheduling. So we would always pay a price in
 throughput without any guarantee of upside on the latency variance. Not a
 good trade-off.

 The solution here is not using different locking mechanisms but not
 using locking at all. That is, anyone who is concerned about latency
 variance (of which starvation is an extreme case) should be using
 asynchronous loggers. The numbers show that with the disruptor (Async
 Loggers) you get 3 to 5 *orders of magnitude* less latency. (Yes that means
 1000x - 100,000x less latency.) And this is compared to AsyncAppender.
 Synchronous logging is not even in the picture here.

 I do agree that synchronizing on a String should be avoided, because
 Strings can be intern()-ed (and in the ConfigurationFactory case it was a
 String literal which is intern()ed by default), which means that our lock
 object is globally visible and other parts of the system could potentially
 synchronize on it and cause deadlock. That was a nice catch.

 However, I'm not convinced that java.util.concurrent.Lock is always
 better than the synchronized keyword. It is a more powerful API, and gives
 more low-level control, but it comes with more complexity and
 responsibility, the most obvious one being you need to manually unlock()
 it. With the synchronized keyword I don't need to worry if I or anyone
 refactoring the code still correctly unlock()s the lock in a finally
 clause. It just works. Nice and simple. It is only when I really need the
 more powerful API that I consider using Locks. For example when using
 separate read and write locks. Or if I need to use tryLock(). Things that I
 can't do with the synchronized keyword. Otherwise I prefer to keep it
 simple.

 My 2 cents.

 Remko


 On Wed, Apr 30, 2014 at 5:45 AM, Matt Sicker boa...@gmail.com wrote:

 Should we be using a fair lock? That's usually a lot slower than a
 typical one, but if it's more proper behavior, then it would make sense to
 go that route.


 On 29 April 2014 14:49, Jörn Huxhorn jhuxh...@googlemail.com wrote:

 Please keep in mind that synchronized is not fair.

 http://sourceforge.net/apps/trac/lilith/wiki/SynchronizedVsFairLock

 Yes, a fair ReentrantLock is way slower than an unfair one… but if
 starvation is caused by a logging framework then this is a serious issue 
 in
 my opinion.

 Joern

 On 29. April 2014 at 01:05:26, Matt Sicker (boa...@gmail.com) wrote:
  I'll delegate my arguments to the SO post about it:
 
 http://stackoverflow.com/questions/442564/avoid-synchronizedthis-in-java
 
  In short, it's defensive programming. It's safer to synchronize on
 an
  internal object than on this. Plus, it aids in concurrency
 throughput
  instead of just using a synchronized method.
 
 
  On 28 April 2014 12:45, Ralph Goers wrote:
 
   Why are they not appropriate lock objects? Start a discussion
 before just
   changing them.
  
   Ralph
  
  
  
   On Apr 28, 2014, at 10:40 AM, Matt Sicker wrote:
  
   In that case, Item 69: prefer concurrency utilities to wait and
 notify.
   Sounds like we can just use a plain Object instance to lock
 (which is
   pretty much equivalent to using ReentrantLock) when doing normal
 locks, but
   instead of using .notifyAll() and .wait(), we should use the
 Condition
   interface (which would require using Lock as well).
  
   I agree that using synchronized(object) makes sense when it's all
 that's
   being done. However, I've been changing instances of
 synchronized(this) and
   synchronized(foo) where foo is not an appropriate lock object
 (e.g., a
   string, or a non-final object, things like that).
  
  
   On 28 April 2014 12:28, Ralph

Re: Log4j Project Guidelines

2014-04-30 Thread Gary Gregory

I'm pretty sure Eclipse does that.

Gary


On Wed, Apr 30, 2014 at 9:50 AM, Matt Sicker boa...@gmail.com wrote:

 So it's a good idea to set up your IDE to warn if you override a
 synchronized method with an unsynchronized method? I remember seeing that
 one somewhere.


 On 30 April 2014 00:35, Remko Popma remko.po...@gmail.com wrote:

 Agreed that unless the synchronization is part of the public API it is
 better to lock on an internal object (e.g. private Object lock = new
 Object(); ).

 On the other hand, OutputStreamManager and subclasses have some
 synchronized public/protected methods and in this case the synchronization
 on this is part of the public API.



 On Wed, Apr 30, 2014 at 1:24 PM, Matt Sicker boa...@gmail.com wrote:

 If you want more than one condition monitor, it's also better to use
 Lock. I'll definitely agree on the simplicity of synchronizing on an
 internal Object instance, though. Locking on this, however, is generally a
 bad idea because any other code can synchronize on the object as well by
 accident and cause weird problems.


 On 29 April 2014 20:51, Gary Gregory garydgreg...@gmail.com wrote:

 I like the KISS approach for now as well.

 Gary


 On Tue, Apr 29, 2014 at 9:45 PM, Remko Popma remko.po...@gmail.comwrote:

 This should be a separate thread, but anyway...

 I would oppose using fair locks. Not only will throughput be much
 less, the benefits are debatable, since fairness of locks does not
 guarantee fairness of thread scheduling. So we would always pay a
 price in throughput without any guarantee of upside on the latency
 variance. Not a good trade-off.

 The solution here is not using different locking mechanisms but not
 using locking at all. That is, anyone who is concerned about latency
 variance (of which starvation is an extreme case) should be using
 asynchronous loggers. The numbers show that with the disruptor (Async
 Loggers) you get 3 to 5 *orders of magnitude* less latency. (Yes that 
 means
 1000x - 100,000x less latency.) And this is compared to AsyncAppender.
 Synchronous logging is not even in the picture here.

 I do agree that synchronizing on a String should be avoided, because
 Strings can be intern()-ed (and in the ConfigurationFactory case it was a
 String literal which is intern()ed by default), which means that our lock
 object is globally visible and other parts of the system could potentially
 synchronize on it and cause deadlock. That was a nice catch.

 However, I'm not convinced that java.util.concurrent.Lock is always
 better than the synchronized keyword. It is a more powerful API, and gives
 more low-level control, but it comes with more complexity and
 responsibility, the most obvious one being you need to manually unlock()
 it. With the synchronized keyword I don't need to worry if I or anyone
 refactoring the code still correctly unlock()s the lock in a finally
 clause. It just works. Nice and simple. It is only when I really need the
 more powerful API that I consider using Locks. For example when using
 separate read and write locks. Or if I need to use tryLock(). Things that 
 I
 can't do with the synchronized keyword. Otherwise I prefer to keep it
 simple.

 My 2 cents.

 Remko


 On Wed, Apr 30, 2014 at 5:45 AM, Matt Sicker boa...@gmail.com wrote:

 Should we be using a fair lock? That's usually a lot slower than a
 typical one, but if it's more proper behavior, then it would make sense 
 to
 go that route.


 On 29 April 2014 14:49, Jörn Huxhorn jhuxh...@googlemail.com wrote:

 Please keep in mind that synchronized is not fair.

 http://sourceforge.net/apps/trac/lilith/wiki/SynchronizedVsFairLock

 Yes, a fair ReentrantLock is way slower than an unfair one… but if
 starvation is caused by a logging framework then this is a serious 
 issue in
 my opinion.

 Joern

 On 29. April 2014 at 01:05:26, Matt Sicker (boa...@gmail.com) wrote:
  I'll delegate my arguments to the SO post about it:
 
 http://stackoverflow.com/questions/442564/avoid-synchronizedthis-in-java
 
  In short, it's defensive programming. It's safer to synchronize on
 an
  internal object than on this. Plus, it aids in concurrency
 throughput
  instead of just using a synchronized method.
 
 
  On 28 April 2014 12:45, Ralph Goers wrote:
 
   Why are they not appropriate lock objects? Start a discussion
 before just
   changing them.
  
   Ralph
  
  
  
   On Apr 28, 2014, at 10:40 AM, Matt Sicker wrote:
  
   In that case, Item 69: prefer concurrency utilities to wait and
 notify.
   Sounds like we can just use a plain Object instance to lock
 (which is
   pretty much equivalent to using ReentrantLock) when doing normal
 locks, but
   instead of using .notifyAll() and .wait(), we should use the
 Condition
   interface (which would require using Lock as well).
  
   I agree that using synchronized(object) makes sense when it's
 all that's
   being done. However, I've been changing instances of
 synchronized(this) and
   synchronized(foo) where foo is not an

Re: Log4j Project Guidelines

2014-04-30 Thread Remko Popma

Yes, overriding a synchronized method with an unsynchronized method sounds
dangerous... Warnings would probably be helpful.


On Wed, Apr 30, 2014 at 11:13 PM, Gary Gregory garydgreg...@gmail.comwrote:

 I'm pretty sure Eclipse does that.

 Gary


 On Wed, Apr 30, 2014 at 9:50 AM, Matt Sicker boa...@gmail.com wrote:

 So it's a good idea to set up your IDE to warn if you override a
 synchronized method with an unsynchronized method? I remember seeing that
 one somewhere.


 On 30 April 2014 00:35, Remko Popma remko.po...@gmail.com wrote:

 Agreed that unless the synchronization is part of the public API it is
 better to lock on an internal object (e.g. private Object lock = new
 Object(); ).

 On the other hand, OutputStreamManager and subclasses have some
 synchronized public/protected methods and in this case the synchronization
 on this is part of the public API.



 On Wed, Apr 30, 2014 at 1:24 PM, Matt Sicker boa...@gmail.com wrote:

 If you want more than one condition monitor, it's also better to use
 Lock. I'll definitely agree on the simplicity of synchronizing on an
 internal Object instance, though. Locking on this, however, is generally a
 bad idea because any other code can synchronize on the object as well by
 accident and cause weird problems.


 On 29 April 2014 20:51, Gary Gregory garydgreg...@gmail.com wrote:

 I like the KISS approach for now as well.

 Gary


 On Tue, Apr 29, 2014 at 9:45 PM, Remko Popma remko.po...@gmail.comwrote:

 This should be a separate thread, but anyway...

 I would oppose using fair locks. Not only will throughput be much
 less, the benefits are debatable, since fairness of locks does not
 guarantee fairness of thread scheduling. So we would always pay a
 price in throughput without any guarantee of upside on the latency
 variance. Not a good trade-off.

 The solution here is not using different locking mechanisms but not
 using locking at all. That is, anyone who is concerned about latency
 variance (of which starvation is an extreme case) should be using
 asynchronous loggers. The numbers show that with the disruptor (Async
 Loggers) you get 3 to 5 *orders of magnitude* less latency. (Yes that 
 means
 1000x - 100,000x less latency.) And this is compared to AsyncAppender.
 Synchronous logging is not even in the picture here.

 I do agree that synchronizing on a String should be avoided, because
 Strings can be intern()-ed (and in the ConfigurationFactory case it was a
 String literal which is intern()ed by default), which means that our lock
 object is globally visible and other parts of the system could 
 potentially
 synchronize on it and cause deadlock. That was a nice catch.

 However, I'm not convinced that java.util.concurrent.Lock is always
 better than the synchronized keyword. It is a more powerful API, and 
 gives
 more low-level control, but it comes with more complexity and
 responsibility, the most obvious one being you need to manually unlock()
 it. With the synchronized keyword I don't need to worry if I or anyone
 refactoring the code still correctly unlock()s the lock in a finally
 clause. It just works. Nice and simple. It is only when I really need the
 more powerful API that I consider using Locks. For example when using
 separate read and write locks. Or if I need to use tryLock(). Things 
 that I
 can't do with the synchronized keyword. Otherwise I prefer to keep it
 simple.

 My 2 cents.

 Remko


 On Wed, Apr 30, 2014 at 5:45 AM, Matt Sicker boa...@gmail.comwrote:

 Should we be using a fair lock? That's usually a lot slower than a
 typical one, but if it's more proper behavior, then it would make sense 
 to
 go that route.


 On 29 April 2014 14:49, Jörn Huxhorn jhuxh...@googlemail.comwrote:

 Please keep in mind that synchronized is not fair.

 http://sourceforge.net/apps/trac/lilith/wiki/SynchronizedVsFairLock

 Yes, a fair ReentrantLock is way slower than an unfair one… but if
 starvation is caused by a logging framework then this is a serious 
 issue in
 my opinion.

 Joern

 On 29. April 2014 at 01:05:26, Matt Sicker (boa...@gmail.com)
 wrote:
  I'll delegate my arguments to the SO post about it:
 
 http://stackoverflow.com/questions/442564/avoid-synchronizedthis-in-java
 
  In short, it's defensive programming. It's safer to synchronize
 on an
  internal object than on this. Plus, it aids in concurrency
 throughput
  instead of just using a synchronized method.
 
 
  On 28 April 2014 12:45, Ralph Goers wrote:
 
   Why are they not appropriate lock objects? Start a discussion
 before just
   changing them.
  
   Ralph
  
  
  
   On Apr 28, 2014, at 10:40 AM, Matt Sicker wrote:
  
   In that case, Item 69: prefer concurrency utilities to wait and
 notify.
   Sounds like we can just use a plain Object instance to lock
 (which is
   pretty much equivalent to using ReentrantLock) when doing
 normal locks, but
   instead of using .notifyAll() and .wait(), we should use the
 Condition
   interface (which would require using Lock as

synchronized vs. Lock (was: Log4j Project Guidelines)

2014-04-30 Thread Jörn Huxhorn

Did you try https://gist.github.com/huxi/81c152a672d1b39aed64 with different 
delays? (If you find anything wrong with that code, please let me know.)

The output on my system with 0ms, 1ms and 10ms delays looks like this: 
http://pastebin.com/za07QmUU

Unfairness increases with the amount of time a lock is held. This isn’t a 
theoretical phantom issue, either. It bit us in production. So if locking is 
used, it is important to keep that in mind. I simply wanted to raise awareness 
about it.

Not using locking at all would definitely be ideal.
I need to take a closer look at org.apache.logging.log4j.core.async.AsyncLogger 
and Disruptor in general.

Joern.

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

Re: Log4j Project Guidelines

2014-04-30 Thread Ralph Goers

Actually, I believe there was a case where I did that because the method in the 
subclass used java.util.concurrent instead of requiring method synchronization.

Ralph

On Apr 30, 2014, at 7:19 AM, Remko Popma remko.po...@gmail.com wrote:

 Yes, overriding a synchronized method with an unsynchronized method sounds 
 dangerous... Warnings would probably be helpful.
 
 
 On Wed, Apr 30, 2014 at 11:13 PM, Gary Gregory garydgreg...@gmail.com wrote:
 I'm pretty sure Eclipse does that.
 
 Gary
 
 
 On Wed, Apr 30, 2014 at 9:50 AM, Matt Sicker boa...@gmail.com wrote:
 So it's a good idea to set up your IDE to warn if you override a synchronized 
 method with an unsynchronized method? I remember seeing that one somewhere.
 
 
 On 30 April 2014 00:35, Remko Popma remko.po...@gmail.com wrote:
 Agreed that unless the synchronization is part of the public API it is better 
 to lock on an internal object (e.g. private Object lock = new Object(); ).
 
 On the other hand, OutputStreamManager and subclasses have some synchronized 
 public/protected methods and in this case the synchronization on this is 
 part of the public API.
 
 
 
 On Wed, Apr 30, 2014 at 1:24 PM, Matt Sicker boa...@gmail.com wrote:
 If you want more than one condition monitor, it's also better to use Lock. 
 I'll definitely agree on the simplicity of synchronizing on an internal 
 Object instance, though. Locking on this, however, is generally a bad idea 
 because any other code can synchronize on the object as well by accident and 
 cause weird problems.
 
 
 On 29 April 2014 20:51, Gary Gregory garydgreg...@gmail.com wrote:
 I like the KISS approach for now as well.
 
 Gary
 
 
 On Tue, Apr 29, 2014 at 9:45 PM, Remko Popma remko.po...@gmail.com wrote:
 This should be a separate thread, but anyway...
 
 I would oppose using fair locks. Not only will throughput be much less, the 
 benefits are debatable, since fairness of locks does not guarantee fairness 
 of thread scheduling. So we would always pay a price in throughput without 
 any guarantee of upside on the latency variance. Not a good trade-off.
 
 The solution here is not using different locking mechanisms but not using 
 locking at all. That is, anyone who is concerned about latency variance (of 
 which starvation is an extreme case) should be using asynchronous loggers. 
 The numbers show that with the disruptor (Async Loggers) you get 3 to 5 
 *orders of magnitude* less latency. (Yes that means 1000x - 100,000x less 
 latency.) And this is compared to AsyncAppender. Synchronous logging is not 
 even in the picture here.
 
 I do agree that synchronizing on a String should be avoided, because Strings 
 can be intern()-ed (and in the ConfigurationFactory case it was a String 
 literal which is intern()ed by default), which means that our lock object is 
 globally visible and other parts of the system could potentially synchronize 
 on it and cause deadlock. That was a nice catch.
 
 However, I'm not convinced that java.util.concurrent.Lock is always better 
 than the synchronized keyword. It is a more powerful API, and gives more 
 low-level control, but it comes with more complexity and responsibility, the 
 most obvious one being you need to manually unlock() it. With the 
 synchronized keyword I don't need to worry if I or anyone refactoring the 
 code still correctly unlock()s the lock in a finally clause. It just works. 
 Nice and simple. It is only when I really need the more powerful API that I 
 consider using Locks. For example when using separate read and write locks. 
 Or if I need to use tryLock(). Things that I can't do with the synchronized 
 keyword. Otherwise I prefer to keep it simple.
 
 My 2 cents.
 
 Remko
 
 
 On Wed, Apr 30, 2014 at 5:45 AM, Matt Sicker boa...@gmail.com wrote:
 Should we be using a fair lock? That's usually a lot slower than a typical 
 one, but if it's more proper behavior, then it would make sense to go that 
 route.
 
 
 On 29 April 2014 14:49, Jörn Huxhorn jhuxh...@googlemail.com wrote:
 Please keep in mind that synchronized is not fair.
 
 http://sourceforge.net/apps/trac/lilith/wiki/SynchronizedVsFairLock
 
 Yes, a fair ReentrantLock is way slower than an unfair one… but if starvation 
 is caused by a logging framework then this is a serious issue in my opinion.
 
 Joern
 
 On 29. April 2014 at 01:05:26, Matt Sicker (boa...@gmail.com) wrote:
  I'll delegate my arguments to the SO post about it:
  http://stackoverflow.com/questions/442564/avoid-synchronizedthis-in-java
 
  In short, it's defensive programming. It's safer to synchronize on an
  internal object than on this. Plus, it aids in concurrency throughput
  instead of just using a synchronized method.
 
 
  On 28 April 2014 12:45, Ralph Goers wrote:
 
   Why are they not appropriate lock objects? Start a discussion before just
   changing them.
  
   Ralph
  
  
  
   On Apr 28, 2014, at 10:40 AM, Matt Sicker wrote:
  
   In that case, Item 69: prefer concurrency utilities to wait and

[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout


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

Mikael Ståldal commented on LOG4J2-623:
---

Currently, it does mimic the XMLLayout. This is not a good thing in this case 
since JSON and XML have different structures.

 Better structure of Thread Context Map in JSONLayout
 

 Key: LOG4J2-623
 URL: https://issues.apache.org/jira/browse/LOG4J2-623
 Project: Log4j 2
  Issue Type: Improvement
  Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Assignee: Ralph Goers
Priority: Minor

 Currently, the Thread Context Map looks like this in JSONLayout:
 {code:JavaScript|title=Current}
  Properties:[
   {
 name:UserName,
 value:admin
   },
   {
 name:OrgName,
 value:test
   } 
 ] 
 {code}
 This does not properly make use of the JSON data format. Since the Thread 
 Context Map is a map, it should be represented as a JSON object. And why not 
 name it mdc rather than the quite vauge Properties?
 {code:JavaScript|title=Suggested}
   mdc: {
 UserName:admin, 
 OrgName:test
   }
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout


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

Ralph Goers commented on LOG4J2-623:


I didn't mean in terms of structure. I mean the names in JSON and XML should 
match where it makes sense.

 Better structure of Thread Context Map in JSONLayout
 

 Key: LOG4J2-623
 URL: https://issues.apache.org/jira/browse/LOG4J2-623
 Project: Log4j 2
  Issue Type: Improvement
  Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Assignee: Ralph Goers
Priority: Minor

 Currently, the Thread Context Map looks like this in JSONLayout:
 {code:JavaScript|title=Current}
  Properties:[
   {
 name:UserName,
 value:admin
   },
   {
 name:OrgName,
 value:test
   } 
 ] 
 {code}
 This does not properly make use of the JSON data format. Since the Thread 
 Context Map is a map, it should be represented as a JSON object. And why not 
 name it mdc rather than the quite vauge Properties?
 {code:JavaScript|title=Suggested}
   mdc: {
 UserName:admin, 
 OrgName:test
   }
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout


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

Mikael Ståldal commented on LOG4J2-623:
---

Ah, yes then I agree.

 Better structure of Thread Context Map in JSONLayout
 

 Key: LOG4J2-623
 URL: https://issues.apache.org/jira/browse/LOG4J2-623
 Project: Log4j 2
  Issue Type: Improvement
  Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Assignee: Ralph Goers
Priority: Minor

 Currently, the Thread Context Map looks like this in JSONLayout:
 {code:JavaScript|title=Current}
  Properties:[
   {
 name:UserName,
 value:admin
   },
   {
 name:OrgName,
 value:test
   } 
 ] 
 {code}
 This does not properly make use of the JSON data format. Since the Thread 
 Context Map is a map, it should be represented as a JSON object. And why not 
 name it mdc rather than the quite vauge Properties?
 {code:JavaScript|title=Suggested}
   mdc: {
 UserName:admin, 
 OrgName:test
   }
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

Re: Log4j Project Guidelines

2014-04-30 Thread Matt Sicker

There are legitimate reasons to do that as long as you maintain
thread-safety such as the case Ralph mentioned. Though that would probably
require full control of the API from top to bottom-ish.


On 30 April 2014 10:22, Ralph Goers ralph.go...@dslextreme.com wrote:

 Actually, I believe there was a case where I did that because the method
 in the subclass used java.util.concurrent instead of requiring method
 synchronization.

 Ralph

 On Apr 30, 2014, at 7:19 AM, Remko Popma remko.po...@gmail.com wrote:

 Yes, overriding a synchronized method with an unsynchronized method sounds
 dangerous... Warnings would probably be helpful.


 On Wed, Apr 30, 2014 at 11:13 PM, Gary Gregory garydgreg...@gmail.comwrote:

 I'm pretty sure Eclipse does that.

 Gary


 On Wed, Apr 30, 2014 at 9:50 AM, Matt Sicker boa...@gmail.com wrote:

 So it's a good idea to set up your IDE to warn if you override a
 synchronized method with an unsynchronized method? I remember seeing that
 one somewhere.


 On 30 April 2014 00:35, Remko Popma remko.po...@gmail.com wrote:

 Agreed that unless the synchronization is part of the public API it is
 better to lock on an internal object (e.g. private Object lock = new
 Object(); ).

 On the other hand, OutputStreamManager and subclasses have some
 synchronized public/protected methods and in this case the synchronization
 on this is part of the public API.



 On Wed, Apr 30, 2014 at 1:24 PM, Matt Sicker boa...@gmail.com wrote:

 If you want more than one condition monitor, it's also better to use
 Lock. I'll definitely agree on the simplicity of synchronizing on an
 internal Object instance, though. Locking on this, however, is generally a
 bad idea because any other code can synchronize on the object as well by
 accident and cause weird problems.


 On 29 April 2014 20:51, Gary Gregory garydgreg...@gmail.com wrote:

 I like the KISS approach for now as well.

 Gary


 On Tue, Apr 29, 2014 at 9:45 PM, Remko Popma 
 remko.po...@gmail.comwrote:

 This should be a separate thread, but anyway...

 I would oppose using fair locks. Not only will throughput be much
 less, the benefits are debatable, since fairness of locks does not
 guarantee fairness of thread scheduling. So we would always pay a
 price in throughput without any guarantee of upside on the latency
 variance. Not a good trade-off.

 The solution here is not using different locking mechanisms but not
 using locking at all. That is, anyone who is concerned about latency
 variance (of which starvation is an extreme case) should be using
 asynchronous loggers. The numbers show that with the disruptor (Async
 Loggers) you get 3 to 5 *orders of magnitude* less latency. (Yes that 
 means
 1000x - 100,000x less latency.) And this is compared to AsyncAppender.
 Synchronous logging is not even in the picture here.

 I do agree that synchronizing on a String should be avoided, because
 Strings can be intern()-ed (and in the ConfigurationFactory case it was 
 a
 String literal which is intern()ed by default), which means that our 
 lock
 object is globally visible and other parts of the system could 
 potentially
 synchronize on it and cause deadlock. That was a nice catch.

 However, I'm not convinced that java.util.concurrent.Lock is always
 better than the synchronized keyword. It is a more powerful API, and 
 gives
 more low-level control, but it comes with more complexity and
 responsibility, the most obvious one being you need to manually unlock()
 it. With the synchronized keyword I don't need to worry if I or anyone
 refactoring the code still correctly unlock()s the lock in a finally
 clause. It just works. Nice and simple. It is only when I really need 
 the
 more powerful API that I consider using Locks. For example when using
 separate read and write locks. Or if I need to use tryLock(). Things 
 that I
 can't do with the synchronized keyword. Otherwise I prefer to keep it
 simple.

 My 2 cents.

 Remko


 On Wed, Apr 30, 2014 at 5:45 AM, Matt Sicker boa...@gmail.comwrote:

 Should we be using a fair lock? That's usually a lot slower than a
 typical one, but if it's more proper behavior, then it would make 
 sense to
 go that route.


 On 29 April 2014 14:49, Jörn Huxhorn jhuxh...@googlemail.comwrote:

 Please keep in mind that synchronized is not fair.

 http://sourceforge.net/apps/trac/lilith/wiki/SynchronizedVsFairLock

 Yes, a fair ReentrantLock is way slower than an unfair one… but if
 starvation is caused by a logging framework then this is a serious 
 issue in
 my opinion.

 Joern

 On 29. April 2014 at 01:05:26, Matt Sicker (boa...@gmail.com)
 wrote:
  I'll delegate my arguments to the SO post about it:
 
 http://stackoverflow.com/questions/442564/avoid-synchronizedthis-in-java
 
  In short, it's defensive programming. It's safer to synchronize
 on an
  internal object than on this. Plus, it aids in concurrency
 throughput
  instead of just using a synchronized method.
 
 
  On 28 April 2014 12:45, Ralph Goers wrote:

[jira] [Created] (LOG4J2-628) Cannot set log4j.Clock with Async appender

2014-04-30 Thread Bryan Hsueh (JIRA)

Bryan Hsueh created LOG4J2-628:
--

 Summary: Cannot set log4j.Clock with Async appender
 Key: LOG4J2-628
 URL: https://issues.apache.org/jira/browse/LOG4J2-628
 Project: Log4j 2
  Issue Type: Question
  Components: Appenders
Affects Versions: 2.0-rc1
 Environment: Ubuntu 12.04 / Java 7
Reporter: Bryan Hsueh


I override log4j.Clock to support a live time vs a simulated time.  

System.setProperty(log4j.Clock, teambh.trade.utils.MyClock);

If I use asynchronous loggers, it works fine and calls my 
Clock:currentTimeMillis().  

If I switch to async appenders, currentTimeMillis() is not called.

Is this expected behavior or a bug?  

Thanks



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LOG4J2-628) Cannot set log4j.Clock with Async appender

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

Remko Popma commented on LOG4J2-628:

This is expected behaviour as of RC-1.

The use case for the Clock interface was to allow an extra performance
optimization for users who want to squeeze the last drop of performance out of
the logging subsystem. The trade-off is that the faster CachedClock
implementation shows jumps of 10-16 milliseconds, so you lose accuracy in the
log timestamps.

However this optimization only becomes visible after other bottlenecks have
been removed. The performance bottleneck of Async appender is on the queue, and
optimizing the timestamping mechanism would not make a visible difference in
performance.

If your use case for using a custom Clock is not performance related, can you
clarify what it is you are trying to achieve?
Perhaps it would make sense to use the Clock interface consistently everywhere
in Log4j.

Cannot set log4j.Clock with Async appender
--

Key: LOG4J2-628
URL: https://issues.apache.org/jira/browse/LOG4J2-628
Project: Log4j 2
Issue Type: Question
Components: Appenders
Affects Versions: 2.0-rc1
Environment: Ubuntu 12.04 / Java 7
Reporter: Bryan Hsueh

I override log4j.Clock to support a live time vs a simulated time.
System.setProperty(log4j.Clock, teambh.trade.utils.MyClock);
If I use asynchronous loggers, it works fine and calls my
Clock:currentTimeMillis().
If I switch to async appenders, currentTimeMillis() is not called.
Is this expected behavior or a bug?
Thanks

--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LOG4J2-626) ThreadContext for Asynchronous logger in multithreaded environmant is overwriting the values.

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

Remko Popma commented on LOG4J2-626:

It should not matter whether you use asynchronous or synchronous logging. When
the application logs a message, Log4j will take a snapshot of the ThreadContext
map of that thread. The snapshot will not change even if the application later
modifies the ThreadContext map.

Depending on your configuration, you may see some or all of the ThreadContext
values in the resulting log file. What you see in the log are the values of the
ThreadContext at the time that the application called {{logger.log(message)}}
and Log4j took a ThreadContext map snapshot.

Does this match what you are seeing?

One thing to be aware of: if you are using a thread pool (and most web
application servers do), you are re-using threads. So it may be a good idea to
clean the ThreadContext from the thread after you are done with it.

ThreadContext for Asynchronous logger in multithreaded environmant is
overwriting the values.
-

Key: LOG4J2-626
URL: https://issues.apache.org/jira/browse/LOG4J2-626
Project: Log4j 2
Issue Type: Question
Components: API
Affects Versions: 2.0-rc1
Environment: java 7
Reporter: sivan

--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

Re: New log4j-streams Module

2014-04-30 Thread Bruce Brouwer

Can we agree to pull out jpa and jms?

As for web, I know there was some discussion on how we could not register a
shutdown hook. If we broke out log4j-web, maybe we could make it as simple
as registering a shutdown hook if log4j-web is not included, but if
log4j-web was included, the shutdown hook is not registered. It's just an
idea.


On Wed, Apr 30, 2014 at 12:22 AM, Matt Sicker boa...@gmail.com wrote:

 I mean I split off log4j-streams and put it in a branch. It being the
 streams module.

 The web stuff actually makes sense to keep in core. JPA and JMS should
 probably be in their own modules. The syslog stuff could be at least in its
 own packages but still in log4j-core. I'm unsure about the JSON/YAML ones
 since they're strictly for configuration and don't really add many classes
 overall.


 On 29 April 2014 21:55, Ralph Goers ralph.go...@dslextreme.com wrote:

 What do you mean “you took care of it?” jpa, jms, web as well as the json
 and yaml support are still in core.  I don’t know that we have agreed to
 move them out yet.

 Ralph

 On Apr 29, 2014, at 4:28 PM, Matt Sicker boa...@gmail.com wrote:

 I took care of it and added it to the experimental branch in svn (along
 with a log4j-camel module I was working on).


 On 29 April 2014 18:18, Bruce Brouwer bruce.brou...@gmail.com wrote:

 Was there any support in creating any of these new modules?


 On Fri, Apr 18, 2014 at 5:59 PM, Bruce Brouwer 
 bruce.brou...@gmail.comwrote:

 I'll put together a list of things that I think could be pulled out of
 log4j-core because they are integrations with other tools. Go ahead and
 throw darts, that's what my list is for.

 * log4j-jms
 * log4j-mail
 * log4j-web
 * log4j-jpa
 * log4j-mongodb
 * log4j-couchdb

 Some more questionable ones to pull out
 * log4j-json
 * log4j-yaml



 On Fri, Apr 18, 2014 at 12:39 PM, Gary Gregory 
 garydgreg...@gmail.comwrote:

 On Fri, Apr 18, 2014 at 11:17 AM, Matt Sicker boa...@gmail.comwrote:

 I agree with all that as well. Part of the no more modules problem
 comes from all the unnecessary OSGi modules. I'll be deleting those soon 
 as
 I'm porting over the OSGi metadata to the appropriate modules so that 
 extra
 parallel modules are unneeded.


 That will be good :)

 Gary




 On 17 April 2014 23:48, Ralph Goers ralph.go...@dslextreme.comwrote:

 I agree with you completely.  In fact, the items you have
 specifically identified are where I would start. Are there more?
 Ralph



 On Apr 17, 2014, at 3:21 PM, Bruce Brouwer bruce.brou...@gmail.com
 wrote:

 This discussion about having modules or not having modules keeps
 coming up and I see different opinions here on the log4j team. 
 Generally,
 the argument of please, no more modules has won. I wanted to present 
 my
 perspective to see if I can sway anyone's opinion.

 There are plenty of reasons why projects decide to make more
 modules. Projects like Spring make plenty of modules. As some have 
 noted,
 this can make it difficult to find things sometimes, and I agree. 
 Although
 there are ways around this with search.maven.org, it is still a bit
 of a pain. Some of this can be solved with documentation, some of it is
 probably not necessary for log4j.

 The Spring guys like to break out different modules because of the
 different features (e.g. batch, security, ...). Log4j is probably not 
 big
 enough to warrant breaking it up across feature lines. However, another
 very valid reason to break out modules is for integrations. This is 
 where I
 think log4j should be allowing more modules to be created: log4j-camel,
 log4j-ng-flume, log4j-jms, log4j-web, log4j-mongodb, ...

 I think that this could help, rather than hinder, some of the
 discoverability related to log4j. I do quite frequently find myself 
 seeing
 what is available in Maven central. If I found myself browsing around
 log4j, it could definitely spark some extra interest: Oh, they have
 something specific to JMS?, I'll have to look into that. I might 
 discover
 aspects of log4j that I had not previously considered. Right now, most 
 of
 those are buried inside of the code and the pom dependencies where I'm 
 not
 as likely to investigate further. But having a list of modules named by
 their integration I may get more people excited to use log4j 2. It's 
 about
 advertising.

 Now, maybe my argument doesn't work in my favor regarding
 log4j-streams, but it might if you consider Java's streams as an
 integration. In a way it is.

 In any case, I support the modularization of log4j along integration
 boundaries, which I think would help with osgi as well.



 On Thu, Apr 17, 2014 at 2:39 PM, Matt Sicker boa...@gmail.comwrote:

 Done. Deleted the two modules after branching to
 branches/experimental.


 On 17 April 2014 12:33, Matt Sicker boa...@gmail.com wrote:

 Thanks, Ralph. I'll move the experimental code to a feature branch.


 On 17 April 2014 12:27, Paul Benedict pbened...@apache.orgwrote:

 If you want to retroactively create a branch, and

Re: New log4j-streams Module

2014-04-30 Thread Ralph Goers

That makes a lot of sense to me

Sent from my iPhone

 On Apr 30, 2014, at 6:05 PM, Bruce Brouwer bruce.brou...@gmail.com wrote:
 
 Can we agree to pull out jpa and jms? 
 
 As for web, I know there was some discussion on how we could not register a 
 shutdown hook. If we broke out log4j-web, maybe we could make it as simple as 
 registering a shutdown hook if log4j-web is not included, but if log4j-web 
 was included, the shutdown hook is not registered. It's just an idea. 
 
 
 On Wed, Apr 30, 2014 at 12:22 AM, Matt Sicker boa...@gmail.com wrote:
 I mean I split off log4j-streams and put it in a branch. It being the 
 streams module.
 
 The web stuff actually makes sense to keep in core. JPA and JMS should 
 probably be in their own modules. The syslog stuff could be at least in its 
 own packages but still in log4j-core. I'm unsure about the JSON/YAML ones 
 since they're strictly for configuration and don't really add many classes 
 overall.
 
 
 On 29 April 2014 21:55, Ralph Goers ralph.go...@dslextreme.com wrote:
 What do you mean “you took care of it?” jpa, jms, web as well as the json 
 and yaml support are still in core.  I don’t know that we have agreed to 
 move them out yet.
 
 Ralph
 
 On Apr 29, 2014, at 4:28 PM, Matt Sicker boa...@gmail.com wrote:
 
 I took care of it and added it to the experimental branch in svn (along 
 with a log4j-camel module I was working on).
 
 
 On 29 April 2014 18:18, Bruce Brouwer bruce.brou...@gmail.com wrote:
 Was there any support in creating any of these new modules?
 
 
 On Fri, Apr 18, 2014 at 5:59 PM, Bruce Brouwer bruce.brou...@gmail.com 
 wrote:
 I'll put together a list of things that I think could be pulled out of 
 log4j-core because they are integrations with other tools. Go ahead and 
 throw darts, that's what my list is for. 
 
 * log4j-jms
 * log4j-mail
 * log4j-web
 * log4j-jpa
 * log4j-mongodb
 * log4j-couchdb
 
 Some more questionable ones to pull out
 * log4j-json
 * log4j-yaml
 
 
 
 On Fri, Apr 18, 2014 at 12:39 PM, Gary Gregory garydgreg...@gmail.com 
 wrote:
 On Fri, Apr 18, 2014 at 11:17 AM, Matt Sicker boa...@gmail.com wrote:
 I agree with all that as well. Part of the no more modules problem 
 comes from all the unnecessary OSGi modules. I'll be deleting those 
 soon as I'm porting over the OSGi metadata to the appropriate modules 
 so that extra parallel modules are unneeded.
 
 That will be good :)
 
 Gary
  
 
 
 On 17 April 2014 23:48, Ralph Goers ralph.go...@dslextreme.com 
 wrote:
 I agree with you completely.  In fact, the items you have 
 specifically identified are where I would start. Are there more? 
 Ralph
 
 
 
 On Apr 17, 2014, at 3:21 PM, Bruce Brouwer bruce.brou...@gmail.com 
 wrote:
 
 This discussion about having modules or not having modules keeps 
 coming up and I see different opinions here on the log4j team. 
 Generally, the argument of please, no more modules has won. I 
 wanted to present my perspective to see if I can sway anyone's 
 opinion. 
 
 There are plenty of reasons why projects decide to make more 
 modules. Projects like Spring make plenty of modules. As some have 
 noted, this can make it difficult to find things sometimes, and I 
 agree. Although there are ways around this with search.maven.org, it 
 is still a bit of a pain. Some of this can be solved with 
 documentation, some of it is probably not necessary for log4j. 
 
 The Spring guys like to break out different modules because of the 
 different features (e.g. batch, security, ...). Log4j is probably 
 not big enough to warrant breaking it up across feature lines. 
 However, another very valid reason to break out modules is for 
 integrations. This is where I think log4j should be allowing more 
 modules to be created: log4j-camel, log4j-ng-flume, log4j-jms, 
 log4j-web, log4j-mongodb, ...
 
 I think that this could help, rather than hinder, some of the 
 discoverability related to log4j. I do quite frequently find myself 
 seeing what is available in Maven central. If I found myself 
 browsing around log4j, it could definitely spark some extra 
 interest: Oh, they have something specific to JMS?, I'll have to 
 look into that. I might discover aspects of log4j that I had not 
 previously considered. Right now, most of those are buried inside of 
 the code and the pom dependencies where I'm not as likely to 
 investigate further. But having a list of modules named by their 
 integration I may get more people excited to use log4j 2. It's about 
 advertising.
 
 Now, maybe my argument doesn't work in my favor regarding 
 log4j-streams, but it might if you consider Java's streams as an 
 integration. In a way it is. 
 
 In any case, I support the modularization of log4j along integration 
 boundaries, which I think would help with osgi as well. 
 
 
 
 On Thu, Apr 17, 2014 at 2:39 PM, Matt Sicker boa...@gmail.com 
 wrote:
 Done. Deleted the two modules after branching to 
 branches/experimental.
 
 
 On 17 April 2014 12:33, Matt Sicker

[jira] [Updated] (LOG4J2-609) StatusConfiguration doesn't close files

2014-04-30 Thread Bruce Brouwer (JIRA)


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

Bruce Brouwer updated LOG4J2-609:
-

Attachment: log4j2-609.patch

With log4j2-609.patch, now all tests pass with a clean install on Windows. This 
patch gets into some of the deeper guts of log4j that I haven't had to deal 
with before, so I would appreciate someone vetting what I did. 

But at least all the tests pass, so that's good. 

 StatusConfiguration doesn't close files
 ---

 Key: LOG4J2-609
 URL: https://issues.apache.org/jira/browse/LOG4J2-609
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0-rc1
Reporter: Bruce Brouwer
 Attachments: log4j2-609.patch


 {{org.apache.logging.log4j.core.config.status.StatusConfiguration}} allows 
 you to specify a destination such as out, err or a file name. If 
 specifying a file, that file stream is used when creating a 
 {{StatusConsoleListener}} that is added to the {{StatusLogger}}. Those 
 {{StatusLogger}} listeners are never cleaned up when, for example, the 
 {{XmlConfiguration}} is reconfigured or when the {{LoggerContext}} is shut 
 down (e.g. in {{InitialLoggerContext.apply()}}). This leaves open file 
 handles and is the source of the failing test {{FileOutputTest}} on Windows. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Resolved] (LOG4J2-542) LogEvents with exceptions fail to deserialize


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

Ralph Goers resolved LOG4J2-542.


   Resolution: Fixed
Fix Version/s: 2.0-rc2

Throwable was made transient in revision 1591544. 

 LogEvents with exceptions fail to deserialize
 -

 Key: LOG4J2-542
 URL: https://issues.apache.org/jira/browse/LOG4J2-542
 Project: Log4j 2
  Issue Type: Bug
  Components: Appenders
Affects Versions: 2.0-rc1
Reporter: Joern Huxhorn
Assignee: Ralph Goers
Priority: Critical
 Fix For: 2.0-rc2


 Events serialized by
 Socket name=Socket host=localhost port=4560 protocol=TCP
   SerializedLayout /
 /Socket
 are suddenly containing unchanged serialized exceptions again. This was 
 already working in earlier versions.
 Doing so means that receiving such log-events is impossible if the exception 
 class is not available in the receiving application. This is the main reason 
 for ThrowableProxy.
 This is caused by
 org.apache.logging.log4j.core.impl
 public class ThrowableProxy {
 private final Throwable throwable;
 }
 The throwable field would have to be transient and the info of the Throwable 
 would have to be added to ThrowableProxy. This may be the only necessary 
 change but I'm not sure.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Assigned] (LOG4J2-609) StatusConfiguration doesn't close files