Weblogic 10.3.0 : Losing a stateless session bean in the bean pool

Question

We have a strange situation where we lose a Stateless SessionBean in a Bean Pool in Weblogic 10.3.0. Since we only have one bean in the pool, this effectively hangs all incoming calls. We do not want more than one instance in the pool because of application restrictions.

In the Weblogic admin console, we can see that there is 1 instance in the bean pool, 0 beans in use, and 1 waiting incoming request. The question is, why doesn't the system send the request to the one obviously free bean instance?

This happens after several hours and over 100,000 incoming requests, and the same scenario worked fine in the old weblogic 8 environment.

We get the following 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)

Any help would be very welcome.

Answer 1

This is a known issue in Oracle and they have a patch for this issue. Contact Oracle support to get the patch.

Answer 2

More a workaround than a direct answer but if this worked with WebLogic 8, maybe try to switch to 8.1 style execute queues and see if it helps. In any case, you should open a case indeed.