This is causing serious problems for our application. I tried switching to EJB3Clustered to hopefully use the TreeCache, but for some reason it's still using SimpleStatefulCache.
javax.ejb.EJBNoSuchObjectException: Could not find Stateful bean: 3j001-gthwm3-eofzrkxj-1-eogs4rla-sb at org.jboss.ejb3.cache.simple.SimpleStatefulCache.get(SimpleStatefulCache.java:266)
There appears to be no discrimination on what component this is a problem for. I thought switching to the clustered config would get us away from the SimpleStatefulCache as a place to start, but it's still using simplestatefulcache.
To recap, this occurs in conjunction with Seam trying to destroy the component. Is anyone else seeing this in their log files?
I'm experiencing very similar behaviour. It may be that something else has caused the bean to be unloaded, such as an exception. I'm investigating this for my application.
These posts seem to be relevant:
I'm seeing this in conjunction with a session scoped bean...
Without knowing a thing about the internals of SFSB, Seam, etc... is it possible that any cache / expiration setting for the session scoped SFSB is SHORTER than it needs to be?
I'm not sure where this value is held, but if my session scoped SFSB is getting expired out of the SimpleStatefulCache after say 5 minutes, and yet I intend a session scoped SFSB to stay around the lifetime of an HttpSession (30 minutes)...
Does / should the SFSB stay around the entire time that Seam holds a reference to it == lifetime of the HttpSession, or can the SFSB get expired out from SimpleStatefulCache before Seam is done with it...?
Yes that is possible.
I must admit I'm also not sure what the default expiration time is. Ask in the EJB3 forum.
I asked the EJB3 forum. The default expiration on SFSB is 300 seconds.
There are custom JBoss annotations called @CacheConfig for both Simple and Tree caches which allow this to be customized on a per-bean basis.
This all may prompt some clarification in the Seam docs? My general notion of a SESSION scoped bean is that it is going to be around for the length of an HttpSession, period. This just isn't the case by default. Also, it seems to me that if people are using custom CONVERSATION timeouts greather than the 5 minute default, that they could run into the same situation where the timeout you're expecing from Seam/HttpSession is different than the timeout of the SFSB.
Maybe Seam could implement some kind of "keep alive" annotated method on an SFSB to prevent the SFSB from getting expired out before its time?
I'm not sure what the answer is across vendors, but I guess I'll try setting the @CacheConfig on every SESSION scoped bean to 1800 to match my HttpSession.
Yeah, what I will lobby for is that the default SFSB and HttpSession timeouts be set the same in JBoss.
Another idea: if there was a hook for Seam to set those in JBoss per component, Seam could keep those in-sync with whatever settings were in web.xml regarding conversation timeout and session timeout.
Yah, but I try not to use JBoss-specific APIs....
As we discussed, I can work around this for Session scoped SFSB's by using the JBoss specific @CacheInfo annotation, setting the timeout to be the same as an HttpSession.
But what about Application scoped SFSB's? We run into this same problem due to the aforementioned reasons in this thread.
An Application scoped SFSB should be viable for the lifetime of an application... but it isn't, and setting a ridiculously large timeout using @CacheInfo would only delay the problem. JBoss times these out like any other SFSB, throws an EJBNoSuchObjectException, and Seam can't recover.
Since EJBNoSuchObjectException is a standard ejb exception, is there a way that Seam could gracefully recover from this?
This all (this thread) seems to me to be quite critical to the promise of Seam -- my component instances should be around for the lifetime of the scope context specified.
I've written in the jira issue related to this topic because, at the begging, I think it's a problem related to this. But now, i'm not sure. If you want, I can open another issue