On 24 Jan 2013, at 15:39, Vladimir Blagojevic <vblagoje(a)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()
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.
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 <galder(a)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 <vblagoje(a)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...
>>
>> --
>> Galder ZamarreƱo
>> galder(a)redhat.com
>>
twitter.com/galderz
>>
>> Project Lead, Escalante
>>
http://escalante.io
>>
>> Engineer, Infinispan
>>
http://infinispan.org
>>
> --
> Manik Surtani
> manik(a)jboss.org
>
twitter.com/maniksurtani
>
> Platform Architect, JBoss Data Grid
>
http://red.ht/data-grid
>