I don't see an obvious path of causation from the redeploy to the big eviction
queue, not if your dependencies were as described. The cache would be fully
started before the session factories were started; i.e. the cache should not
have been exposed to requests while it was starting.
A possibil
The queue contains instances of:
http://anonsvn.jboss.org/repos/jbosscache/core/branches/1.4.X/src/org/jboss/cache/eviction/EvictedEventNode.java
As you can see it contains ref to an Fqn, two ints, a boolean and a long. Every
time you read or write to the cache one of those is created and added
Thanks. So, the eviction queue should not be the cause of our problem as the
content in the queue is pretty small.
I think we have found out the problem we had in production. It is the hot
deployment. I know jboss does not recommend redeployment in production, we use
it once in a while to add ne
200,000 seems pretty big to me. But my question is how big of each object in
the eviction queue? What is the content of objects in the eviction queue? Is it
just wrapper around the cached objects or just a pointer to the cached object?
If it is a replication of each cached object, then 200,000 s
The eviction event queue holds event objects that describe reads and writes to
the cache. Those are used by the eviction handling code to determine which
nodes to evict (e.g. what nodes are LRU).
The queue itself takes memory, but it's a bounded queue so it won't grow beyond
200,000 entries. Bu
Just before the jvm got outofmemory error, we notice in the log many entries
like this:
putNodeEvent(): eviction node event queue size is at 98% threshold value of
capacity: 20 You will need to reduce the wakeUpIntervalSeconds parameter.
Our wakeUpIntervalSeconds is set as 3 (seconds). I don
Perhaps the eviction thread is not running frequently enough?
The maxNodes config is not a hard limit, i.e. the cache doesn't use the thread
trying to insert node 30,001 to evict a node first in order to stay under the
limit. There's a separate eviction thread (runs every 5 secs by default) that
Well, sometimes we see in production that the total number of objects cached is
far more than what we defined for max node number in treecache.xml. We deploy
hibernate session factory as mbean and turns on the session factory statistics
so we can watch all the caching behavior. In one particula
You can roughly assume one node per entity. There are some overhead nodes as
well, but that's unlikely to be significant in the overall node count once you
start talking thousands of entities.
Yes, increasing maxNodes to 10,000 will increase the number of hibernate
objects. Whether you have en
Sorry the following is not displayed correctly in the original post.
5000
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221644#4221644
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221644
_
10 matches
Mail list logo
