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