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).
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org