That won't help, the moment Tristan sees there are less than 10 PRs open he'll come up with a couple more :)
On Tue, May 7, 2013 at 7:57 PM, Sanne Grinovero <sa...@infinispan.org>wrote: > 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 >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev