"bstansberry(a)jboss.com" wrote : 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.
In my test, what I see in the JMX console is a -1 in the maxSize. I even have the maxSize
changed in ejb3-interceptors-aop.xml to 125,000, so I can tell the difference between the
two caches. I have even tried putting the @CacheConfig annotation in, and it still shows
-1 in the maxSize in the JMX console.
Is it possible that what you are testing is not what is in the CR 2 build?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184864#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...