[jboss-jira] [JBoss JIRA] (LOGMGR-120) Thread local log level overriding

[John Mezzetta (JIRA)]

    [ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057493#comment-13057493 ] 

John Mezzetta commented on LOGMGR-120:
--------------------------------------

Hi,

Thiago is away for 6 weeks and I am currently doing characteristics testing on the proposed solution.

>From a performance perspective, the implementation does not satisfy requirements. Essentially, every time a logger object is accessed (even if forceLogging turns out to be false), 5 instances of the jboss Logger class are instantiated (assuming that the category being logged has a name that is 5 deep - i.e. 1.2.3.4.5).  This happens because of this snippet of code in Logger.java:


    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



> Thread local log level overriding
> ---------------------------------
>
>                 Key: LOGMGR-120
>                 URL: https://issues.jboss.org/browse/LOGMGR-120
>             Project: JBoss Log Manager
>          Issue Type: Feature Request
>          Components: core
>    Affects Versions: 1.5.2.Final
>            Reporter: Matthew Robson
>            Assignee: James Perkins
>         Attachments: force_logging.patch
>
>
> Having the ability to force logs down to a filter no matter what the log level is set to.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)