[jboss-user] [JBossCache] - Re: uninitialized nodes
"genman" wrote : The thing with the removal and addition of interceptors is ... the APIs are a little hokey. Working with index numbers isn't as nice as with objects. | | I was thinking (and it's too late to change, but ...) Interceptors themselves have a specific dependency or ordering to them. And rather than specify the ordering explicitly, the API would be add(Interceptor). You could have a remove(Interceptor) (symmetric call) as well that scans using object identity. | | I do agree that bypassing certain interceptors should be drive by options, not an API call. (It'd be nice if this was done in some generic way. Off topic, but overhauling the interceptor chain is something I have planned for 2.1.0. See http://jboss.org/index.html?module=bb&op=viewtopic&t=112842 for early discussions around this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065307#4065307 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065307 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
"[EMAIL PROTECTED]" wrote : | "genman" wrote : | | There really should be options you can set to override loading from the cache loader, or for ignoring the return values for Node.put(key, value) or Node.remove(key) . | | | Yes, but then you change the behaviour of put() and remove(), which IMO should not be controlled by an option. Perahps add a putQuietly() or removeQuietly() that have return types of void, although this clutters up the API which sucks. | The AsyncCacheLoader has an option to allow remove() and put() (single key) operations to return null instead of the old value. This allows these operations to be queued rather than making the caller wait. Anyway, I thought the point of the options was to send hints to the system, such as "Don't wait to put() if the node is already locked." I would think "I don't need to know the return value for this operation" would be a somewhat similar use case. "[EMAIL PROTECTED]" wrote : | "genman" wrote : | | It would be nice if there was a "disable()" method on Interceptor. Interceptor.invoke() might have been public/final and delegated to a protected abstract method ... | | Well, unless disabling was conditional (i.e., disable for all get() calls) you may as well yank the interceptor out of the chain. The thing with the removal and addition of interceptors is ... the APIs are a little hokey. Working with index numbers isn't as nice as with objects. I was thinking (and it's too late to change, but ...) Interceptors themselves have a specific dependency or ordering to them. And rather than specify the ordering explicitly, the API would be add(Interceptor). You could have a remove(Interceptor) (symmetric call) as well that scans using object identity. I do agree that bypassing certain interceptors should be drive by options, not an API call. (It'd be nice if this was done in some generic way. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065262#4065262 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065262 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
"genman" wrote : | There really should be options you can set to override loading from the cache loader, or for ignoring the return values for Node.put(key, value) or Node.remove(key) . | Yes, but then you change the behaviour of put() and remove(), which IMO should not be controlled by an option. Perahps add a putQuietly() or removeQuietly() that have return types of void, although this clutters up the API which sucks. "genman" wrote : | It would be nice if there was a "disable()" method on Interceptor. Interceptor.invoke() might have been public/final and delegated to a protected abstract method ... Well, unless disabling was conditional (i.e., disable for all get() calls) you may as well yank the interceptor out of the chain. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064788#4064788 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064788 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
"aditsu" wrote : | I didn't put(node, key, value), but put(fqn, map). And it didn't load it from the cacheloader, until I tried to "get" something. | That is a bug. (I've updated JBCACHE-1133) This is now fixed in HEAD with an updated unit test, and now: * put(Fqn, Key, Value) triggers a load (because of return values needed) * put(Fqn, Map) does not trigger a load * get(Fqn, Key) does not trigger a load if the key is in memory, even if dataLoaded is false. The last case can happen when: 1) create a new node - put(fqn, key, value) 2) node is evicted 3) put more data in the node - put(fqn, map) - node not loaded so dataLoaded = false. 4) get(fqn, k2) - if k2 exists in memory due to the put in 3), node is still not loaded and dataLoaded is left at false. See UnnecessaryLoadingTest in CVS for details. "aditsu" wrote : | It should also not write that data to the cacheloader (this is yet another issue, I used a workaround for that too). The ultimate goal is to do my own optimized preloading of data from a database. | This bit I don't understand. Even if you're doing a put(Fqn, Map) and you don't want to load data from the loader, I can't imagine why you wouldn't want the data written TO the cacheloader. Beats the fundamental purpose of a cache loader if this doesn't happen. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064787#4064787 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064787 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
There really should be options you can set to override loading from the cache loader, or for ignoring the return values for Node.put(key, value) or Node.remove(key) . You should be able to remove the interceptors after you load to disable loading and saving. It would be nice if there was a "disable()" method on Interceptor. Interceptor.invoke() might have been public/final and delegated to a protected abstract method ... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063803#4063803 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063803 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
Thanks for the updates and sorry for messing up the jira issue "[EMAIL PROTECTED]" wrote : | This is not entirely correct since even when you first put a node in the cache, it does need to (try and) load it from the cache loader in case it is not really a new node but one that was evicted. | Why should it load it when I put? It doesn't even do that currently. "[EMAIL PROTECTED]" wrote : | Doing a put(node, key, value) is expected to return the old value under that key and hence the need to load. | I didn't put(node, key, value), but put(fqn, map). And it didn't load it from the cacheloader, until I tried to "get" something. I guess it did that because it thinks it should merge the map I gave it with the existing data. I need a way to tell it "just put this data and don't load anything". It should also not write that data to the cacheloader (this is yet another issue, I used a workaround for that too). The ultimate goal is to do my own optimized preloading of data from a database. I wonder if the way to solve it is to have another "special" method like putForExternalRead. Anyway, as I said, my program works now with a cache listener and no cache loader. That will only run into problems if not all the data is present in the cache all the time. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063797#4063797 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063797 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
Also pls see the unit test I've got for this, which emulates the steps you've got in your comment on JIRA: org.jboss.cache.loader.UnnecessaryLoadingTest View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063608#4063608 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063608 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
>From your comment on JBCACHE-1120:
"aditsu" wrote :
| I don't think that's what I reported. I actually had these two problems:
| - AFTER I PUT A NODE IN THE CACHE, if I try to get the same node from the
cache, it still loads its data from the cacheloader
| - after I load a node's children for the first time, if I try to get a
child node from the cache, it loads its data from the cacheloader, even if it
had already loaded it previously
|
| Here's an example, with comments describing what the cacheloader is doing:
|
| Cache c =
DefaultCacheFactory.getInstance().createCache("replSync-service.xml", true);
| Map m = new HashMap();
| m.put("foo", "bar");
| Fqn ab = new Fqn("a", "b");
| c.put(ab, m); //put /a/b, {foo=bar}
| c.get(ab, "foo"); //get /a/b
| c.get(ab, "foo"); //(nothing)
| Node a = c.getRoot().getChild(new Fqn("a")); //get /a
| a.getChildren(); //getchildrennames /a
| c.get(ab, "foo"); //get /a/b
| c.stop();
|
| So it's loading the /a/b node twice, when normally it should never load it
at all (because I put it in the cache first)
|
This is not entirely correct since even when you first put a node in the cache,
it does need to (try and) load it from the cache loader in case it is not
really a new node but one that was evicted.
Doing a put(node, key, value) is expected to return the old value under that
key and hence the need to load.
Subsequent calls to put and get should not load from the loader until the node
is evicted though.
See JBCACHE-1133.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063532#4063532
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063532
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
Sorry, didn't see 1120 - marking it as a dupe. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063527#4063527 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063527 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
Thanks for this. Yes, this is a bug - JBCACHE-1133. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063525#4063525 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063525 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
Filed this as JBCACHE-1120 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060987#4060987 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060987 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
It looks like the solution to all my problems is *not* to use a cacheloader at all. I was preloading all the data anyway (in a custom and optimized way) so I don't need to load further data, and for storing changes I found that I can use a simple cache listener (the JBC2 CacheListener does a wonderful job). I'm using this kind of configuration now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060624#4060624 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060624 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
I also found that CacheLoaderInterceptor.loadChildren() actually calls setDataLoaded(false) explicitly on every single child node, ignoring the fact that data was already in memory. It looks like JBC is trying every possible way to make sure that I can never optimize data preloading, and it loads each node separately from the cache loader, even multiple times. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059000#4059000 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059000 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
In order to call replaceAll, I need to have a Node first. And when I try to get a node, the cache calls the cacheloader to load the data. This is exactly what I want to avoid. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058574#4058574 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058574 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
Node.replaceAll(Map m) should not load the data. Node.putAll() really is a merge operation, which is why the cache will load old data when doing a getData() View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058546#4058546 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058546 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
Well, I have the same problem with jboss-cache-2.0.0.CR2: I put a node in the cache, but when I try to get it later, it tries to load it from the cacheloader because dataLoaded (in UnversionedNode) is false. How can I solve this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058513#4058513 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058513 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
> Don't use the Node object directly in JBC 1.x. Ok, I guess I can use getChildrenNames(), but how can I get the data map of a node? Anyway, I'm already looking at JBC 2, and I found a lot of nice improvements... maybe we'll switch to that. I'll adapt my code to it and see how it behaves. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058009#4058009 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058009 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
Don't use the Node object directly in JBC 1.x. It was meant to be an internal data structure object that got leaked into the API. The correct approach is to use TreeCache.getChildrenNames() In 2.x, we fully support access to Nodes, but this is different. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058008#4058008 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058008 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
> You say this data is "already in memory", how do you know? Because I first put it myself in the cache. The data map already present in the cache node (I checked with peek) has all the information I need, plus the jboss:internal:uninitialized key which I don't need. When the cache finds that key, it decides to load data from the cacheloader. > Also, the children are not loaded with their data until they are accessed. > This is a feature not a bug. Well, I am calling getChildren() on a node, then getData() on the resulting map's values. Again, I get the data I want with that extra key added. Am I doing it the wrong way? > Some of the problems with JBCache 1.4 are caused by accessing data via the > Node object and not the Cache object. Well, when I put data in the cache, I use the cache object. When I get data (in the first case, without involving children), I use get(Fqn) on the cache object then getData() on the node; I haven't found a better way to get all the node's data. I found that if I manually remove the uninitialized key immediately after putting a node in the cache, all the problems seem to disappear. However, this looks like an UGLY thing to do. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057966#4057966 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057966 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: uninitialized nodes
JBoss Cache 2 (which is not in release yet) fixes some problems, such as the "hack" where the map storage is used for book-keeping information. This key is used to indicate that the data has not yet been loaded from disk. You say this data is "already in memory", how do you know? Also, the children are not loaded with their data until they are accessed. This is a feature not a bug. Some of the problems with JBCache 1.4 are caused by accessing data via the Node object and not the Cache object. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057955#4057955 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057955 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
