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. 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. > 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 _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
