Re: [infinispan-dev] Reading data differs from a WAR deployment or an EAR deployment

2011/9/1 Sanne Grinovero <sanne(a)infinispan.org&gt;: > update > it might just be a trivial error: duplicate jars on the classpath, > make the equals fail on the key when looking up a value from the > container. > > This happened to myself once already and costed us some tear and > blood; I'm tempted to add a check for this to log a fat warning, but > this would have an overhead on a very hot path: to verify when the > class instances are different if their names where actually equal, to > be checked for each key comparison in happening during a cache lookup. > > I'm thinking to add such check only if the debug/trace level are > enabled; still that would check for the debug level potentially many > times per query execution, do I'll check the logging level statically > .. better than nothing. > > WDYT ? > Extending the idea: today we've hit this issue on this specific key implementation, but it's in no way specific to Lucene, it could happen to anybody using Infinispan, with any key type both he's own custom keys or our "framework keys" such as those used by Lucene or OGM. Would it make sense to have an option which wraps all keys in the container to do such a check? That would be able to quickly identify classloading ambiguities, and being an Infinispan configuration option it is a bit more intuitive to deal with than changing the behaviour according to log levels.

Sanne _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev