1

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.

Jason Plank
  • 2,336
  • 5
  • 31
  • 40
KlasE
  • 142
  • 11
  • You might try Oracle's support for this. It sounds like a bug in the weblogic thread processor. Probably a memory leak of some sort. – NotMe Feb 17 '10 at 14:12
  • Thank you for the suggestion Chris, we will most likely do that, just wanted to hear if anyone else has run into this and have an idea what it could be. – KlasE Feb 17 '10 at 14:19

2 Answers2

0

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.

Pascal Thivent
  • 562,542
  • 136
  • 1,062
  • 1,124
  • Thank you for the suggestion and link. We have now opened a case with Oracle. There are also some defects solved in Weblogic 10.3.1 that may be related, which may force us to upgrade. I will post the outcome of the help case here when it hopefully is resolved. – KlasE Feb 18 '10 at 10:05
0

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

Jason Plank
  • 2,336
  • 5
  • 31
  • 40
arun
  • 16
  • Thank you Arun for noticing. Our project worked with Oracle to identify and create that patch. So for anyone having a similar issue, this is good to know, go get that patch. – KlasE May 16 '10 at 09:00