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

[Max Rydahl Andersen]

On 24 Nov 2014, at 17:48, David M. Lloyd wrote:

> 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.

and I assume there are some reason why the logmanager don't have a 
fallback default it will use until its fully configured ?  (i.e. to 
avoid this racecondition to result in full error/stopping of the server)

/max
http://about.me/maxandersen