SFSB caching average and passivation remover timers

[ben.wang]

While trying to resolve this issue: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=75370
, cusomter also discover an additional issue. Here is the description:

If we have a setting like:

max-bean-life = 3600 (secs)
* Used to determine when to remove the bean in the passivation store by: (max-bean-life - max-bean-age) = 0 now.

max-bean-age = 3600 (secs)
* Used to determine when to passivate

So in this case, after 1 hour, the bean will be passivated first and removed immediately. Not perfect but still ok.

The caveat when you have pool size of only 2, so when bean1 is passivated, next time when remover task thread comes in to check for bean removal, it will remove it immediately since the delta is 0 now as well!

Next when 10 mins is up, and the session unbound listener in web container tries to remove the ejb, you will have bean not found exception since it has been removed.

Of course the get-around is to set the two timer differently. But do we have an easy solution for this?

[starksm64]

I don't see why there should be an expectation that the session should be recoverable based on these settings. Explain the issue with a 2 count pool in more detail in terms of how it relates to this config as I'm not following what is special about it.

[ben.wang]

Ok, I will try to explain it one more time. Hope it is clearer.

The issue is when both are set to 3600 (secs). Users expect to see the bean goes away in one hour. If, however, the pool size is set to 2, after creating the 3rd bean, bean #1 will be passivated. Next when the remover thread comes in to check for ageout items to remove, bean #1 will be removed immediately (instead of 3600 seconds later). This is because the remove thread determine when to remove the passivated bean based on the delta of (max-bean-life and max-bean-age).

[starksm64]

Ok, but for max-bean-life == max-bean-age I would expect this. What else would you expect?

[ben.wang]

yeah, but in that example, I'd expect both max-bean-age and max-bean-life to be both 3600 seconds (so the bean should last for one hour). But in reality, the bean can be removed in 10-15 seconds after it has been passivated (because of pool size limit). Do you know what I am saying?

[starksm64]

Ok, the bean is being passivated due to the size of the cache and subsequently removed because of the maxLifeAfterPassivation=0. This is a flaw in the logic of the removePassivated method. This code is assuming a time based passivation policy. The maxLifeAfterPassivation elapsed time needs to be calculated based on the inactive period of the bean, not the max-bean-age - max-bean-life diff because there is no correlation between these if the bean is evicted due to size.

[starksm64]

http://jira.jboss.com/jira/browse/JBAS-2695