Agreed :)
2015-12-18 11:53 GMT+01:00 Sanne Grinovero <sa...@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 <rva...@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 <sa...@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@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> -- >> Radim Vansa <rva...@redhat.com> >> JBoss Performance Team >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
