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

[Dan Berindei]

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 <sanne at 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.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
>>
>
> _______________________________________________
> 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/da920e99/attachment.html