You can avoid half a day of trouble by merging the trivial pulls I've set a week ago ;-) On 7 May 2013 17:53, "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