Hi all,
I had to make a minor change to Equivalence<T> to make things work.
I've made Equivalence<T> extend Serializable. The reason for doing that is
EquivalentCHMv8, and any other equivalent collections are Serializable, so anything they
reference must be either Serializable or transient, and I don't want to force an
Infinispan marshaller on these classes.
I've noticed this because some lucene code stores instances of Infinispan's
ConcurrentHashSet into the cache (represents File list AFAIK, @Sanne?). I could have
worked around this by either providing an Externalizer for AnyEquivalence, but this would
only have worked for situations were these equivalent collections were stored in a cache.
Anyone could potentially create an instance of our equivalent concurrent collections and
just try to serialise it.
If you really wanna make the most out of it, you can always provide an Externalizer, just
like it's been since we added Externalizers, but given that I see Equivalence
instances as mostly stateless, just making it extend Serializable is quite simple
solution.
Cheers,
On Apr 25, 2013, at 7:35 PM, Galder Zamarreño <galder(a)redhat.com> wrote:
Hi all,
Re:
https://github.com/infinispan/infinispan/pull/1790
**There's some bits that require a look from all core developers**:
- AdvancedCache.put(K key, V value, Metadata metadata)
- interface Metadata
- interface Equivalence<T>
- interface TypeConverter<K, V, KT, VT>
The rest of the code can be left reviewed by a couple of people, one of them being
Tristan who's very familiar with the problem and indeed came up with some of the ideas
there (kudos Tristan!) :)
It contains embedded/hotrod compatibility work, and some extra goodies that should reduce
the memory consumption of Hot Rod servers. This was a good opportunity to add these
improvements, including new API to pass in metadata.
Please note that some Memcached tests are failing, as explained in the pull req. I'll
get them sorted tomorrow morning.
Cheers,
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org