Weblogic 10.3.0: Der Verlust eines Stateless Session Bean in der Bean-Pool

Question

Wir haben eine seltsame Situation, in der wir eine Stateless SessionBean in einem Bean Pool in Weblogic 10.3.0 verlieren. Da wir nur eine Bohne in den Pool haben, hängt dies effektiv alle eingehenden Anrufe. Wir wollen nicht mehr als eine Instanz im Pool wegen Anwendungsbeschränkungen.

In der Weblogic Admin-Konsole, können wir sehen, dass es ein Beispiel in dem Bean-Pool, 0 Bohnen im Einsatz und 1 warten eingehende Anfrage. Die Frage ist, warum nicht das System die Anforderung an die eine offensichtlich frei Bean-Instanz senden?

Dies geschieht nach mehreren Stunden und mehr als 100.000 eingehenden Anfragen, und das gleiche Szenario funktionierte gut in der alten WebLogic 8-Umgebung.

Wir erhalten den folgenden Stack-Trace:

   "[ACTIVE] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'" waiting for lock java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@b0d484 TIMED_WAITING

            sun.misc.Unsafe.park(Native Method)

            java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)

            java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2054)

            weblogic.ejb.container.pool.StatelessSessionPool.waitForBean(StatelessSessionPool.java:269)

            weblogic.ejb.container.pool.StatelessSessionPool.getBean(StatelessSessionPool.java:111)

            weblogic.ejb.container.manager.StatelessManager.preInvoke(StatelessManager.java:148)

            weblogic.ejb.container.internal.BaseRemoteObject.preInvoke(BaseRemoteObject.java:227)

            weblogic.ejb.container.internal.StatelessRemoteObject.preInvoke(StatelessRemoteObject.java:52)

            com.mycompany.beans.MessageLogFacace_n73y0z_EOImpl.isMyStuffValid(MessageLogFacace_n73y0z_EOImpl.java:261)

            com.mycompany.beans.MessageLogFacace_n73y0z_EOImpl_WLSkel.invoke(Unknown Source)

            weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:589)

            weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:230)

            weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:477)

            weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)

            weblogic.security.service.SecurityManager.runAs(Unknown Source)

            weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:473)

            weblogic.rmi.internal.wls.WLSExecuteRequest.run(WLSExecuteRequest.java:118)

            weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)

            weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

Jede Hilfe wäre sehr willkommen.

Answer 1

Dies ist ein bekanntes Problem in Oracle, und sie haben einen Patch für dieses Problem. Kontakt Oracle-Unterstützung den Patch zu erhalten.

Answer 2

Mehr eine Abhilfe als eine direkte Antwort, aber wenn dies mit WebLogic 8 gearbeitet, vielleicht versuchen zu wechseln 8.1 Stil ausführen Warteschlangen und sehen, ob es hilft. In jedem Fall sollten Sie einen Fall öffnen in der Tat.