On Jan 24, 2013, at 4:26 PM, Sanne Grinovero <sa...@infinispan.org> wrote:
> It's important to note that Infinispan's implementation of storing as > binary isn't guaranteeing different instances of objects are returned > to different get() invocations (especially when they happen in > parallel). ^ Do you have a test for this? Could this be related to the fact that a get(), unless it had received that entry from another node, will held as reference? It'd be interesting if that test works if after a put() you call compact()... > This is the reason for example that Hibernate OGM can't use this flag > to have safe and independent instances, but needs to make defensive > copies if returned values. As I read in your first post, you want to > use this for defensive copies: that doesn't work, especially if the > TCK is performing concurrent requests. ^ As I said, the storeAsBinary feature is heavily optimised for performance, hence why it initially keeps instances as references, so that if another thread requests the entry soon later, a reference is sent back (no need to serialize/deserialize the entry just put) > > > > On 24 January 2013 16:09, Manik Surtani <ma...@jboss.org> wrote: >> >> On 24 Jan 2013, at 15:39, Vladimir Blagojevic <vblag...@redhat.com> 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 <gal...@redhat.com> 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 <vblag...@redhat.com> >>>>> 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 >>>>> gal...@redhat.com >>>>> twitter.com/galderz >>>>> >>>>> Project Lead, Escalante >>>>> http://escalante.io >>>>> >>>>> Engineer, Infinispan >>>>> http://infinispan.org >>>>> >>>> -- >>>> Manik Surtani >>>> ma...@jboss.org >>>> twitter.com/maniksurtani >>>> >>>> Platform Architect, JBoss Data Grid >>>> http://red.ht/data-grid >>>> >>> >> >> -- >> Manik Surtani >> ma...@jboss.org >> twitter.com/maniksurtani >> >> Platform Architect, JBoss Data Grid >> http://red.ht/data-grid >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
