[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] John Mezzetta commented on LOGMGR-120: -------------------------------------- Hi, Thiago is away for 6 weeks and I am currently doing characteristics testing on the proposed solution. private boolean forceLogging() { if (!FORCING_LOG_CHECKER.isForcingLogFeatureEnabled()) { return false; } final CheckForceLogCallback result = loggerNode.getCheckForceLogCallback(); if (result != null) { return result.isForcingLog(); } final Logger parent = getParent(); return parent != null && parent.forceLogging(); } The call to getParent is a problem. It causes the instantiation of a new logger object. And it is recursive to the root, so multiple objects are created per call. In my test app, if traffic is light, the problem is not noticed. but under heavy logger use, it seems that all of these objects cannot be GCed fast enough because they have a finalize method. Regardless, the implementation is far too inefficient. We cannot have so many method invocations and object instantiations per logger call. Basically, the requirement was to have an extra 2 or 3 high level instructions per logger call to determine if forcelogging is on. And this was on both sides, not just the jboss side. The current implementation is in the 50-100 range on the jboss side alone. The proposal to fix this would be: 1. create a static method in a class (LogManager.java?) for the "forceLogging() method. 2. when the LogManager initiaizes, it needs to perform an SPI lookup for implementors of the org.jboss.logmanager.CheckForceLogCallback interface. We would provide that implementor (and deal with the obvious classpath issues by modifying the jboss loggin module.xm). If there are no implementors found in the SPI lookup, the forceLogging() method would return false. This would effectively mean the feature is disabled. If an implementation is found, the forceLogging() method is passed though to the implementation. 3. this means that the forceLogging method above would be replaced by a call to the static method in LogManager. And when the feature is disabled, LogManager would return a local Boolean. While a productified version of this feature would probably be different, this would be the most concise and efficient implementation that would satisfy our requirements. What do you think? Regards, John -- This message was sent by Atlassian JIRA (v6.3.11#6341)