[Design of EJB 3.0] - Re: Passivating EJB 3 Stateful Session Beans stops the World
by andy.miller@jboss.com
"bstansberry(a)jboss.com" wrote : "andy.miller(a)jboss.com" wrote : Is it possible that what you are testing is not what is in the CR 2 build?
|
| Oh, for sure. I'm testing my local checkout of trunk, which is probably off from head by a day or so.
|
| Hmm, I see what you are saying about the maxSize in the JMX console. I'll have a look; that's a bug. When I tracked the deployment in the debugger, the 100K maxSize came through from the metadata and was passed into the JBC eviction configuration. So 99% sure the bug is in the JMX display of the metadata.
Based on your test, that's what I was starting to think as well. So, that leaves me with one other issue to explore. Why is my test so much slower using the StatefulTreeCache, then using the SimpleStatefulCache?
I have been having trouble with getting JBoss Profiler working, but Jesper has given me a fix for an issue I was having. Could you recommend specific packages I should make sure I capture with the profiler?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184917#4184917
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184917
15 years, 6 months
[Design of JBossCache] - Tree versus flat hashmap cache structure
by nonius
We are studying the internals of JBossCache and we are wondering what exactly are the performance reasons that made you choose to struture cache as a tree rather than as a flat hastable.
In this tutorial:
http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs...
We found this paragraph:
anonymous wrote : The first version of TreeCache was essentially a single HashMap that replicated. However, the decision was taken to go with a tree structured cache because (a) it is more flexible and efficient and (b) a tree can always be reduced to a map, thereby offering both possibilities. The efficiency argument was driven by concerns over replication overhead, and was that a value itself can be a rather sophisticated object, with aggregation pointing to other objects, or an object containing many fields. A small change in the object would therefore trigger the entire object (possibly the transitive closure over the object graph) to be serialized and propagated to the other nodes in the cluster. With a tree, only the modified nodes in the tree need to be serialized and propagated. This is not necessarily a concern for TreeCache, but is a vital requirement for PojoCache (as we will see in the separate PojoCache documentation).
|
We agree on the fact that a tree structure can be always reduced to a hashtable, but we do not see particular difficulties in handling with incremental updates to replicate a hashtable.
We could not find a previous discussion on this topic in the forum. So, we would appreciate if someone can help us in better understanding the reasons underlying this design choice.
Thanks in advance,
nuno
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184913#4184913
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184913
15 years, 6 months