And it looks like this change results in mem leak as well ... On May 7, 2013, at 6:53 PM, Dan Berindei <dan.berin...@gmail.com> wrote:
> > > > On Fri, May 3, 2013 at 1:49 PM, Galder Zamarreño <gal...@redhat.com> wrote: > Here's what I replied in a separate email last. Since then the issue has been > sorted: > > > The reason I designed a byte[] specific Equivalence class is to avoid > doing instanceof on the type passed. This would slow things in a > critical path, hence, I designed a purely byte[] Equivalence class, > and why there's no instanceof in AnyEquivalence either, to be as > performant as possible. > > So yeah, as you suggest, the workaround would be for AnyEquivalence to > check if the parameter is a byte[], in which case, delegate to > ByteArrayEquivalence, but to reiterate, this is only a workaround and > not the optimal solution. > > I also checked if the Hot Rod server could add this itself to the > caches, but this is complex stuff because it's given a cache manager > already built, so it'd need to go and change the default configuration > to apply this change programmatically, which is not easy because > you're given a Configuration object and not the buillder, and making > Configuration mutable just for that, where you're just trying to > override what it's been configured in the cache manager is a hack. > > Since we controlled the way the servers are started via Infinispan > Server, I assumed we controlled its configuration, hence I expected > configuring BAEquivalence to be a safe assumption. We've made a bad > job of waiting to integrate this and test Infinispan Server until now, > with 7 days since the pull req has been up. Maybe the pull req test > execution needs to also execute the Infinispan Servers testsuite > automatically to avoid future issues.... > > -1 to add more stuff to the pull request build, it already takes half a day > for all the pull requests to be revalidated after a push to master. (10 PRs * > 30 mins/PR = 5h) > > Besides, if this change broke Infinispan Server, isn't there a risk that it > broke 3rd party applications relying on the HotRod server as well? > > > > On May 2, 2013, at 5:05 PM, Tristan Tarrant <ttarr...@redhat.com> wrote: > > > Hi all (Galder in particular), > > > > the integration of ISPN-2281 has caused breakage of Infinispan Server > > because the caches created by the server have key/value equivalence set > > to AnyEquivalence instead of ByteArrayEquivalence (like the testsuite does). > > I believe the fix rests in making AnyEquivalence true to its name and > > handle array equivalence too. > > > > HotRod on Infinispan Server is essentially broken until this is fixed. > > > > Tristan > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Galder Zamarreño > gal...@redhat.com > twitter.com/galderz > > Project Lead, Escalante > http://escalante.io > > Engineer, Infinispan > http://infinispan.org > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
