Author |
Message
|
KIT_INC |
Posted: Thu Feb 15, 2018 12:00 pm Post subject: LOG4J2 used for IIB logging |
|
|
Knight
Joined: 25 Aug 2006 Posts: 589
|
I have seen couple of comments on Log4j in this forum
Quote: |
Best practice says use java.util.logging and not log4j ,
Log4j and Broker should be consigned to the trashcan
|
Our developers are proposing to do message and error logging using Log4j2. The new message flow can have multi-instances , they claim that the new Log4j2 with Asynchronous logger or Appender can greatly reduce the logging latency. Can the Asynchronous logger assure no loss of data ?
If Log4j2 is not the right way to go, I need some documentation to support my argument. Can some one point me to the best practice document that says "use java.util.logging and not log4j " Also any discussion on using the Asynchronous logger or Appender with IIB V10 on Linux or AIX. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Feb 15, 2018 12:11 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
IMHO those comments were specific to log4j rather than log4j2, which is a whole new ball game,to the point there's limited backwards compatibility:
Quote: |
The API for Log4j 2 is not compatible with Log4j 1.x, however an adapter is available to allow applications to continue to use the Log4j 1.x API |
(https://logging.apache.org/log4j/2.x/)
If, as with all new major releases, this is now better/faster/glossier/smarter then maybe it's time to review. As a totally non-Java person, I was struck by this:
Quote: |
The JDK Logging Adapter is a custom implementation of java.util.logging.LogManager that uses Log4j |
(https://logging.apache.org/log4j/2.0/log4j-jul/index.html)
So maybe the "this one or that one" discussion is now moot. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Feb 15, 2018 12:13 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
I also thought this was interesting. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
souciance |
Posted: Thu Feb 15, 2018 12:46 pm Post subject: |
|
|
Disciple
Joined: 29 Jun 2010 Posts: 169
|
By the way, we used the IBM support back for log4j loggning i.e. the log4j node. Be very careful how you set that up. My advice is to have one brokerlog.xml per execution group. Otherwise you end up in messy file locks and the rolling file appender will not function correctly. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Feb 15, 2018 12:57 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
souciance wrote: |
By the way, we used the IBM support back for log4j loggning i.e. the log4j node. Be very careful how you set that up. My advice is to have one brokerlog.xml per execution group. Otherwise you end up in messy file locks and the rolling file appender will not function correctly. |
They talk about that on the Apache site - how log44j sucked in a multi-threaded environment but log4j2 does better Java thread stuff.
Behold my awesome grasp of Java, complemented by my awesome ability to parrot things I've read on a web site!  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
souciance |
Posted: Fri Feb 16, 2018 3:13 am Post subject: |
|
|
Disciple
Joined: 29 Jun 2010 Posts: 169
|
Vitor wrote: |
souciance wrote: |
By the way, we used the IBM support back for log4j loggning i.e. the log4j node. Be very careful how you set that up. My advice is to have one brokerlog.xml per execution group. Otherwise you end up in messy file locks and the rolling file appender will not function correctly. |
They talk about that on the Apache site - how log44j sucked in a multi-threaded environment but log4j2 does better Java thread stuff.
Behold my awesome grasp of Java, complemented by my awesome ability to parrot things I've read on a web site!  |
 |
|
Back to top |
|
 |
|