Affects: \v5.2.9.RELEASE
CPU profiling of some fairly high HTTP traffic spring Webflux (on Tomcat) applications has shown between ~3-10% of time (in aggregate) spent in org.apache.commons.logging.LogFactory.getLog calls made from the following locations:
Based on my initial inspection, some of these loggers may be unused in spring-framework code. Comments suggest in at least some of the cases that the loggers are intentionally available for use by subclasses (though I haven't seen any such usage in the spring-framework included subclasses that are in play in my specific stack traces).
I think the most typical pattern is to use static constants to refer to Loggers (since their construction is relatively expensive). Is there good reason for these Loggers to be instance members instead in these cases? If so, I wonder if it could be made configurable such that applications that aren't interested in these loggers can avoid spending time constructing them? I looked for an existing way to configure this, but wasn't able to find anything.
Affects: \v5.2.9.RELEASE
CPU profiling of some fairly high HTTP traffic spring Webflux (on Tomcat) applications has shown between ~3-10% of time (in aggregate) spent in org.apache.commons.logging.LogFactory.getLog calls made from the following locations:
Based on my initial inspection, some of these loggers may be unused in spring-framework code. Comments suggest in at least some of the cases that the loggers are intentionally available for use by subclasses (though I haven't seen any such usage in the spring-framework included subclasses that are in play in my specific stack traces).
I think the most typical pattern is to use
staticconstants to refer to Loggers (since their construction is relatively expensive). Is there good reason for these Loggers to be instance members instead in these cases? If so, I wonder if it could be made configurable such that applications that aren't interested in these loggers can avoid spending time constructing them? I looked for an existing way to configure this, but wasn't able to find anything.