Hi all, Yesterday while looking at a support case, I discovered an awkward behavior when it came to root region based marshalling nodes and cache loaders. Let's say you have a cache configured with a cache loader and have a region marshaled called starting at /me. I have created an MBean so that I can register/unregister classloader and activate/deactivate the region upon deployment/undeployment of the classes I wanna put under /me. Now, let's say that I put a k,v in /me which will get stored in the cache loader. If I know touch the deployment archive to force a redeployment and check the contents of the cache, they're empty. If I try to get the k I put under /me, it'll return nothing. Why? Simple: The cache instance is configured to preload from root (/) but when the region is activated, /me node is created. When the preloading phase comes, a check is made to see whether the node needs to be loaded: private boolean mustLoad(DataNode n, Object key) { if (log.isTraceEnabled()) { log.trace("mustLoad called with key=" + key + " and datanode=" + n); } return n == null || (n.containsKey(TreeCache.UNINITIALIZED) && (key == null || !n.containsKey(key))); } The problem is that nothing will be preloaded for at least the /me node, because the node is not null, and it's not TreeCache.UNINITIALIZED. Any child nodes under the region node do not have issues like this. This is likely a bug: maybe when the region is activated, the node should probably be created as TreeCache.UNINITIALIZED? I think this would work). It's true that you could say that putting data at the root node of the region is not a good idea regardless, but I think deep down this is a bug.

Thoughts? p.s. This is at least present in 1.4.x, need to check trunk. However, wanted to gather some thoughts before I continue debugging/ fixing it.

Manik Surtani wrote: > > On 29 May 2008, at 14:09, Galder Zamarreno wrote: > >> Hi all, >> >> Yesterday while looking at a support case, I discovered an awkward >> behavior when it came to root region based marshalling nodes and >> cache loaders. >> >> Let's say you have a cache configured with a cache loader and have a >> region marshaled called starting at /me. I have created an MBean so >> that I can register/unregister classloader and activate/deactivate >> the region upon deployment/undeployment of the classes I wanna put >> under /me. >> >> Now, let's say that I put a k,v in /me which will get stored in the >> cache loader. If I know touch the deployment archive to force a >> redeployment and check the contents of the cache, they're empty. If I >> try to get the k I put under /me, it'll return nothing. Why? >> >> Simple: The cache instance is configured to preload from root (/) but >> when the region is activated, /me node is created. When the >> preloading phase comes, a check is made to see whether the node needs >> to be loaded: >> >> private boolean mustLoad(DataNode n, Object key) >> { >> if (log.isTraceEnabled()) >> { >> log.trace("mustLoad called with key=" + key + " and >> datanode=" + n); >> } >> return n == null || >> (n.containsKey(TreeCache.UNINITIALIZED) && (key == null >> || !n.containsKey(key))); >> } >> >> The problem is that nothing will be preloaded for at least the /me >> node, because the node is not null, and it's not >> TreeCache.UNINITIALIZED. Any child nodes under the region node do not >> have issues like this. >> >> This is likely a bug: maybe when the region is activated, the node >> should probably be created as TreeCache.UNINITIALIZED? I think this >> would work). >> >> It's true that you could say that putting data at the root node of >> the region is not a good idea regardless, but I think deep down this >> is a bug. > > I agree this is a bug. Could you raise a JIRA for this? Absolutely :). I'll do it later today. > > Also agree with your solution, that when a region is activated and if > a node needs to be created, it should be uninitialized. > >> Thoughts? >> >> p.s. This is at least present in 1.4.x, need to check trunk. However, >> wanted to gather some thoughts before I continue debugging/fixing it. > > If you create a unit test, could you add it to trunk as well? Defo. > > Thanks > -- > Manik Surtani > Lead, JBoss Cache > manik(a)jboss.org > > > > > >