log4j2 Ausnahme: FEHLER Die Registrierung von MBeans für org.apache.logging.log4j2 konnte nicht aufgehoben werden: type = AsyncContext @ 694ae32f, component = AsyncLoggerRingBuffer

Question

Ich sehe eine Ausnahme beim Start von weblogic 10.3.x Anwendung. Log4j2 Version: 2.6.1

Unten erwähnt log4j XML-Konfiguration verwende ich und StackTrace.

Log4j2.xml

<?xml version="1.0" encoding="UTF-8"?> 
<Configuration status="INFO" > 
     <Properties> 
     <Property name="theHostName">${hostName}</Property> 
     </Properties> 
     <Appenders> 
      <RollingFile name="FILE" filename="${sys:weblogic.Name}.log" filepattern="${sys:weblogic.Name}.log.%i" append="true" > 
       <PatternLayout pattern="[%-5p][%d{yyyy-MM-dd HH:mm:ss,SSS}][${sys:weblogic.Name}:${hostName}][%t][%X{MessageInfo}][%c{1}:%M:%L][%msg]%n" /> 
       <Policies> 
        <SizeBasedTriggeringPolicy size="50 MB" /> 
       </Policies> 
       <DefaultRolloverStrategy max="100" fileIndex="min"/> 
      </RollingFile> 
     </Appenders> 
     <Loggers> 
      <AsyncLogger level="INFO" name="com.company" includeLocation="true" additivity="false"> 
       <AppenderRef ref="FILE"/> 
      </AsyncLogger> 
      <Root level="INFO" includeLocation="true"> 
       <AppenderRef ref="FILE"/> 
      </Root> 
      <!-- Package specific log level defines --> 
      <Logger level="WARN" name="org.springframework" /> 
      <Logger level="WARN" name="org.jboss" /> 
      <Logger level="OFF" name="org.hibernate" /> 
      <Logger level="WARN" name="com.company.project.eligibility" /> 
     </Loggers> 
</Configuration> 

Exception auftritt am Anfang des Serverstarts:

2016-08-26 02:19:15,172 [ACTIVE] ExecuteThread: '13' for queue: 
'weblogic.kernel.Default (self-tuning)' ERROR Could not 
unregister MBeans for org.apache.logging.log4j2:type=AsyncContext@694ae32f, 
component=AsyncLoggerRingBuffer javax.management.InstanceNotFoundException: 
org.apache.logging.log4j2:type=AsyncContext@694ae32f, 
component=AsyncLoggerRingBuffer 
     at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) 
     at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(DefaultMBeanServerInterceptor.java:427) 
     at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:415) 
     at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:546) 
     at org.apache.logging.log4j.core.jmx.Server.unregisterAllMatching(Server.java:335) 
     at org.apache.logging.log4j.core.jmx.Server.unregisterAsyncLoggerRingBufferAdmins(Server.java:316) 
     at org.apache.logging.log4j.core.jmx.Server.unregisterLoggerContext(Server.java:258) 
     at org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:162) 
     at org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:138) 
     at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:502) 
     at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:561) 
     at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:577) 
     at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:212) 
     at org.apache.logging.log4j.core.async.AsyncLoggerContext.start(AsyncLoggerContext.java:75) 
     at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152) 
     at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45) 
     at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194) 
     at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551) 
     at com.company.tns.netmessage.bean.NetMessageListener.<clinit>(NetMessageListener.java:55) 
     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) 
     at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) 
     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) 
     at java.lang.reflect.Constructor.newInstance(Constructor.java:526) 
     at java.lang.Class.newInstance(Class.java:383) 
     at com.oracle.pitchfork.spi.bean.internal.GeneralBeanManager.getBean(GeneralBeanManager.java:22) 
     at com.oracle.pitchfork.spi.EjbComponentCreatorBrokerImpl.getBean(EjbComponentCreatorBrokerImpl.java:82) 
     at weblogic.ejb.container.injection.EjbComponentCreatorImpl.getBean(EjbComponentCreatorImpl.java:57) 
     at weblogic.ejb.container.manager.BaseEJBManager.createNewBeanInstance(BaseEJBManager.java:220) 
     at weblogic.ejb.container.manager.BaseEJBManager.allocateBean(BaseEJBManager.java:235) 
     at weblogic.ejb.container.manager.MessageDrivenManager.createBean(MessageDrivenManager.java:301) 
     at weblogic.ejb.container.pool.MessageDrivenPool.createBean(MessageDrivenPool.java:174) 
     at weblogic.ejb.container.pool.Pool.createInitialBeans(Pool.java:299) 
     at weblogic.ejb.container.manager.MessageDrivenManager.start(MessageDrivenManager.java:655) 
     at weblogic.ejb.container.deployer.MessageDrivenBeanInfoImpl$DestinationResovler.activateNoneDDMDManager(MessageDrivenBeanInfoImpl.java:2356) 
     at weblogic.ejb.container.deployer.MessageDrivenBeanInfoImpl$QueueConnectionHandler.handleNoneDD(MessageDrivenBeanInfoImpl.java:2798) 
     at weblogic.ejb.container.deployer.MessageDrivenBeanInfoImpl$DestinationResovler.resolveDestnationWorkMode(MessageDrivenBeanInfoImpl.java:2289) 
     at weblogic.ejb.container.deployer.MessageDrivenBeanInfoImpl$DestinationEventHandler.onDestinationsAvailable(MessageDrivenBeanInfoImpl.java:2112) 
     at weblogic.jms.extensions.JMSDestinationAvailabilityHelper$DestinationAvailabilityListenerWrapper$2.run(JMSDestinationAvailabilityHelper.java:386) 
     at weblogic.jms.extensions.JMSDestinationAvailabilityHelper$DestinationAvailabilityListenerWrapper.callOutListener(JMSDestinationAvailabilityHelper.java:402) 
     at weblogic.jms.extensions.JMSDestinationAvailabilityHelper$DestinationAvailabilityListenerWrapper.onDDMembershipChange(JMSDestinationAvailabilityHelper.java:383) 
     at weblogic.jms.common.CDS$DD2Listener.run(CDS.java:1264) 
     at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545) 
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256) 
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:221) 

Was bedeutet der Cryptic Fehler, und wie kann ich es beheben?

Answer 1

Der Fehler bedeutet Weblogic barfed, wenn log4j versuchte, eine JMX-MBean, die nicht registriert wurde, abzumelden.

Log4j fängt diesen Fehler ab und protokolliert ihn auf ERROR-Ebene einschließlich des Stack-Trace. Die Anwendung arbeitet dann weiter. Es gibt also kein echtes Problem und das ist mehr wie ein lauter Alarm.

Sie können versuchen, das Rauschen zu reduzieren, indem Sie log4j anweisen, JMX zu deaktivieren, indem Sie die Systemeigenschaft log4j2.disable.jmx=true setzen.

Darüber hinaus könnte man argumentieren, dass log4j die Fehlerbehandlung ändern sollte, um eine weniger gruselig aussehende Nachricht anzuzeigen. Sie können diese Änderung im log4j2 Jira Issue Tracker anfordern.

---

Update:

Ich hob https://issues.apache.org/jira/browse/LOG4J2-1581 für dieses Problem. Dies ist jetzt im Master behoben und wird in der nächsten Version Log4j 2.7 enthalten sein.