[wildfly-dev] JBAS011592 the logging subsystem requires the log manager to be org.jboss.logmanager.LogManager

[David M. Lloyd]

On 11/24/2014 10:40 AM, Max Rydahl Andersen wrote:
>>>>
>>>> We do not do any agent funkyness afaik.
>>>>
>>>> And as said the "workaround" so far have been "restart it" and it
>>>> works.
>>>>
>>>> zero changes to the state or arguments.
>>>
>>> okey so there been some new movement in this.
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1037970
>>>
>>> Indicating there actually is a race condition if something pings the jvm
>>> via jmx during the startup
>>> *before* jboss main boot process manages to set the logmanager.
>>> Something that will happen because
>>> we actually have a feature that scans for locally running jvm's and
>>> attach an agent to gather info.
>>>
>>> Suggested workaround is to add this to our launch:
>>> JAVA_OPTS="$JAVA_OPTS
>>> -Djava.util.logging.manager=org.jboss.logmanager.LogManager"
>>> JAVA_OPTS="$JAVA_OPTS
>>> -Xbootclasspath/p:$JBOSS_HOME/modules/org/jboss/logmanager/main/jboss-logmanager-1.3.1.Final-redhat-1.jar"
>>>
>>> -logging org.jboss.logmanager.LogManager
>>>
>>> Question from us is, is the above workaround proper ? Will EAP/WildFly
>>> change their boot arguments to match to avoid this race condition issue
>>> for bat/sh launched servers too ?
>>
>> No, there's a very good chance that will cause weird stuff to happen,
>> like two copies of the log manager being installed.  It may work,
>> mostly, but this is not a risk-free solution.
>
> Yeah, that was what I feared...btw. this is what the official
> recommendation is on the knowledge base article about this issue ;/
>
> But can you confirm that the issue is can and will happen if a remote
> process tries to install an agent and even if the agent has zero jboss
> logging usage
> that can somehow result in jboss logging getting activated before it has
> settings configured ?
>
> I'm just wondering what code actually is being invoked that needs this
> log manager when we are installing an agent very early in the start up
> phase ?

Conceptually we don't need or want our log manager to be installed until 
we have something interesting to log.  But, you only get one chance to 
install the log manager, and the JVM initializes it whenever it wants, 
so that's the basic summary of the problem.  The only way to "beat" the 
JVM is to get in there ahead of it.

You could theoretically dig in with reflection and swap out the log 
manager after the fact, but then you'd also have to somehow swap out all 
the loggers made with the original log manager, otherwise what happens 
is some log messages just go missing.

Another option is to install some kind of "proxy" log manager that has a 
facility to swap out all the backing loggers.

>> The "proper fix" is to come up with some kind of agent mode for
>> jboss-modules, but it's not really clear how this can be accomplished
>> without yet more goofy side-effects.
>
> okey ;/
>
> /max
> http://about.me/maxandersen

-- 
- DML