[EJBTHREE-788] Align Default timeout of SFSB and HttpSession

[alrubinger]

https://jira.jboss.org/jira/browse/EJBTHREE-788

Seam is requesting a bump of the default SFSB timeout (==passivation, not removal) from 5 minutes to at least 30.

I'm not comfortable with this for the following reasons:

1) Possible abrupt memory profile changes for our users upon upgrade that brings in this change
2) There's nothing binding the timeouts of SFSB and HttpSession, so this makes a problem less frequent but not properly resolve it

But the real nagging point is that EJBTHREE-788 does not specify *why* this needs to be done; Brian notes in a discussion w/ Pete that likely managed objects stored in HttpSession get out of sync when references to these are unbound upon SFSB passivation?

Possible to get Seam to hook into the SFSB lifecycle callbacks and on passivation/reactivation?

S,
ALR

[alrubinger]

"ALRubinger" wrote:
Possible to get Seam to hook into the SFSB lifecycle callbacks and on passivation/reactivation?

I came across this in an email from Pete:

"Pete Muir" wrote:
We can't easily switch to using passivation/activation callbacks as at that point the session (at least for SFSBs) and conversation (though if we have the session, we could work around this) aren't available.

So my question becomes: can you make it available? :)

S,
ALR

[alrubinger]

I just spoke to Pete, who pointed me to:

http://seamframework.org/Community/ApplicationInstabilityInMultiuserEnvironment

This talks about SFSB removal, not passivation.

The default is now:

@org.jboss.ejb3.annotation.CacheConfig (maxSize=100000, idleTimeoutSeconds=300, removalTimeoutSeconds=0)

...where "0" means "don't remove the bean as part of a timeout".

So either:

1) The issue is now fixed in EJB3 by nature of us not removing a SFSB
2) EJB3 is applying a removal timeout when it shouldn't.

The removals are reaped by a Thread with a name prefix of "SFSB Removal Thread - ", by default as defined by SimpleStatefulCache.

Pete and I have agreed to curb this pending further evidence that the issue is still present.

S,
ALR

[pmuir]

"ALRubinger" wrote:
https://jira.jboss.org/jira/browse/EJBTHREE-788

Seam is requesting a bump of the default SFSB timeout (==passivation, not removal) from 5 minutes to at least 30.

<snip>

But the real nagging point is that EJBTHREE-788 does not specify *why* this needs to be done; Brian notes in a discussion w/ Pete that likely managed objects stored in HttpSession get out of sync when references to these are unbound upon SFSB passivation?

No, the request is for removalTimeout, which talking to ALR appears to have been set to "never". This is a totally different issue from passivation/activation... Seam users are still reporting problems in 4.2.2 with SFSBs getting removed even with "never", so we need to continue monitor this...

On this unrelated issue, which you ask about - no with Seam 2 we can't get restore the conversation in SFSB passivation/activation call, as we store conversations in the HTTP session, and this isn't available in these passivation/activation call backs.