[hibernate-dev] Infinispan versions for Hibernate OGM

[Sanne Grinovero]

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