[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=13057781#comment-13057781 ] 

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

Hi David,

Thanks for the quick response. I reread your comments and agree with them 100%. The thing that stands out the most is the fact that you were concerned with "thread local access is very slow compared to our existing volatile int read". This is exactly the type of discussion that we had when assessing the performance characteristics. However, the current proposed implementation isn't even close to this level of performance, as I describe above.

In terms of a final solution, i don't think that the jboss log manager (the system, not the class) should store the thread local boolean to force logging. I am not sure if that is being considered, but in case it is let me explain why it would not be good for us. 

Under such a system, the log manager would (typically) provide an accessor and mutator method to manipulate the thread local force logging flag. Although this would be the safest implementation from the jboss perspective (since the performance would be deterministic), i don't think the system would work, at least from the perspective of our requirements. 

The reason for this is that when a new context begins use of a thread (i.e. doGet() servlet method is called), the force logging criteria need to be established and an algorithm needs to be executed to determine if the force logging flag is set to true or false. This algorithm is expensive, so it should only be executed once and its result should be cached for the duration of the context thread execution.

To make the API for this system small and clean, we do not expose any methods to explicitly execute the algorithm. We do it automatically when the first log record is output (for the context). That is why we need the jboss log manager to invoke the forceLogging() method that we implement. We rely on the jboss logging manager to trigger the execution of the algorithm (and the subsequent cacheing), as opposed to exposing and API method to explicitly trigger the algorithm and set the thread local flag in the jboss log manager. This makes the system more robust and simpler to use.

Invoking a forceLogging() method is the only real "low level" requirement that we have. The rest are just implementation details and anything that is efficient and cohesive would suffice. The implementation i describe above captures this requirement in the most succinct and efficient way possible. 

Actually, to prototype things and assess performance, i would likely not even implement the SPI lookup, but rather put a setter method in the jboss log manager (the class) to register the implementation. This is not really the greatest approach since the registration of the implementor of the forceLogging() method will come much later in the system, but it should be good enough for our specific purposes.

And i don't expect the proposed implementation to be taken as a contribution; it is only meant to communicate our low level technical requirements. The reality is that the production solution needs to interface with the jboss cli in some way so that a regular user can specify things in the usual way. I am not even attempting to describe this solution...

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)