Excessive [could not destroy component] 1.1B1 to 1.1CR1

[rdewell]

We've been running Seam in production for many months now. During that time we've VERY intermittently seen the Seam warning "Could not destroy component" in the logs. Due to its low occurrence and seemingly benign nature, we've ignored it.

After the upgrade to CR1, however, we're receiving these warnings almost constantly. Specifically, it appears to be isolated to Stateful Session scoped components, however that is an initial sampling. There doesn't appear to be a Session or component that isn't effected.

Anything that could have changed between b1 and cr1 that could have caused this drastic increase...? We're on 4.0.5.

Ryan

2006-11-30 02:52:03,664 WARN [org.jboss.seam.contexts.Contexts] Could not destroy component: OrderSession
javax.ejb.EJBNoSuchObjectException: Could not find Stateful bean: 41z4l26-wb41k6-ev4j007b-1-ev4jirql-bw
 at org.jboss.ejb3.cache.simple.SimpleStatefulCache.get(SimpleStatefulCache.java:268)
 at org.jboss.ejb3.stateful.StatefulRemoveInterceptor.removeSession(StatefulRemoveInterceptor.java:127)
 at org.jboss.ejb3.stateful.StatefulRemoveInterceptor.invoke(StatefulRemoveInterceptor.java:87)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
 at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
 at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:131)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
 at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
 at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
 at org.jboss.ejb3.stateful.StatefulContainer.localInvoke(StatefulContainer.java:203)
 at org.jboss.ejb3.stateful.StatefulLocalProxy.invoke(StatefulLocalProxy.java:98)
 at $Proxy219.destroy(Unknown Source)
 at x.x.OrderSession$$FastClassByCGLIB$$e5185c52.invoke(<generated>)
 at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
 at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:45)
 at org.jboss.seam.intercept.ClientSideInterceptor$1.proceed(ClientSideInterceptor.java:69)
 at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:55)
 at org.jboss.seam.interceptors.RemoveInterceptor.removeIfNecessary(RemoveInterceptor.java:39)

[gavin.king]

Increase your SFSB timeout to be slightly longer than the HttpSession timeout.

[rdewell]

Added 5 minutes to @CacheConfig. So it's at 35 minutes now. Was 30 minutes. No change in frequency.

This was occurring maybe 5-10 times a day on B1 and older, and now it's occurring about 50 times per hour.

Other ideas?

[gavin.king]

I can't think of any other possible explanation. It really, really looks like an SFSB timeout problem.

[gavin.king]

Did you see this page:

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984429

I'm not sure if I thing @CacheConfig is a really good use of an annotation. If you can use XML for this, that would be better.

[vivimos]

I had the same problem using CR1 with a SFSB where I was injecting FacesMessages using @In(create=true) private FacesMessages facesMessages. (It didn't matter whether I used the transient keyword or not.)

When I removed the @In injection statement and instantiated FacesMessages in the method using FacesMessages.instance() the problem disappeared.

With the nightly build of November 29th the problem seems to have disappeared an I can inject FacesMessages with no problem.

I had no luck trying to solve the problem with @CashConfig.

Carl

[rdewell]

Yes I see that thread. Using the XML descriptor is merely configuring that annotation, so they are functionally equivalent. The XML has the downside of not being granular enough to say that Session scoped SFSB should have a longer timeout than say a Conversation scoped SFSB.

You're up against Seam and JBoss notions of SFSB lifetimes, and AFAIK @CacheConfig is the ONLY way to handle this granularly.

I'm originally reported this SFSB timeout issue with Seam:

http://jira.jboss.org/jira/browse/JBSEAM-279

As is reported in that ticket, @CacheConfig used to solve this lifetime mismatch. I don't like the solution either, but there really was/is no other solution.

As of sometime between b1 and cr1, however, something has happened and @CacheConfig doesn't do the trick anymore. Actually, it's even worse than before that reported ticket.

On a related note, I'd really like to know how Seam is going to handle this problem across different JEE implementations. Could Seam "ping" the SFSB's it controls periodically so the container doesn't time them out?

OR, are you suggesting that in the XML configuration we should set the SFSB timeout to Integer.MAX_VALUE? Effectively telling JBoss to never expire SFSB beans? That just seems like it would very dangerous and put a lot of responsibility on Seam to cleanup unexpected problems with lingering SFSB's.

OR, if from Seam's standpoint this is a benign warning, could it do something else besides throw up a stack trace? Like:

"WARN: Seam could not destroy component XVB. This is probably safe to ignore, but may represent an SFSB timeout setting that is too low for the Seam scope."

[gavin.king]

Hum, OK I just realized that there *is* a problem (perhaps this is what you have been trying to say all along).

If you have an SFSB sitting in session scope, and you make some requests to the server which do not actually touch that SFSB, then the SFSB will timeout *before* the HttpSession times out. I don't see a really good way to fix this (there is no safe way to "ping" an SFSB AFAIK).

So the only solution is to set the SFSB timeout "much" longer than the HttpSession timeout. Disabling the SFSB timeout altogether will work, and should be reasonably safe to do, since Seam is pretty good about guaranteeing that cleanup occurs at HttpSession timeout.

The other solution is to simply not use SFSBs in this way. Use session-scoped SFSBs only if you know that they will be used on each page, or at the beginning of each conversation, or whatever.

[gavin.king]

I mean, frankly, if you think about it, this is exposing a real flaw in your application design. What you have is state sitting on the server that is not even being used, for an entire login session! This is a waste of server resources.

[rdewell]

Alright, it's my fault, but this thread has gotten off topic.

No, my session scoped SFSB are not sitting around idle. They're being used almost constantly throughout the app session. What I'm trying to explain in both the ticket (and apologies for diverging here) is that I believe it is Seam's responsibility to handle this better, and agnostic to the JEE container.

Regardless of that perspective I have, back to topic, as of 1.1CR1, Seam is no longer destroying these components successfully (above error). I have @CacheConfig set at 35 minutes. It was previously at 30 minutes and worked FINE on 1.1b1 and below. Seam had no problems destroying these components.

So, I don't know what's changed. I guess I'll have to dig more info up. I find the whole thing strange myself.

[gavin.king]

No, my session scoped SFSB are not sitting around idle.

I don't believe you. If they were not sitting around idle, you would not be getting EJBNoSuchObjectExceptions. Please consider the possibility that this is your problem, instead of fixating that it is mine.

What I'm trying to explain in both the ticket (and apologies for diverging here) is that I believe it is Seam's responsibility to handle this better, and agnostic to the JEE container.

Is it also Seam's responsibility to solve the AIDS epidemic in Africa and help America bring democracy and stability to Iraq?

It's all very well to wish for impossible things, but I have to actually write some code at some stage.

There is no platform-neutral way to implement this, since the metadata to control SFSB timeout is not defined by the Java EE spec. End of story. Nor are there any exposed APIs that Seam could call.

as of 1.1CR1, Seam is no longer destroying these components successfully (above error). I have @CacheConfig set at 35 minutes. It was previously at 30 minutes and worked FINE on 1.1b1 and below. Seam had no problems destroying these components.

You are the only one who has experienced this (so far). You have given us no way to reproduce the problem. You have given no real information other than a stack trace. And you are ranting and telling us that we have a responsibility to deliver impossible things.

If you can produce a very, very simple test case that demonstrates this happening, we can continue this discussion. If not, I have many other things to do.

[rdewell]

I didn't intend to make you defensive. Seam is a great app, and as I said, I'll try to dig up some more info. Others have experienced this problem. I'll start with Carl's suggestion in this thread, and see where that goes.

[rdewell]

Carl's solution worked. Never would have guessed it had he not said something. Thanks, Carl.

I had to remove all @In's from my Session scoped SFSB's and change them to direct access through Component.getInstance.

Changed session timeout in web.xml to 1 minute -- far less than the idle timeout of the SFSB's -- and allowed me to test quickly.

With the @In's present, I get the previously mentioned error.

With the @In's absent, everything works as it used to in b1 and below -- the error no longer occurs. Again -- only change was the removal of all @In's from the session scoped SFSB's.

Would you like a test case for this? Unlike Carl, I've had no luck with the nightlies fixing this.

[vivimos]

Rdewell,

I was mistaken this morning when I said I was not having problems with the latest nightly builds. I, like you, have the same result with the latest nightly builds.

Carl

[gavin.king]

With the @In's present, I get the previously mentioned error.

With the @In's absent, everything works as it used to in b1 and below -- the error no longer occurs. Again -- only change was the removal of all @In's from the session scoped SFSB's.

This makes no sense at all.

Please produce a simple test case which shows this happening.