weblogic threads FAT LOCK weblogic.socket.Muxer STUCK BEA-002936最大线程约束已达到ClusterMessaging

时间：2017-12-08 13:47:04

标签： weblogic weblogic11g

我刚刚在我的weblogic服务器10.3.6“”

上发了一些随机警报

在完整的线程转储中，我有（活动状态）

带有FAT LOCK的这个堆栈的264个线程：

    "[ACTIVE] ExecuteThread: '100' for queue: 'weblogic.kernel.Default (self-tuning)'": non-Java thread
    "[ACTIVE] ExecuteThread: '101' for queue: 'weblogic.kernel.Default (self-tuning)'": non-Java thread
    "[ACTIVE] ExecuteThread: '102' for queue: 'weblogic.kernel.Default (self-tuning)'": non-Java thread

each ExecuteThread have the same thing:

"[ACTIVE] ExecuteThread: '110' for queue: 'weblogic.kernel.Default (self-tuning)'" id=842 idx=0x48 tid=28341 prio=5 alive, waiting, native_blocked, daemon
    -- Waiting for notification on: weblogic/work/ExecuteThread@0xa03777f0[fat lock]
    at jrockit/vm/Threads.waitForNotifySignal(JLjava/lang/Object;)Z(Native Method)
    at jrockit/vm/Locks.wait(Locks.java:1973)[inlined]
    at java/lang/Object.wait(Object.java:485)[inlined]
    at weblogic/work/ExecuteThread.waitForRequest(ExecuteThread.java:205)[inlined]
    at weblogic/work/ExecuteThread.run(ExecuteThread.java:233)[optimized]
    ^-- Lock released while waiting: weblogic/work/ExecuteThread@0xa03777f0[fat lock]
    at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)
    -- end of trace

"Thread-1" id=11 idx=0x4c tid=16134 prio=5 alive, sleeping, native_waiting, daemon
    at java/lang/Thread.sleep(J)V(Native Method)
    at com/singularity/util/org/apache/log4j/helpers/FileWatchdog.run(FileWatchdog.java:104)
    at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)
    -- end of trace

"[ACTIVE] ExecuteThread: '103' for queue: 'weblogic.kernel.Default (self-tuning)'" id=850 idx=0x50 tid=28350 prio=5 alive, waiting, native_blocked, daemon
    -- Waiting for notification on: weblogic/work/ExecuteThread@0x9cf6ba30[fat lock]
    at jrockit/vm/Threads.waitForNotifySignal(JLjava/lang/Object;)Z(Native Method)
    at jrockit/vm/Locks.wait(Locks.java:1973)[inlined]
    at java/lang/Object.wait(Object.java:485)[inlined]
    at weblogic/work/ExecuteThread.waitForRequest(ExecuteThread.java:205)[inlined]
    at weblogic/work/ExecuteThread.run(ExecuteThread.java:233)[optimized]
    ^-- Lock released while waiting: weblogic/work/ExecuteThread@0x9cf6ba30[fat lock]
    at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)
    -- end of trace

其中一些（7）处于待机状态，这个完整堆栈有FAT LOCK：

"[STANDBY] ExecuteThread: '105' for queue: 'weblogic.kernel.Default (self-tuning)'" id=852 idx=0x6c tid=28352 prio=5 alive, waiting, native_blocked, daemon
    -- Waiting for notification on: weblogic/work/ExecuteThread@0xa02d3520[fat lock]
    at jrockit/vm/Threads.waitForNotifySignal(JLjava/lang/Object;)Z(Native Method)
    at jrockit/vm/Locks.wait(Locks.java:1973)[inlined]
    at java/lang/Object.wait(Object.java:485)[inlined]
    at weblogic/work/ExecuteThread.waitForRequest(ExecuteThread.java:205)[inlined]
    at weblogic/work/ExecuteThread.run(ExecuteThread.java:233)[optimized]
    ^-- Lock released while waiting: weblogic/work/ExecuteThread@0xa02d3520[fat lock]
    at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)
    -- end of trace

一个线程处于“STUCK”状态，有这个堆栈：

"[STUCK] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'": non-Java thread
    at jrockit/vm/Threads.waitForNotifySignal(JLjava/lang/Object;)Z(Native Method)
    at java/lang/Object.wait(J)V(Native Method)
    at weblogic/rjvm/ResponseImpl.waitForData(ResponseImpl.java:90)
    at weblogic/rjvm/ResponseImpl.retrieveThreadLocalContext(ResponseImpl.java:153)
    at weblogic/messaging/dispatcher/DispatcherProxy.unmarshalResponse(DispatcherProxy.java:241)
    at weblogic/messaging/dispatcher/DispatcherProxy.dispatchSyncTranFuture(DispatcherProxy.java:134)
    at weblogic/messaging/dispatcher/DispatcherWrapperState.dispatchSyncTran(DispatcherWrapperState.java:334)
    at weblogic/messaging/dispatcher/DispatcherWrapperState.dispatchSyncNoTran(DispatcherWrapperState.java:381)
    at weblogic/messaging/dispatcher/DispatcherWrapperState.dispatchSync(DispatcherWrapperState.java:249)
    at weblogic/jms/dispatcher/DispatcherAdapter.dispatchSync(DispatcherAdapter.java:43)
    at weblogic/jms/frontend/FEConsumer.<init>(FEConsumer.java:296)
    at weblogic/jms/frontend/FESession$2.run(FESession.java:1076)
    at weblogic/security/acl/internal/AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
    at weblogic/security/service/SecurityManager.runAs(SecurityManager.java:146)
    at weblogic/jms/frontend/FESession.consumerCreate(FESession.java:1072)
    at weblogic/jms/frontend/FESession.invoke(FESession.java:3027)
    at weblogic/messaging/dispatcher/Request.wrappedFiniteStateMachine(Request.java:961)
    at weblogic/messaging/dispatcher/DispatcherImpl.syncRequest(DispatcherImpl.java:185)
    at weblogic/messaging/dispatcher/DispatcherImpl.dispatchSync(DispatcherImpl.java:220)
    at weblogic/jms/dispatcher/DispatcherAdapter.dispatchSync(DispatcherAdapter.java:43)
    at weblogic/jms/client/JMSSession.consumerCreate(JMSSession.java:3017)
    at weblogic/jms/client/JMSSession.setupConsumer(JMSSession.java:2775)
    at weblogic/jms/client/JMSSession.createConsumer(JMSSession.java:2717)
    at weblogic/jms/client/JMSSession.createDurableSubscriber(JMSSession.java:2513)
    at weblogic/ejb/container/internal/JMSConnectionPoller.setUpTopicSessionAt(JMSConnectionPoller.java:1530)
    at weblogic/ejb/container/internal/JMSConnectionPoller.setUpTopicSessions(JMSConnectionPoller.java:1316)
    at weblogic/ejb/container/internal/JMSConnectionPoller.createJMSConnection(JMSConnectionPoller.java:2311)
    at weblogic/ejb/container/internal/JMSConnectionPoller.connect(JMSConnectionPoller.java:808)
    at weblogic/ejb/container/internal/MDConnectionManager.timerExpired(MDConnectionManager.java:179)
    at weblogic/timers/internal/TimerImpl.run(TimerImpl.java:284)
    at weblogic/work/SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:550)
    at weblogic/work/ExecuteThread.execute(ExecuteThread.java:263)
    at weblogic/work/ExecuteThread.run(ExecuteThread.java:221)
    at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)

这一个执行线程2 

"ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'" id=55 idx=0xc8 waiting for java/lang/String@0x9c312a30 held by:, "ExecuteThread: '1' for queue: 'weblogic.socket.Muxer'" id=54 idx=0xc4 tid=16428 in chain 2, , Chain 4:, "ExecuteThread: '3' for queue: 'weblogic.socket.Muxer'" id=56 idx=0xcc tid=16432 waiting for java/lang/String@0x9c312a30 held by:, "ExecuteThread: '1' for queue: 'weblogic.socket.Muxer'" id=54 idx=0xc4 tid=16428 in chain 2, , Open lock chains, ================, Chain 1:, "[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'" id=34 idx=0x80 tid=16400 waiting for weblogic/jms/client/JMSXASession@0x91a97650 held by:, "[STUCK] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'" id=35 idx=0x84 tid=16401 (waiting on notification), , Chain 2:, "ExecuteThread: '0' for queue: 'weblogic.socket.Muxer'" id=53 idx=0xc0 tid=16426 waiting for java/lang/String@0x9c312a30 held by:, "ExecuteThread: '1' for queue: 'weblogic.socket.Muxer'": non-Java thread

这是执行线程1 

"ExecuteThread: '1' for queue: 'weblogic.socket.Muxer'": non-Java thread
    at jrockit/ext/epoll/EPoll.epollWait0(ILjava/nio/ByteBuffer;II)I(Native Method)
    at jrockit/ext/epoll/EPoll.epollWait(EPoll.java:123)[optimized]
    at weblogic/socket/EPollSocketMuxer.processSockets(EPollSocketMuxer.java:156)
    at weblogic/socket/SocketReaderRequest.run(SocketReaderRequest.java:29)
    at weblogic/socket/SocketReaderRequest.execute(SocketReaderRequest.java:42)
    at weblogic/kernel/ExecuteThread.execute(ExecuteThread.java:145)
    at weblogic/kernel/ExecuteThread.run(ExecuteThread.java:117)
    at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)

在每个THREAD中，我看到来自jrockit / vm / Threads.waitForNotifySignal的“FLAT锁”等待信号移除锁，但我找不到源（也许是ExecuteThread 2持有的ExecuteThread 2）。 / p>

ExecuteThread 2似乎被ExecuteTread'1'“保持”，为什么？

“weblogic.socket.Muxer”似乎读取服务器上的传入请求，客户端上的传入响应是否正确？是否有可能知道他在等什么？

感谢您的帮助，我迷路了：/

此致

C

1 个答案:

答案 0 :(得分：1)

为了更好的说明：

  

BEA-002936

     

信息：已达到最大线程约束constraintName描述：已达到最大线程约束constraintName

     

原因：分配给该工作管理器的线程数已达到最大线程限制中的配置值

     

操作：无需采取操作


  

BEA-002937   信息：不再达到最大线程约束constraintName

     

说明：不再达到最大线程约束constraintName

     

原因：分配给该工作管理器的线程数已降至最大线程限制中的配置值以下

     

操作：无需采取操作

来源：https://docs.oracle.com/cd/E23943_01/apirefs.1111/e14397/WorkManager.html

相关问题
最新问题