Things learned by trial and error ...

vpertsovskiy Jan 13, 2005 2:25 PM

It seems when the object is very complex. For example, one object extends an abstract object and implements a few interfaces. If only one of the interfaces is serializable and the abstract object is not and contains state, no error is thrown, but the object is not serialized, and does not appear in the replicated cache. I am not sure how you could check this, but might be a useful improvement.

We've also ran a number of performance tests. TreeCacheAOP performs terribly with close to 300ms to put a large object. The same object takes about 2ms to put using plain TreeCache.

We have a requirement to dynamically walk the tree without explicitely knowing all the branches. We accomplished this using the node.getChildren(), and then walking the children recursively. The problem is that the node.getChildren() is an unsynchronized map that can be modified during the walk generating a ConcurrentModificationException. Our solution was to copy the values(nodes) of the returned map into an object array, and then triverse the object array. The copy would keep retrying until it can successfully copy the map. The performance hit was pretty negligable.

The final problem we saw deals with replication. We have two nodes in the cluster. Node1 is writting data continuosly, and node2 is started and tries to obtain the current state. We were using SERIALIZABLE locking scheme WITHOUT transactions. Most of the time the request for state failed with a ConcurrentModificationException. When we started using dummy transactions, the tree was successfully locked.

Anyways, hope this helps somebody, or improves jboss-cache.

1. Re: Things learned by trial and error ...

ben.wang Jan 13, 2005 4:23 PM (in response to vpertsovskiy)

Thanks for the feedback. Just some comments on the aop.

TreeCachAop will always be more expensive than TreeCache on the put object. This is because aop needs to map all the object graph into the store while TreeCache just stores a reference. So the bigger the object graph, the more expensive aoo will be.

However, keep in mind that in aop, you don't do putObject frequently. And once it is done, aop will then manage your object relationship transparently for you. And if you have replication, the granularity is field level. This is where the performance advantage of aop can come in because of fine-grained replication.

Hope this help,

-Ben
Actions