[infinispan-dev] ISPN-2281 effect on Infinispan Server

[Sanne Grinovero]

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.berindei at gmail.com> wrote:

>
>
>
> On Fri, May 3, 2013 at 1:49 PM, Galder Zamarreño <galder at 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 <ttarrant at 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 at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> --
>> Galder Zamarreño
>> galder at redhat.com
>> twitter.com/galderz
>>
>> Project Lead, Escalante
>> http://escalante.io
>>
>> Engineer, Infinispan
>> http://infinispan.org
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130507/38dc8e79/attachment-0001.html