On 16 Sep 2010, at 08:31, Galder Zamarreño wrote:
Hi,
Paul has opened an interesting JIRA in the Hibernate Infinispan 2LC code:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5552
The problem here is that Infinispan 2LC code maintains a series of listeners that can
force deserialization of MarshalledValues within Transport thread which leads to CNFEs. MV
deserialization here happens as a result of calling
EventImpl.getKey()/EventImpl.getValue(). The key thing here is that one of the listeners
actually uses these key/values to maintain a local cache for better performance. To solve
this, Paul has come up with a solution which involves having a Cache wrapper and any
listener added is wrapped around a listener that sets the correct CL.
I haven't seen similar problems so far, but considering that we might see more issues
like this reported, I was wondering whether we could help solve this issue within
Infinispan in a better way. I considered @Listener having an optional parameter which
indicates whether getKey/getValue should return the MarshalledValues instead of their
deserialized versions. This would solve half of the problem since local caches could
stored MVs instead of deserialized versions. However, client listener could would then
need to wrap keys into MarshalledValues which means that they'd have to pass an
StreamingMarshaller but this is not exposed to clients. This avenue does not look very
pretty since we're exposing internals, although it could be improved by providing some
kind of MarshalledValue factory method that would not require clients to know anything
about the Marshaller.
Hmm, I don't think getKey()/getValue() should ever return a MarshalledValue as this is
really pretty useless to callers. If a caller calls either of these methods, they want
the actual key or value and not some internal representation.
I plan to go with Paul's workaround but I think we should keep
this in mind and see if we can come up with a cleaner solution.
Yes, stick with this for now and if there is general need for such a feature we can think
of something like perhaps adding a ClassLoader to the listener impl and having the
notifier use this CL when deserializing stuff for a listener. But too much for now -
let's see if it is generally useful first.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org