Paul Ferraro wrote about the issue:

This issue can be reproduced more simply by the following steps:
1. Start node1 + node2
2. Log in booking site using demo/demo
3. Click search hotels
4. Click "View Hotel" on the any hotel entry
5. Click "Back to Search"
6. Stop the server on which all the above activity took place
7. Click "View Hotel" on any hotel entry (even the same one, it doesn't
matter)
8. Click "Back to Search"
9. Repeat steps 7+8 three more times. On the third repeated attempt you
will get the "NoSuchEJBException".
10. Try repeating steps 7+8 again and you will not get an exception

First, change the session replication granularity to ATTRIBUTE.
This way you can use the jboss.cache:service=TomcatClusteringCache
printDetails() method to see the contents of the session.

When the "View Hotel" link is clicked from the search hotel page, this
begins a new conversation. The conversation ends when either the hotel
is booked, or the booking is cancelled. Conversations are identified by
a conversation id. This id is merely a counter and is not unique across
the cluster. When you first click "View Hotel" (step 4) you are already
on conversation #4. You can see this by looking at the session cache
(using the printDetails() method). You'll see a number of session
attributes for this first booking conversation:
org.jboss.seam.CONVERSATION#4$hotelBooking: org.jboss.invocation.MarshalledValue@7dc1f719
org.jboss.seam.CONVERSATION#4$hotel: org.jboss.invocation.MarshalledValue@9f1fed88
org.jboss.seam.CONVERSATION#4$org.jboss.seam.persistence.persistenceContexts: org.jboss.invocation.MarshalledValue@3eb6c39d
org.jboss.seam.CONVERSATION#4$org.jboss.seam.faces.facesMessages: org.jboss.invocation.MarshalledValue@3aa15e6c
org.jboss.seam.CONVERSATION#4$org.jboss.seam.core.conversation: org.jboss.invocation.MarshalledValue@4454a04e

After performing step 5, conversation #4 ends and all session attributes
should get removed. However, look at the session cache again and you'll
find a stray session attribute storing the hotelBooking sfsb context
that was not removed:
org.jboss.seam.CONVERSATION#4$hotelBooking: org.jboss.invocation.MarshalledValue@7dc1f719

N.B. This is already a memory leak that affects even a non-clustered
setup.

After steps 6 and 7, if you look at the session cache again, you'll see
that a new conversation is started, but with conversation id #1. As I
said earlier, the conversation id is just a counter and this is the 1st
conversation this server has encountered. On the 4th time step 7 is
performed, the conversation id is now at #4, and the selectHotel(...)
action is attempted on the stale hotelBooking sfsb found in the session

• hence the exception.