hey all, I'm just getting started with c3p0 for database connection pooling. It's attaching itself to my log4j output currently. How do I set logging off or at least to SEVERE level only for c3p0? I tried tweaking the properties file but not sure it's being picked up properly.
any ideas on how best to turn it off?
thanks
UPDATE:
this seems to work in the log4j.properties file
log4j.logger.com.mchange.v2.c3p0.impl=INFO
log4j.logger.com.mchange=INFO
For those who are NOT using a configuration file, just to add the following in the code, before loading the connection pool.
Properties p = new Properties(System.getProperties());
p.put("com.mchange.v2.log.MLog", "com.mchange.v2.log.FallbackMLog");
p.put("com.mchange.v2.log.FallbackMLog.DEFAULT_CUTOFF_LEVEL", "OFF"); // Off or any other level
System.setProperties(p);
If you use a log4j.xml file you can simple define a logger for the c3po package:
<logger name="com.mchange.v2.c3p0">
<level value="SEVERE"/>
</logger>
There are analogous methods for log4j.properties. I think it's just:
log4j.logger.com.mchange.v2.c3p0=SEVERE
I was getting messages like the following:
Tue Feb 12 13:42:01 EST 2013 INFO: Profiler Event: [FETCH] at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeQuery(NewProxyPreparedStatement.java:76) duration: 0 ms, connection-id: 67, statement-id: 23, resultset-id: 27
This made me think that C3P0 was logging these messages. Actually the message is coming from the mysql connector because I enabled profiling by using a connection string like this:
jdbc:mysql://localhost/database?profileSQL=true
Remove ?profileSQL=true to make it stop logging these messages.
I fixed problem with line of code:
com.mchange.v2.log.MLog.getLogger().setLevel(MLevel.INFO);
I am using log4j in my app.
You can set log level by adding following lines in log4j.xml
Logging at least at Error level is desired.
< category name="com.mchange" additivity="false">
< priority value="ERROR"/>
< appender-ref ref="ASYNC"/>
</ category>
If you really want to turn off c3P0 logging set property com.mchange.v2.log.FallbackMLog.DEFAULT_CUTOFF_LEVEL=OFF
in c3p0-Config.properties
or you can directly set this in code as an System property System.setProperty("com.mchange.v2.log.FallbackMLog.DEFAULT_CUTOFF_LEVEL",MLevel.OFF);
I am working on clojure, through korma and for the life of my I could not get any properties files to load (I am new to clojure so I blame myself). If you are in a similar boat, the following might help you out.
(System/setProperties
(doto (java.util.Properties. (System/getProperties))
(.put "com.mchange.v2.log.MLog" "com.mchange.v2.log.FallbackMLog")
(.put "com.mchange.v2.log.FallbackMLog.DEFAULT_CUTOFF_LEVEL" "OFF")))
The is basically a clojure port of Philippe Carriere's answer above, thank you so much!
Related
I'm using Alluxio 2.0 to accelerate compute layer's performance.
When no query is performing, I found there are about verbose netty output appendding to $Alluxio_home/logs/master.log.
2019-11-25 10:26:32,141 DEBUG NettyServerHandler - {} {} HEADERS: streamId={} headers={} streamDependency={} weight={} exclusive={} padding={} endStream={}
2019-11-25 10:26:32,141 DEBUG NettyServerHandler - {} {} DATA: streamId={} padding={} endStream={} length={} bytes={}
Dozens of above message are appeneded to master.log each second.
Is it a normal behavior? If sure, what's it used for? For heartbeat amoung components?
I found the root cause, leave this thread here for anyone who might encounter the same problem.
The Alluxio is using gRPC as its RPC framework and the latter is based on netty, the verbose output is actually from netty, check this thread for details.
To disable the verbose output from Alluxio side, add below statement to $Alluxio_home/conf/alluxio-site.properties:
log4j.logger.io.grpc.netty.NettyServerHandler=OFF
Note that modify log4j.rootLogger of alluxio-propeties can't disable this verbose output.
Currently I have two maps in hazelcast, and they are configured like so:
<hz:map name="some-map"
max-idle-seconds="0"
time-to-live-seconds="0">
<hz:map-store enabled="true"
initial-mode="EAGER"
write-delay-seconds="0"
class-name="SomeMapStore">
</hz:map-store>
<hz:partition-strategy>com.hazelcast.partition.strategy.DefaultPartitioningStrategy</hz:partition-strategy>
</hz:map>
I would expect the initial-mode="EAGER" from the hazelcast-beans.xml configuration to populate the hazelcast map. Instead the application process hangs for a moment, and then I see the following error:
my-service 21:14:15.247Z [hz.my-service-name.SlowOperationDetectorThread] WARN com.hazelcast.spi.impl.operationexecutor.slowoperationdetector.SlowOperationDetector - [localhost]:8085 [my-service-name-local] [3.9.4] Slow operation detected: com.hazelcast.map.impl.operation.PutTransientOperation
Has anyone run into this? I'm on hazelcast 3.9.4
I'm using log4j 2 with a pattern layout that highlights different log levels. In my code, I specify a custom level. When this level is logged, it's not colored and shows null before the level in the log. Below is my pattern and log snip.
Custom level:
final Level STATS = Level.forName("STATS", 510);
Pattern:
%highlight{%-10.10level}{FATAL=red, ERROR=red, WARN=yellow, INFO=green, DEBUG=blue, TRACE=blue, STATS=red}
Output:
Jul 22 15:36:00 INFO [qtp982337150-23] c.e.class : Logging an info line
Jul 22 15:36:00 nullSTATS [qtp982337150-23] c.e.class : Logging a stats line
You may have found a bug. Please raise this on the Log4j2 JIRA issue tracker.
I found the same problem with log levels from jul.
I filed an issue in jira for that: https://issues.apache.org/jira/browse/LOG4J2-2405
This seems to be the same problem.
UPDATE 2018-10-24:
I have prepared a Pull Request that fixes this problem. Hopefully this will be included in Log4j2 soon.
I'm using logback and the JUL to SLF4J bridge (the latter for capturing third party libraries log statements that use Java Logging).
I get the log output from the third parties, but the logging pattern isn't what I specified for Logback. Should JUL and Logback use the same pattern that I specified in my logback.xml? Or do I need to set JUL separately? And finally, if I need to set JUL separately, is there a way to have a single place to define my log output pattern and have that go to JUL and Logback?
The setup I have looks like this:
In my main class I have a static block (at the top of the class) with these lines:
SLF4JBridgeHandler.removeHandlersForRootLogger();
SLF4JBridgeHandler.install();
My logback.xml looks like this:
<configuration>
<contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator"/>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<Pattern>
%d{HH:mm:ss.SSS} [%-32thread] %-5level | %-80msg | %class.%method\(%file:%line\)%n
</Pattern>
</encoder>
</appender>
<root level="WARN">
<appender-ref ref="STDOUT"/>
</root>
</configuration>
Below are two lines of log output that I copied. You'll notice the first line is per the format I specified and the second line is not (because it is coming from JUL):
21:06:33.297 [ModelUpdateThread-1 ] INFO | view Molecules and Complexes took 1 ms for 17116 model elements | com.**[blanked out for privacy]**
Sat Nov 21 21:06:33 EST 2015 : com.tomsawyer.licensing.TSILicenseManager - setUseProxy
INFO: setUseProxy: false
Patterns set in Logback should be automatically applied to JUL... or rather, since the JUL log records are handed off to Logback for logging the pattern will apply.
The problem I was seeing turned out to be because the third party library (from tomsawyer) was by default writing its logs to both stdout and JUL. That is... Tomsawyer was using System.out to write log messages in addition to Logger.info. The clue that this was happening resides in the log level of my configuration (warn) and the output log level from Tomsawyer (info).
So indeed the Tomsawyer output was being sent to logback and then suppressed because the log level was configured at warn. And since Tomsawyer was also outputting to stdout with System.out... I still saw the message.
Does logging decreases application performance?
and how to restrict display-tags logs to be printed in log files?
eg. my log file has below logs
[2012-06-20 15:52:06,290] org.displaytag.tags.TableTag isFirstIteration 684 - [data] first iteration=true (row number=1)
[2012-06-20 15:52:06,290] org.displaytag.tags.TableTag isFirstIteration 684 - [data] first iteration=true (row number=1)
[2012-06-20 15:52:06,290] org.displaytag.tags.TableTag isFirstIteration 684 - [data] first iteration=true (row number=1)
[2012-06-20 15:52:06,290] org.displaytag.tags.TableTag isFirstIteration 684 - [data] first iteration=true (row number=1)
why the above is in log file?
log.properties file
# Log4j configuration file.
log4j.rootCategory=DEBUG, A1
# Available levels are DEBUG, INFO, WARN, ERROR, FATAL
#
# A1 is a ConsoleAppender
#
log4j.appender.A1 = org.apache.log4j.RollingFileAppender
log4j.appender.A1.File = C:/LogInfo/logfile.log
log4j.appender.A1.MaxFileSize = 100MB
log4j.appender.A1.MaxBackupIndex=50
log4j.appender.A1.layout = org.apache.log4j.PatternLayout
log4j.appender.A1.append = true
log4j.appender.A1.layout.ConversionPattern = [%d] %C %M %L - %m%n
log4j.appender.A1.Threshold = DEBUG
how to stop (org.displaytag.tags.TableTag) these kind of logs to be printed in log files
Does logging decreases application performance?
Yes. How much it does depends on a number of factors; see below.
and how to restrict display-tags logs to be printed in log files?
By changing the ConversionPattern in the logging properties
why the above is in log file?
Because:
somewhere in the code is a call to a Logger method (probably debug(String)) with that message, and
your logging properties set the logging Threshold to DEBUG for the appender.
To improve performance:
change the ConversionPattern to use less expensive date/time formatting, and (more importantly) avoid 'C', 'F', 'L' and 'M' because they are particularly expensive.
change the logging Threshold to INFO or WARNING or ERROR to reduce the amount of logging,
put the Logger.debug(...) call inside an if statement that checks that debug logging is enabled. This saves the cost of assembling the log message in cases where it won't be needed; see In log4j, does checking isDebugEnabled before logging improve performance?.
with log4j version 2 (log4j2), there are overloads that on the logging methods that take a format and parameters. These reduce the overhead when a logging at a level that is disabled.
look also at logback and log4j 2.0.
You can also throttle logging at the Logger level ... as described in the log4j documentation. In fact, the documentation answers most of the questions that you asked, and has a lot of detail on the topics of logging performance and logging configuration.
Short answer: yes, it decreases application performance as it uses some CPU cycles and other resources (memory, etc).
See also this question : log4j performance
Logging can be 30% of you cpu time or more. In terms of jitter, it as large (and more often) than your GC delays.
A simple way to reduce overhead is to use the Pattern to turn off where you are logging each message from. In your case this is %C %M and %L as it has to take a stack trace (of the entier stack) to get this information.
Yes they do. That's why you should only log an error or something that must absolutely be logged. You can also log information helpful for debugging in the debug channel so it won't affect production performance.
how about?
log4j.category.org.displaytag.tags.TableTag=ERROR, A1
You can restrict junk logs like this.
Set the root logger as INFO so that unnecessary debug logs won't come and fill up your log file.
log4j.rootCategory=INFO, A1
If you want specific class or package to give out DEBUG logs you can do it like this.
log4j.logger.org.hibernate.event.def.DefaultLoadEventListener=DEBUG,A1
The above will print DEBUG level logs from the class DefaultLoadEventListener in your log file along with other INFO level logs.