On Jan 24, 2013, at 4:09 PM, Manik Surtani <[email protected]> wrote: > > On 24 Jan 2013, at 15:39, Vladimir Blagojevic <[email protected]> wrote: > >> 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. > > Is it not? Perhaps it is only serialised the first time a serial form is > necessary.
^ Manik, you read my reply? :) > You can get around this by calling compact() > > http://docs.jboss.org/infinispan/5.1/apidocs/org/infinispan/Cache.html#compact() > > But this definitely isn't the most optimal way of doing things. Perhaps a > new config option for eager serialisation might be necessary, but for now > calling compact() should work. ^ Didn't remember about compact(), but I had suggested that precisely, a configuration option to force serialization right from the start. > >> 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. > > Yup, I realise. > >> >> 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 >>> >> > > -- > Manik Surtani > [email protected] > twitter.com/maniksurtani > > Platform Architect, JBoss Data Grid > http://red.ht/data-grid > -- Galder Zamarreño [email protected] twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
