[brian.stansberry]

Capture org.jboss.ejb3.cache.tree, org.jboss.cache and org.jgroups.

[andy.miller]

Capture org.jboss.ejb3.cache.tree, org.jboss.cache and org.jgroups.

Thanks. I'll do that.

[brian.stansberry]

Thank you. :-) This will be very helpful.

[alrubinger]

"wolfc" wrote:
I 'fixed' your unit test. No need to thank me. :-P

It outlined the problem well.

I've also made two minor corrections in your additions:

* Need to synchronize on the cacheMap to ensure Thread visibility
* The check that the session is removed must come after we manually release the lock on the PM, not before

r80122.

S,
ALR

[alrubinger]

"ALRubinger" wrote:
Side effect: Perhaps removal task might sneak in there and remove an instance before passivation can come along.

No, I found that both passivation and remove are synchronizing on the StatefulBeanContext instances pulled out of the cacheMap, so they're guarded there.

Additionally before passivation we check that the bean hasn't already been removed:

if (centry.getCanPassivate())

So the remaining issue is that activation does *not* synchronize on StatefulBeanContext instances, so there can be odd interleaving during passivation when a get() request comes in.

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

S,
ALR

[brian.stansberry]

Re: the -1 value from StatefulTreeCache.getMaxSize():

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

Which is fixed in ejb3 trunk.

[alrubinger]

Hey, Andy.

If you're still doing this testing, current trunk of AS has a new version of EJB3 with some Cache fixes in SimpleStatefulCache (ie. non-clustered SFSBs). Would be interested in hearing how this plays out.

S,
ALR

[andy.miller]

"ALRubinger" wrote:
Hey, Andy.

If you're still doing this testing, current trunk of AS has a new version of EJB3 with some Cache fixes in SimpleStatefulCache (ie. non-clustered SFSBs). Would be interested in hearing how this plays out.

S,
ALR

Yes. I have been trying to do a profiling run working with Jesper. I can run the test again against the SimpleStatefulCache and see what happens. That's pretty easy to do. I'll let you know what I see. I'll have to build from trunk, correct?

[alrubinger]

I'll have to build from trunk, correct?

Yep.

S,
ALR

[andy.miller]

"ALRubinger" wrote:
Hey, Andy.

If you're still doing this testing, current trunk of AS has a new version of EJB3 with some Cache fixes in SimpleStatefulCache (ie. non-clustered SFSBs). Would be interested in hearing how this plays out.

S,
ALR

Good news. I have been running the load test again against trunk and the stop the world behavior is now gone when using the SimpleStatefulCache. Overall throughput is a little lower now, but I'll take that over the stop the world behavior we had before.

Good work, and thanks.

[fivalo]

HI

Im getting an stops the world with Jboss AS, I only want to know if this is the final configuration:

<annotation expr="class(*) AND !class(@org.jboss.ejb3.annotation.Cache) AND class(@org.jboss.ejb3.annotation.Clustered)">

         @org.jboss.ejb3.annotation.Cache ("StatefulTreeCache")

      </annotation>

      <annotation expr="class(*) AND !class(@org.jboss.ejb3.annotation.CacheConfig) AND class(@org.jboss.ejb3.annotation.Clustered)">

         @org.jboss.ejb3.annotation.CacheConfig (name="sfsb-cache", maxSize=100000, idleTimeoutSeconds=300, removalTimeoutSeconds=0)

      </annotation>

or I must to change to SimpleStatefulCache

Thanks