Re: [infinispan-dev] Reading data differs from a WAR deployment or an EAR deployment
2011/9/1 Sanne Grinovero <sanne(a)infinispan.org>:
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