[hibernate-dev] Infinispan versions for Hibernate OGM

[Gunnar Morling]

Agreed :)

2015-12-18 11:53 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> To clarify, I don't have a immediate specific need to upgrade
> Infinispan within OGM, although since I'm working on an entire new
> module I'd rather code using the latest than have us to perform an
> upgrade later.
>
> But it's important we agree that rather than being obsessed with the
> modules I can simply upgtrade Infinispan because we have some reason,
> and we can agree that aligning with WildFly is a non-goal so I
> shouldn't be concerned with that, in case an upgrade was useful for
> the remote dialect.
>
> Sanne
>
>
>
> On 17 December 2015 at 10:14, Radim Vansa <rvansa at redhat.com> wrote:
>> On 12/16/2015 10:41 PM, Gunnar Morling wrote:
>>> Hi,
>>>
>>> Is there an actual need for 8.1 at this point (so does it provide
>>> features we really need in OGM?) or is this more a general/theoretical
>>> proposal?
>>>
>>> I like the idea in general, but we must carefully think through all
>>> the implications, such as what module slot to depend on in the OGM
>>> dialect and so on. I suppose the alias stuff may come in handy here.
>>
>> I think that the most important part is being independent, than choosing
>> the 'right' version. Infinispan 8.0 brought a few regressions
>> performance-wise, and developers are actively working on fixing those
>> (not sure how much of the effort landed in 8.1). 8.2 could bring quite
>> interesting scalability (in terms of concurrently processed requests)
>> improvements.
>>
>>>
>>> Question on Remote: can the 8.0 libs in WF talk to a 8.1 remote?
>>
>> Old HotRod client can always talk to new HotRod server. New HotRod
>> client may require configuration setting (limiting certain features) in
>> order to talk to old server.
>> In library=embedded mode, compatibility of different version in the same
>> cluster is *not* guaranteed even for micro releases.
>>
>> Radim
>>
>>>
>>> All in all, if there is a strong benefit for going to the latest ISPN
>>> right now, let's do it, otherwise I'd prefer if we sticked for now to
>>> what's provided and focused on getting the remote dialect fly. Let's
>>> life out the module obsession once we actually gain something from it
>>> ;)
>>>
>>> --Gunnar
>>>
>>>
>>>
>>> 2015-12-16 14:04 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>>> Hello all,
>>>>
>>>> we generally have been trying to target the versions of Infinispan
>>>> provided by the WildFly version we're targeting for compatibility with
>>>> a specific OGM release cycle.
>>>>
>>>> I would like to change that, and for example now switch to the latest
>>>> Infinispan 8.1.0.Final (rather than the one in WildFly 10 candidate
>>>> release, which would be 8.0.2.Final).
>>>>
>>>> Several reasons:
>>>>
>>>> # shall not use the WildFly Infinispan distribution
>>>>    in WildFly the specific Infinispan version being integrated is an
>>>> implementation detail.
>>>> People wanting to use Infinispan directly, or for other means than the
>>>> ones addressed by the WildFly clustering features which are based on
>>>> Infinispan (but don't expose it), should be encouraged to download the
>>>> Infinispan modules from the Infinispan project. We should apply (and
>>>> encourage) this practice too.
>>>>
>>>> # pick our own version
>>>>    it's obviously nicer for us to reserve ourselves the practical
>>>> benefits of being able to pick our own version according to needs,
>>>> rather than stick with wathever WildFly requires.
>>>>
>>>> # we might have a need for latest Infinispan
>>>>    probably no need to explain ;)
>>>> I don't with us to wait for an app-server update cycle when we need an
>>>> upstream patch.
>>>>
>>>> # don't aim at a single WildFly version
>>>>    while we're currently running integration tests with latest WildFly,
>>>> I think it's desirable to use that as a testing bed for the modules we
>>>> provide but not as a coupling factor for our dependency matrix.
>>>> In other words, let's prepare OGM to be able to produce modules for
>>>> different versions of the application servers (and not least other
>>>> application servers although that's unrelated).
>>>> Not least, the fact that the app server is sticking with some version
>>>> shouldn't have an impact to all of our users who have no interest in
>>>> this particular appserver at all.
>>>>
>>>> Am I missing any important counter argument?
>>>>
>>>> Thanks,
>>>> Sanne
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>> --
>> Radim Vansa <rvansa at redhat.com>
>> JBoss Performance Team
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev