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

On Nov 24, 2014, at 8:20 AM, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: On 11/24/2014 06:34 AM, Max Rydahl Andersen wrote: > On 20 Oct 2014, at 11:20, Max Rydahl Andersen wrote:> On 20 Oct 2014, at > 1:48, James R. Perkins wrote: >> >>> As Stuart asked more details would help. >>> >>> The only way this could happen is if something, an agent for example, >>> attempts to get a logger before JBoss Modules initializes logging. >>> JBoss Modules looks for a META-INF/services/ >>> java.util.logging.LogManager service which JBoss Log Manager has. If >>> an agent needs to be used the java.util.logging.manager needs to be >>> set to org.jboss.logmanager.LogManager before the agent initializes a >>> logger. >> >> It is all in the jira. >> >> And no, these errors have been happening on what is just plain vanilla >> WildFly or EAP/JPP bundles. >> >> 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. 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. -- - DML