Debugging java.rmi.NoSuchObjectException and javax.ejb.NoSuchObjectLocalException thrown when calling a Stateful Session Bean
 Technote (troubleshooting)
 
Problem(Abstract)
Errors pertaining to NoSuchObjectException and NoSuchObjectLocalException, which are thrown when a Stateful Session Bean (SFSB) has timed out or has been removed.
 
Symptom
The following exceptions are thrown:
  • java.rmi.NoSuchObjectException
  • javax.ejb.NoSuchObjectLocalException
 
Cause
Note: This analysis applies to Stateful Session Beans (SFSBs) only.
The EJB specification defines the meaning of these two exceptions when the invocation of an SFSB causes either of these exceptions to be thrown. However, sometimes users feel these exceptions are incorrect. In determining whether that is the case or not, you must determine if they are misunderstood, or if they indicate a problem with WebSphere Application Server.

This document looks at the cases where these exceptions are thrown due to a user calling a timed out or removed SFSB. For example, an exception is thrown when a removed or timed out SFSB instance is invoked:

Remote case:
java.rmi.NoSuchObjectException: Stateful bean BeanId(ExceptionTestEAR#ExceptionTest.jar#MySFSBTest, BF7D926B-0112-4000-E000-18E0C0A80064) was removed or timed out. vmcid: 0x0 minor code: 0 completed: No

Local case:
javax.ejb.NoSuchObjectLocalException: ; nested exception is: com.ibm.ejs.container.SessionBeanTimeoutException: Stateful bean CMStatefulBeanO(BeanId(ExceptionTestEAR#ExceptionTest.jar#MySFSBTest, BF7DBC79-0112-4000-E000-18E0C0A80064), state = METHOD_READY)timed out

The underlined text above indicates that the user is calling an SFSB instance that has timed-out or has been removed. If you see the SessionBeanTimeoutException, this means that the bean has been marked as timed out. However, you must verify in trace that the SFSB instance has truly been removed or has timed out.

In resolving this issue, first look at determining if the SFSB instance has timed out, then determine if the bean was removed.


Determining if the SFSB instance has timed out

Four steps to analyze the trace:

  1. Search for the occurrence of the NoSuchObjectException or NoSuchObjectException. Take note of the BeanId listed in the exception.
  2. Using the J2EEName from the BeanId, find the BeanMetaData Dump for this bean type to determine what setting is listed for the Session Timeout.
  3. From the exception found in step #1, use the BeanId and search backwards for the message indicating the bean instance has timed out. If this message is not found, then the bean was likely removed by the user and you should move onto the section Determining if the SFSB instance has been removed.
  4. If the message is found indicating the bean has timed out, search backwards for the last invocation of this bean instance using the BeanId.

Step 1:
In the remote case, you would see something like this:

[5/24/07 16:14:13:906 EDT] 0000002c StatefulSessi 1 atActivation: exception raised
java.rmi.NoSuchObjectException: Stateful bean
BeanId(ExceptionTestEAR#ExceptionTest.jar#MySFSBTest,
BFB97E53-0112-4000-E000-0374C0A80064)
was removed or timed out.

The BeanId is underlined and will help with the rest of the analysis.

Step 2:
Use the bean name (J2EE name) from the BeanId to find the BeanMetaData Dump for this bean. From the BeanId, determine the J2EE name of the SFSB (for example, in the above BeanId is ExceptionTestEAR#ExceptionTest.jar#MySFSBTest).

Search the trace for the string BeanMetaData  3 -- BeanMetaData Dump. This might result in a lot of hits depending on the number of beans the user has.

Another search option (and likely the best option) would be to search on the string
J2EEName = ExceptionTestEAR#ExceptionTest.jar#MySFSBTest

Once the BeanMetaData Dump is found for the bean, scroll down a few lines and look for Session Timeout. This is the amount of time, in seconds, the bean can remain inactive before it times out. Take note of this time for later use.

[5/24/07 16:11:19:515 EDT] 0000001d BeanMetaData 3
-- BeanMetaData Dump --
MetaDataImpl@1782213178

*** START ComponentMetaData fields ***
J2EEName = ExceptionTestEAR#ExceptionTest.jar#MySFSBTest
EJB Type = STATEFUL_SESSION
TX Type = CONTAINER_MANAGED_TX
Module Version = EJB 2.1
******* ResRefList *******
ResRefList size = 0
****** LOCAL-TRANSACTION *******
Boundary = BEAN_METHOD
Resolver = APPLICATION
UnResolvedAction = ROLLBACK
*** END ComponentMetaData fields ***

Reentrant= false
Session Timeout= 1

Note: In this example of the trace, the session timeout is set very low (which is 1 second) for testing purpose.

Step 3:

Go back to the line where the exception is found in step #1. From there, search backwards for: atTimeout <BeanId>. For example, in our sample trace, it would be:

[5/24/07 16:14:11:546 EDT] 0000000d StatefulSessi >  atTimeout BeanId(ExceptionTestEAR#ExceptionTest.jar#MySFSBTest, BFB97E53-0112-4000-E000-0374C0A80064) Entry

In other words, the string atTimeout, followed by the BeanId. If the message is found, take note of the time stamp in trace (such as, 16:14:11:546). Note that this message might be printed from a thread separate from the thread where the exception is caused. If this message isn’t found, then the bean hasn’t timed out and was removed by the user. This might also indicate a bug in IBM® WebSphere® Application Server, in which case, please refer to the section Determining if the SFSB instance has been removed.

Step 4:

Start at the atTimeout message if found in #3, and search backwards for the BeanId to determine where the bean was last used. It's possible, when searching backwards from the atTimeout message, that this BeanId should be last printed from within an EJBpostInvoke entry/exit.

[5/24/07 16:14:03:890 EDT] 0000002c EJSContainer > EJBpostInvoke(1:beforeSessionTimeout) Entry
[5/24/07 16:14:03:890 EDT] 0000002c StatefulSessi > atPostInvoke Entry ContainerTx@1e531e53#tid=11

CMStatefulBeanO(BeanId(ExceptionTestEAR#ExceptionTest.jar#MySFSBTest, BFB97E53-0112-4000-E000-0374C0A80064), state = TX_METHOD_READY)

[5/24/07
16:14:03:890 EDT] 0000002c EJSContainer < EJBpostInvoke(1:beforeSessionTimeout) Exit

Take note of the timestamp of the last usage of this bean. The difference in the timestamps from the bean instances last usage (in this example, 16:14:03:890), and the atTimeout message (in this example, 16:14:11:546) should roughly equal or greater than the Session Timeout found in step #2. This should be enough to prove that they are in fact calling a timed-out bean. In this case, you must increase the bean’s Session Timeout (refer to Setting Session Timeout for Stateful Session Bean for more details).

Determining if the SFSB instance has been removed

Two steps to analyze the trace:

  1. Search for the occurrence of the NoSuchObjectException or NoSuchObjectException. Take note of the BeanId listed in the exception.
  2. From the exception found in step #1, use the BeanId and search backwards looking for an invocation of the remove method on the bean instance.

Examine the two steps in detail using example trace.

Step 1:

In the remote case, you would see something like this:

[5/24/07 16:14:13:906 EDT] 0000002c StatefulSessi 1 atActivation: exception raised
java.rmi.NoSuchObjectException: Stateful bean
BeanId(ExceptionTestEAR#ExceptionTest.jar#MySFSBTest, BFB97E53-0112-4000-E000-0374C0A80064) was removed or timed out.

The BeanId is underlined and will help with the rest of the analysis.

Step 2:

Starting at the exception found in #1, we should search backwards for a string such as:

Invoking method 'remove' on bean………….<BeanId>

For example, in our sample trace, it looks like this:
[5/24/07 16:14:03:250 EDT] 0000002c EJSContainer < EJBpreInvoke(2:remove) Invoking method 'remove' on bean
'
ejbs.EJSLocalStatefulMySFSBTest_9b857cf0(BeanId(ExceptionTestEAR#ExceptionTest.jar#MySFSBTest, BFB97BD2-0112-4000-E000-0374C0A80064))', 'ContainerTx@b5a0b5a#tid=6e196e19(LTC)', isGlobalTx=false Exit

It may be difficult to know the exact bean name (underlined, above). If so, use regular expressions in your search. You can also search backwards from the exception using the BeanId. Searching backwards using the BeanId should lead you to the message, because the call to remove should have been the last successful execution on the bean instance.

If you still have not proven it is a user’s issue, please contact IBM Customer Support.

Setting Session Timeout for Stateful Session Bean

The session timeout for stateful session bean can be set or changed using IBM Rational Application Developer (RAD) or WebSphere Application Server Toolkit (AST). It is in the Bean tab, under the WebSphere Extensions section.

Refer to the EJB Deployment Descriptor editor topic in the Rational Application Developer Information Center for more information.


About the attachment:

  • Trace file generated from the Sample application: trace.log
  • Sample application: ExceptionTestEAR.ear
  1. Install the EAR
  2. Start the application
  3. Open the browser to http://localhost:9080/TestServlet/index.html
 
Resolving the problem
 
AppAndTrace.zip
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > EJB Container
Operating system(s): z/OS
Software version: 6.1
Software edition:
Reference #: 1289468
IBM Group: Software Group
Modified date: Feb 1, 2008