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

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.