-
1. Re: storeAsBinary() makes DeltaAware ineffective?
rvansa Apr 15, 2016 4:10 AM (in response to ksobolewski)Hi,
this is simply not implemented. The way to do that is either unpacking each object from its binary form on write (very ineffective) or storing the info if the value implements DeltaAware in entry's metadata. However, DeltaAware does not get too much love, and in my personal opinion it's designed with quite a narrow focus. Therefore, if you need to work with deltas, I'd recommend you to peek into the Functional API, where you can do more and with more straightforward interfaces. You'd have to run deserialization and serialization manually, but that shouldn't trouble you too much (and if it does, please file a JIRA for configuration option that will do this automatically).
-
2. Re: storeAsBinary() makes DeltaAware ineffective?
ksobolewski Apr 15, 2016 5:29 AM (in response to rvansa)Yeah, the only implementing class is AtomicHashMap, but when I looked at it for guidance how I should implement DeltaAware, I got overwhelmed and ran away
I'll look into functional API and how it allows delta-like functionality, thanks!
-
3. Re: storeAsBinary() makes DeltaAware ineffective?
ksobolewski Apr 22, 2016 7:44 AM (in response to rvansa)OK, so I gave it a shot and there is a problem: the ReadWriteEntryView I get inside eval() does not load entries from the CacheLoader. If the object is not (yet) in the cache, then entry.get() will throw an exception, even though Cache.get() would (load and) return the object just fine. Is this a bug?
-
4. Re: storeAsBinary() makes DeltaAware ineffective?
rvansa Apr 22, 2016 8:33 AM (in response to ksobolewski)It would be a bug, but it's probably a misuse. Could you enable TRACE level logging on org.infinispan.interceptors.CacheLoaderInterceptor? It should tell you 'Skip load for ...' with the reason why it's not loaded. Also could you post the code where you acquire the FunctionalCache instance? If it's not loading anything, there must be a SKIP_CACHE_LOAD set. somewhere...
-
5. Re: storeAsBinary() makes DeltaAware ineffective?
ksobolewski Apr 22, 2016 9:39 AM (in response to rvansa)7979 TRACE [main] org.infinispan.interceptors.CacheLoaderInterceptor [] - Skip load for write command ReadWriteKeyCommand {key={<redacted>}, flags=null}? false
8019 TRACE [main] org.infinispan.interceptors.CacheLoaderInterceptor [] - Entry was loaded? true
8034 TRACE [main] org.infinispan.interceptors.CacheLoaderInterceptor [] - Skip load for command GetKeyValueCommand {key={<redacted>}, flags=null}. Entry already exists in context.
The instance is acqired by copy-paste from the reference
this.functionalCache = ReadWriteMapImpl.create(FunctionalMapImpl.create(this.cache));
As for SKIP_CACHE_LOAD, it's nowhere in code I've written
-
6. Re: storeAsBinary() makes DeltaAware ineffective?
ksobolewski Apr 22, 2016 9:42 AM (in response to ksobolewski)Also, in other tests, I get:
8092 TRACE [main] org.infinispan.interceptors.CacheLoaderInterceptor [] - Skip load for command ReadWriteKeyCommand {key={<redacted>}, flags=null}. Cannot load the key.
8095 ERROR [main] org.infinispan.interceptors.InvocationContextInterceptor [] - ISPN000136: Error executing command ReadWriteKeyCommand, writing keys [{<redacted>}]
java.util.NoSuchElementException: No value present
-
7. Re: storeAsBinary() makes DeltaAware ineffective?
rvansa Apr 22, 2016 4:00 PM (in response to ksobolewski)So the log 7979 and 8019 look like the entry was really loaded from the cache. As for 8092 and 8095 - is the cache rebalance completed? 8092 should happen only during state transfer.
I've created unit test Tests loading from cache store using functional API · GitHub where the load from cache store works. Can you tweak it to reproduce your problem?
-
8. Re: storeAsBinary() makes DeltaAware ineffective?
ksobolewski Apr 25, 2016 6:45 AM (in response to rvansa)Sure! I created a fork with "tweaks". It fails, but unfortunately not because of the problem I mentioned above See [ISPN-6542] Subclasses of AbstractWriteKeyCommand don't marshal the Params params field - JBoss Issue Tracker
But the short version is that if the key is local to the node, it works fine. But it fails when it has to replicate the command to the key's owner. I'm not sure yet why I'm observing the missing value exception instead of NullPointerException as in the modified test.
-
9. Re: storeAsBinary() makes DeltaAware ineffective?
ksobolewski Apr 29, 2016 4:54 AM (in response to ksobolewski)I now updated the gist so that it reproduces the scenario I'm seeing. So the thing is: in non-transactional context it works (as you probably already know). It starts failing when the functional operation is done in a transaction. Looks like the entry is wrapped prematurely, which puts it into the context's looked up nodes with the null value; the cache loader skips because the key is not local; and when it reaches Command.perform(), it still has null value. In the non-tx context this works OK because the command returns early if the entry is null (not wrapped) and then it is properly sent across the cluster. But in tx context it gets confused and invokes the functional operation on the local node even if it's not the owner. That's the reason why it fails for me.
Now, the test in the linked gist still fails because the update in the functional operation is not properly committed in the cache. I don't know why, but I already have a bug to report
-
11. Re: storeAsBinary() makes DeltaAware ineffective?
rvansa Apr 29, 2016 6:45 AM (in response to ksobolewski)Thanks for the bug report with test case, that's ideal way to get things fixed. I hope that I or galder.zamarreno will have time to take a look next week.
Is this an issue only when cache store is involved, or are the functional operations broken in transactional mode completely?
-
13. Re: storeAsBinary() makes DeltaAware ineffective?
ksobolewski Apr 29, 2016 7:51 AM (in response to rvansa)I only tested with the cache loader, I can test it without but I won't be able to do it until monday.
-
14. Re: storeAsBinary() makes DeltaAware ineffective?
rvansa Apr 29, 2016 8:24 AM (in response to ksobolewski)Since you seem to analyze the problem quite well, would you be so kind and try to write a fix yourselves? You know, fixing stuff yourselves is the best way to make sure it is fixed soon, in opensource projects