Unnecessary returnValue.toString() invocation in ResultSetSpy.reportAllReturns()

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Configure log4jdbc-log4j with OFF loggers
2. Execute high load with select queries on DataSourceSpy
3. look at profiler 

What is the expected output? What do you see instead?
I expect NO CPU utilization by ResultSetSpy. But I see a lot of CPU grabbed by 
ResultSetSpy

What version of the product are you using? On what operating system?
1.16

Please provide any additional information below.
It is due to redundant returnValue.toString() in 
ResultSetSpy.reportAllReturns() method(ResultSetSpy.java:111). It needs to be 
wrapped by condition and to be executed only if necessary.

Original issue reported on code.google.com by [email protected] on 31 Jan 2014 at 9:44

[GoogleCodeExporter]

Actually it would be better to make Slf4jSpyLogDelegator.methodReturned() 
accept "Object returnMsg" and convert it into the String inside of 
"if(logger.isInfoEnabled())" instead of accepting "String returnMsg".

Original comment by [email protected] on 31 Jan 2014 at 9:51

[GoogleCodeExporter]

Hmm, I agree with your suggestions, but it would impact existing code a lot: I 
would need to go through all the "historical" log4jdbc code, using the 
`reportReturn` methods; also I would need to modify the signature of the 
SpyLogDelegator interface, which will break existing applications with custom 
SpyLogDelegators.

But I agree that this is a required modification, I just need to think about it 
a bit more.

In the meantime, are you sure that all your loggers are off? Because in that 
case, DataSourceSpy is supposed to return the real JDBC connection, not wrapped 
into a ConnectionSpy (see the condition `if 
(spyLogDelegator.isJdbcLoggingEnabled())` in the `getConnection` methods. You 
shouldn't see any use of ResultSetSpy. 

Original comment by [email protected] on 11 Feb 2014 at 4:59

• Changed state: Accepted
• Added labels: Performance
• Removed labels: Type-Defect

[GoogleCodeExporter]

Probably one logger is set up with ERROR level

Original comment by [email protected] on 1 Apr 2014 at 5:11