However after I had configured the adapter and run some successful tests I saw the following stack trace in the server log after a period:
<[STUCK] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "600" seconds working on the request "weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl@4b936059", which is more than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace:
java.net.SocketInputStream.socketRead0(Native Method)
java.net.SocketInputStream.read(SocketInputStream.java:129)
oracle.net.nt.MetricsEnabledInputStream.read(TcpNTAdapter.java:564)
oracle.net.ns.Packet.receive(Packet.java:295)
oracle.net.ns.DataPacket.receive(DataPacket.java:94)
oracle.net.ns.NetInputStream.getNextPacket(NetInputStream.java:176)
oracle.net.ns.NetInputStream.read(NetInputStream.java:121)
oracle.net.ns.NetInputStream.read(NetInputStream.java:96)
oracle.net.ns.NetInputStream.read(NetInputStream.java:81)
oracle.jdbc.driver.T4CSocketInputStreamWrapper.readNextPacket(T4CSocketInputStreamWrapper.java:124)
oracle.jdbc.driver.T4CSocketInputStreamWrapper.read(T4CSocketInputStreamWrapper.java:80)
oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1087)
oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1062)
oracle.jdbc.driver.T4Caqdq.receive(T4Caqdq.java:338)
oracle.jdbc.driver.T4CConnection.doDequeue(T4CConnection.java:4067)
oracle.jdbc.driver.PhysicalConnection.dequeue(PhysicalConnection.java:16057)
oracle.jdbc.driver.PhysicalConnection.dequeue(PhysicalConnection.java:16138)
oracle.jdbc.OracleConnectionWrapper.dequeue(OracleConnectionWrapper.java:1594)
weblogic.jdbc.wrapper.XAConnection_oracle_jdbc_driver_LogicalConnection.dequeue(Unknown Source)
weblogic.jdbc.wrapper.JTAConnection_weblogic_jdbc_wrapper_XAConnection_oracle_jdbc_driver_LogicalConnection.dequeue(Unknown Source)
oracle.tip.adapter.aq.v2.database.AbstractDequeueAgent.dequeue(AbstractDequeueAgent.java:356)
oracle.tip.adapter.aq.v2.database.AbstractDequeueAgent.dequeueMessage(AbstractDequeueAgent.java:259)
oracle.tip.adapter.aq.v2.database.AbstractDequeueAgent.getInputRecord(AbstractDequeueAgent.java:232)
oracle.tip.adapter.aq.v2.database.AbstractDequeueAgent.run(AbstractDequeueAgent.java:101)
weblogic.work.ContextWrap.run(ContextWrap.java:41)
weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Apparently, this StuckThread trace occurs 10 minutes after the server has been started and is caused by the fact that WebLogic uses by default 1 polling thread which remains active, or in other words is never released by the adapter, by design. Therefore the stuck thread trace can be ignored.
Please look in the OSB JCA transport guide for a detailed explanation and the configuration steps that can be applied to prevent stuck thread traces for polling threads (use a special configured Workmanager)
