No valid reason Manik. In summary I thought I would have gotten our keys/values serialized even in local VM if I turn on storeAsBinary but that does not seem to be the case. I need to use storeAsBinary to complete a feature of JSR 107 that allows storing of key/value pairs as serialized values rather than simple references.
TBH, I am not sure how can we do this given mechanisms we have in place. I would have to implement serialization/deserialization in our jsr 107 project but that would be a wrong path if we can somehow turn on our own existing storeAsBinary for in VM stored objects (see Galder's email on what is currently done) Regards, Vladimir On 13-01-24 7:09 AM, Manik Surtani wrote: > JSR 107's storeAsBinary and our storeAsBinary are conceptually the same. You > get a defensive copy and this should work. > > But see my comment below: > > Also adding Mircea in cc. Any reason why you're not using infinispan-dev for > this? > > On 24 Jan 2013, at 12:00, Galder Zamarreño <[email protected]> wrote: > >> Hey Vladimir, >> >> IIRC, for performance reasons, even with storeAsBinary, Infinispan keeps the >> data as normal instance locally. When data is serialized and sent to other >> nodes, again for performance reasons, it keeps it as raw or byte[] format. >> >> So, storing objects by value only happens in counted occassions when >> storeAsBinary is enabled. >> >> You can track it by using a debugger and see how the the MarshalledValue >> instances are created. >> >> Not sure how to fix this without some extra configuration option. >> >> Cheers, >> >> On Jan 23, 2013, at 5:38 PM, Vladimir Blagojevic <[email protected]> wrote: >> >>> Galder, >>> >>> A quick search of help from you beacuse you are more familiar with this >>> area (storeAsBinary) than I am. There is a tck test that checks storing of >>> objects by value not by reference in the cache [1]. I thought that if we >>> set our underlying cache to be storeAsBinary we would handle this tck >>> requirement (store by value if neeed rather than by reference). However, >>> StoreByValueTest fails although I set our underlying Infinispan cache to be >>> storeAsBinary. I am using local cache athough I tried with transport and >>> dist_async setup as well - same result. Any ideas what is going on? >>> >>> Have a look at the test [1] , result I get are below: >>> >>> >>> ------------------------------------------------------- >>> Running org.jsr107.tck.StoreByValueTest >>> Jan 23, 2013 12:35:29 PM org.jsr107.tck.util.ExcludeList <init> >>> INFO: ===== ExcludeList >>> url=file:/Users/vladimir/workspace/jsr107/jsr107tck/implementation-tester/target/test-classes/ExcludeList >>> Defined org.jsr107.tck.StoreByValueTest config >>> StoreAsBinaryConfiguration{enabled=true, storeKeysAsBinary=true, >>> storeValuesAsBinary=true} >>> Tests run: 6, Failures: 6, Errors: 0, Skipped: 0, Time elapsed: 21.852 sec >>> <<< FAILURE! >>> >>> Results : >>> >>> Failed tests: get_Existing_MutateValue(org.jsr107.tck.StoreByValueTest): >>> expected: java.util.Date<Wed Jan 23 12:35:34 EST 2013> but was: >>> java.util.Date<Wed Jan 23 12:35:34 EST 2013> > ?? These seem the same to me? How is the TCK testing for these two values? > By reference? Or using .equals()? > >>> get_Existing_MutateKey(org.jsr107.tck.StoreByValueTest): expected:<Wed Jan >>> 23 12:35:38 EST 2013> but was:<null> > This seems a bigger issue. You might want to look at Infinispan logs here? > >>> getAndPut_NotThere(org.jsr107.tck.StoreByValueTest): expected: >>> java.util.Date<Wed Jan 23 12:35:41 EST 2013> but was: java.util.Date<Wed >>> Jan 23 12:35:41 EST 2013> > Again, see my first comment. > >>> getAndPut_Existing_MutateValue(org.jsr107.tck.StoreByValueTest): expected: >>> java.util.Date<Wed Jan 23 12:35:45 EST 2013> but was: java.util.Date<Wed >>> Jan 23 12:35:45 EST 2013> > Again, see my first comment. > >>> getAndPut_Existing_NonSameKey_MutateValue(org.jsr107.tck.StoreByValueTest): >>> expected: java.util.Date<Wed Jan 23 12:35:48 EST 2013> but was: >>> java.util.Date<Wed Jan 23 12:35:48 EST 2013> > Again, see my first comment. > >>> getAndPut_Existing_NonSameKey_MutateKey(org.jsr107.tck.StoreByValueTest): >>> expected:<Wed Jan 23 12:35:51 EST 2013> but was:<null> >>> >>> Tests run: 6, Failures: 6, Errors: 0, Skipped: 0 >>> >>> [1] >>> https://github.com/jsr107/jsr107tck/blob/master/cache-tests/src/test/java/org/jsr107/tck/StoreByValueTest.java >> >> -- >> Galder Zamarreño >> [email protected] >> twitter.com/galderz >> >> Project Lead, Escalante >> http://escalante.io >> >> Engineer, Infinispan >> http://infinispan.org >> > -- > Manik Surtani > [email protected] > twitter.com/maniksurtani > > Platform Architect, JBoss Data Grid > http://red.ht/data-grid > _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
