Just an update. First, I deployed a bean with configuration like what you reported Andy, and when StatefulTreeCache was accessing the bean metadata to determine how to set up JBoss Cache's passivation, it got a maxSize=100000. So, that's all working fine. I deployed the bean along with a little service that creates a configurable # of threads that loop a configurable number of times instantiating new beans. Doesn't use the beans after looking up the proxy and invoking a single getter. Fired it off telling it to use 4 threads to create 200K beans. Am now watching the JMX console view of the bean container to see what happens. 1) The CurrentSize attribute steadily rose past 10K; no apparent limit; eventually got up to over 24K 2) After 5 mins, consistent with the default @CacheConfig.idleTimeoutSeconds=300 in ejb3-interceptors-aop.xml, passivation kicked in and the CurrentSize started dropping a bit while PassivatedCount steadily rose. It would appear the single background thread is able to passivate beans faster than the 4 threads create them. Judging from some periodic logging I added, it's taking about 6 secs to create 500 beans. The beans aren't particularly heavyweight, the client is in-vm, and there's only one node in the cluster, so no replication going on. So not particularly fast. But, the passivation part seems to be working as I'd expect. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184606#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...