[infinispan-dev] Marshalled Value issue

Galder Zamarreno galder at jboss.org
Thu Jan 28 04:43:41 EST 2010



On 01/28/2010 10:22 AM, Manik Surtani wrote:
>
> On 28 Jan 2010, at 09:08, Galder Zamarreno wrote:
>
>>
>>
>> On 01/28/2010 09:35 AM, Galder Zamarreno wrote:
>>>
>>> One quick note about marshalled values. Over the past few days, I've
>>> been fighting a random failure in a concurrent test in the 2nd level
>>> cache. I still haven't got to the bottom of it, but I've narrowed it
>>> down to something related to marshalled values cos when it's switched
>>> off, the test always passes.
>>>
>>> My gut feeling is that there's some thread safety issue with marshalled
>>> values but still can't pin point the exact issue.
>>>
>>> I'll keep you posted but I'm not sure I'll be able to resolve it in the
>>> next couple of days before I go on holidays.
>>
>> To make sure everyone understands the complexity of this, logging for
>> marshalled values is a bit of a mess. The same marshalled object can be
>> represented in 3 diff ways in the logs:
>>
>> MarshalledValue(cachedHashCode=0; serialized=false)
>> ->  This is shown when the marshalled value that has not yet been
>> deserialized at all. The main issue here is:
>> + On one side, when the MarshalledValue is created from MVI, we should
>> comnpute it's hashcode. This is hardly any cost for us cos we have the
>> Object instance and we don't have to do any deserialization.
>
> MVs are also created when deserializing a byte stream from a remote node.
>
>> A side issue here is that two different objects could have the same
>> hashcode, so simply showing that might not be good enough to
>> differentiate them in the logs. So, we need to add identity hash code
>> information at the end of the toString representation. To give you an
>> example of this:
>>
>> Here's a key for collection cache:
>> org.hibernate.test.cache.infinispan.functional.Customer.contacts#3
>> Here's a key for entity cache:
>> org.hibernate.test.cache.infinispan.functional.Customer#3
>>
>> These two produce the same MarshalledValue representation:
>> MarshalledValue(cachedHashCode=3; serialized=false)
>>
>> Now, the other two representations:
>>
>> MarshalledValue(cachedHashCode=3; serialized=false)
>> ->  This is shown when the MarshalledValue has been deserialized. Here
>> the hashcode is 3, which comes from CacheKey's hashCode which is
>> represented by the primary key.
>
> Right, this is when the cachedHashCode is populated.
>
>> org.hibernate.test.cache.infinispan.functional.Customer.contacts#3
>> ->  This is the toString() representation of CacheKey.
>
> When does this happen?  MVs should always indicate that they are, in fact, MVs.  Regardless of the internal form they take (objects or bytes).

This happens when there's logging before MVI, i.e. at 
InvocationContextInterceptor

>
> Cheers
>
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache



More information about the infinispan-dev mailing list