[infinispan-dev] IRC chat: HB + I9

Steve Ebersole steve at hibernate.org
Thu May 25 09:31:38 EDT 2017


A lot to read through here so I apologize up front if I missed something...

So to be fair I am biased as I would really like to not have to deal with
these integrations :)  That said, I do really believe that the best option
is to move this code out of the hibernate/hibernate-orm repo.  To me that
could mean a separate repo altogether (infinispan/infinispan-hibernate-l2c,
or sim) or into infinispan proper if Infinispan already has Hibernate
dependency as Sanne mentioned somewhere.

As far as Hibernate..  master is in fact 5.2, 6.0 exists just in my fork
atm - we are still discussing the exact event that should trigger moving
that 6.0 branch up stream.  6.0 timeline is still basically unknown
especially as far as a Final goes.

On Wed, May 24, 2017, 11:04 AM Galder Zamarreño <galder at redhat.com> wrote:

> Adding Steve,
>
> Scott Marlow just reminded me that you've advocated for Infinispan 2LC
> provider to be moved to Infinispan source tree [2].
>
> So, you might want to add your thoughts to this thread?
>
> Cheers,
>
> [2]
> http://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/2015/%23hibernate-dev.2015-08-06.log.html
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
> > On 24 May 2017, at 17:56, Paul Ferraro <paul.ferraro at redhat.com> wrote:
> >
> > Option #4 would be my preference as well.  The integration into WF has
> > become increasingly cumbersome as the pace of Infinispan releases (and
> > associated API changes) has increased.  I would really rather avoid
> > having to create and maintain forks of hibernate-infinispan to support
> > the combination of Hibernate and Infinispan that don't exist in the
> > upstream codebase.
> >
> > On Wed, May 24, 2017 at 11:18 AM, Sanne Grinovero <sanne at infinispan.org>
> wrote:
> >> I would suggest option 4# : move the 2LC implementation to Infinispan.
> >>
> >> I already suggested this in the past, but to remind the main arguments
> I have:
> >>
> >> - neither repository is ideal, but having it here vs there is not
> >> just moving the problem as the two projects are different, have
> >> different timelines and different backwards compatibility policies.
> >>
> >> - Infinispan already depends on several Hibernate projects - even
> >> directly to Hibernate ORM itself via the JPA cachestore and indirectly
> >> via Hibernate Search and WildFly - so moving the Infinispan dependency
> >> out of the Hibernate repository helps to linearize the build for one
> >> consistent stack.
> >> For example right now WildFly master contains a combination of
> >> Hibernate ORM and Infinispan 2LC, which is not the same combination as
> >> tested by running the 2LC testsuite; this happens all the time and
> >> brings its own set of issues & delays.
> >>
> >> - Infinispan changes way more often - and as Radim already suggested
> >> in his previous email - there's more benefit in having such advanced
> >> code more closely tied to Infinispan so that it can benefit from new
> >> capabilities even though these might not be ready to be blessed as
> >> long term API. The 2LC SPI in Hibernate on the other hand is stable,
> >> and has to stay stable anyway, for other reasons not least integration
> >> with other providers, so there's no symmetric benefit in having this
> >> code in Hibernate.
> >>
> >> - Infinispan releases breaking changes with a more aggressive pace.
> >> It's more useful for Infinispan 9 to be able to support older versions
> >> of Hibernate ORM, than the drawback of a new ORM release not having
> >> yet an Infinispan release compatible. This last point is the only
> >> drawback I can see, and franckly it's both a temporary situation as
> >> Infinispan can catch up quickly and a very inlikely situation as
> >> Hibernate ORM is unlikely to change these SPIs in e.g. the next major
> >> release 6.0.
> >>
> >> - Infinispan occasionally breaks expectations of the 2LC code, as
> >> Galder just had to figure out with a painful upgrade. We can all agree
> >> that these changes are necessary, but I strongly believe it's useful
> >> to *know* about such breackages ASAP from the testsuite, not half a
> >> year later when a major dependency upgrade propagates to other
> >> projects.
> >>
> >> - The Hibernate ORM would appreciate getting rid of debugging
> >> clustering and networking issues when there's the occasional failure,
> >> which are stressful as they are out of their area of expertise.
> >>
> >> I hope that makes sense?
> >>
> >> Thanks,
> >> Sanne
> >>
> >>
> >>
> >> On 24 May 2017 at 08:49, Radim Vansa <rvansa at redhat.com> wrote:
> >>> Hi Galder,
> >>>
> >>> I think that (3) is simply not possible (from non-technical
> perspective)
> >>> and I don't think we have the manpower to maintain 2 different modules
> >>> (2). The current version does not seem ready (generic enough) to get
> >>> into Infinispan, so either (1), or a lot of more work towards (4)
> (which
> >>> would be my preference).
> >>>
> >>> I haven't thought about all the steps for (4), but it seems that
> >>> UnorderedDistributionInterceptor and LockingInterceptor should get into
> >>> Infinispan as a flavour of repl/dist cache mode that applies update in
> >>> parallel on all owners without any ordering; it's up to the user to
> >>> guarantee that changes to an entry are commutative.
> >>>
> >>> The 2LC code itself shouldn't use the
> >>> TombstoneCallInterceptor/VersionedCallInterceptor now that there is the
> >>> functional API, you should move the behavior to functions.
> >>>
> >>> Regarding the invalidation mode, I think that a variant that would void
> >>> any writes to the entry (begin/end invalidation) could be moved to
> >>> Infinispan, too. I am not even sure if current invalidation in
> >>> Infinispan is useful - you can't transparantly cache access to
> >>> repeatable-read isolated DB (where reads block writes), but the
> blocking
> >>> as we do in 2LC now is probably too strong if we're working with DB
> >>> using just read committed as the isolation level. I was always trying
> to
> >>> enforce linearizability, TBH I don't know how to write a test that
> would
> >>> test a more relaxed consistency.
> >>>
> >>> Btw., I've noticed that you've set isolation level to READ_COMMITTED in
> >>> default configuration - isolation level does not apply at all to
> >>> non-transactional caches, so please remove that as it would be just a
> noise.
> >>>
> >>> Radim
> >>>
> >>> On 05/23/2017 03:07 PM, Galder Zamarreño wrote:
> >>>> Hi all,
> >>>>
> >>>> I've just finished integrating Infinispan with a HB 6.x branch Steve
> had, all tests pass now [1].
> >>>>
> >>>> Yeah, we didn't commit on the final location for these changes.
> >>>>
> >>>> As far as I know, Hibernate master is not 6.x, but rather 5.2.x.
> There's no 5.2.x branch in Hibernate main repo. 6.x is just a branch that
> Steve has.
> >>>>
> >>>> These are the options availble to us:
> >>>>
> >>>> 1. Integrate 9.x provider as part of 'hibernate-infinispan' in
> Hibernate 6.x branch.
> >>>>
> >>>> 2. Integrate 9.x provider as part of a second Infinispan module in
> Hibernate 5.x branch.
> >>>>
> >>>> 3. Integrate 9.x provider as part of 'hibernate-infinispan' in
> Hibernate 5.x branch. This is problematic for since the provider is not
> backwards compatible.
> >>>>
> >>>> 4. Integrate 9.x provider in infinispan and deliver it as part of
> Infinispan rather than Hibernate.
> >>>>
> >>>> I'm not sure which one I prefer the most TBH... 1. is the ideal
> solution but doesn't seem there will be a Hibernate 6.x release for a
> while. 2./3./4. all have their downsides... :\
> >>>>
> >>>> Thoughts?
> >>>>
> >>>> [1] https://github.com/galderz/hibernate-orm/commits/t_i9x_v2
> >>>> --
> >>>> Galder Zamarreño
> >>>> Infinispan, Red Hat
> >>>>
> >>>>> On 16 May 2017, at 17:06, Paul Ferraro <paul.ferraro at redhat.com>
> wrote:
> >>>>>
> >>>>> Thanks Galder.  I read through the infinispan-dev thread on the
> >>>>> subject, but I'm not sure what was concluded regarding the eventual
> >>>>> home for this code.
> >>>>> Once the testsuite passes, is the plan to commit to hibernate master?
> >>>>> If so, I will likely fork
>          these changes into a WF module (and adapt it
> >>>>> for Hibernate 5.1.x) so that WF12 can move to JGroups4+Infinispan9
> >>>>> until Hibernate6 is integrated.
> >>>>>
> >>>>> Radim - one thing you mentioned on that infinispan-dev thread puzzled
> >>>>> me: you said that invalidation mode offers no benefits over
> >>>>> replication.  How is that possible?  Can you elaborate?
> >>>>>
> >>>>> Paul
> >>>>>
> >>>>> On Tue, May 16, 2017 at 9:03 AM, Galder Zamarreño <galder at redhat.com>
> wrote:
> >>>>>> I'm on the move, not sure if Paul/Radim saw my replies:
> >>>>>>
> >>>>>> <pferraro> galderz, rvansa: Hey guys - is there a plan for
> Hibernate &
> >>>>>>    ISPN 9?
> >>>>>> <rvansa> pferraro: Galder has been working on that
> >>>>>> <rvansa> pferraro: though I haven't seen any results but a list of
> >>>>>>    stuff that needs to be changed
> >>>>>> <pferraro> galderz: which Hibernate branch are you targeting?
> >>>>>> <rvansa> pferraro: 5.2, but there are minute differences between 5.x
> >>>>>>    in terms of the parts that need love to get Infinispan 9 support
> >>>>>> *** Mode change: +v vblagoje on #infinispan by ChanServ
> >>>>>>    (ChanServ at services.)
> >>>>>> <pferraro> rvansa: are you suggesting that 5.0 or 5.1 branches will
> be
> >>>>>>    adapted to additionally support infinispan 9?  how is that
> >>>>>>    possible?
> >>>>>>> pferraro: i'm working on it as we speak...
> >>>>>>> pferraro: down to 16 failuresd
> >>>>>>> pferraro: i started a couple of months ago, but had talks/demos to
> >>>>>>    prepare
> >>>>>>> pferraro: i've got back to working on it this week
> >>>>>> ...
> >>>>>>> pferraro: rvansa
> >>>>>>> rvansa: minute differences my ass ;p
> >>>>>>> pferraro: did you see my replies?
> >>>>>>> i got disconnected while replying...
> >>>>>> <pferraro> hmm - no - I didn't
> >>>>>> <pferraro> galderz: ^
> >>>>>>> pferraro: so, working on the HB + I9 integration as we speak
> >>>>>>> pferraro: i started a couple of months back but had talks/demos to
> >>>>>>    prepare and had to put that aside
> >>>>>>> pferraro: i'm down to 16 failures
> >>>>>>> pferraro: serious refactoring required of the integration to get it
> >>>>>>    to compile and the tests to pass
> >>>>>>> pferraro: need to switch to async interceptor stack in 2lc
> >>>>>>    integration and get all the subtle changes right
> >>>>>>> pferraro: it's a painstaking job basically
> >>>>>>> pferraro: i'm working on
> >>>>>>    https://github.com/galderz/hibernate-orm/tree/t_i9x_v2
> >>>>>>> pferraro: i can't remember where i branched off, but it's a branch
> >>>>>>    that steve had since master was focused on 5.x
> >>>>>>> pferraro: i've no idea when/where we'll integrate this, but one
> >>>>>>    thing is for sure: it's nowhere near backwards compatible
> >>>>>>> actually, fixed one this morning, so down to 15 failures
> >>>>>>> pferraro: any suggestions/wishes?
> >>>>>>> is anyone out there? ;)
> >>>>>> Cheers,
> >>>>>> --
> >>>>>> Galder Zamarreño
> >>>>>> Infinispan, Red Hat
> >>>>>>
> >>>
> >>>
> >>> --
> >>> Radim Vansa <rvansa at redhat.com>
> >>> JBoss Performance Team
> >>>
> >>> _______________________________________________
> >>> 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/20170525/cf30f5d8/attachment-0001.html 


More information about the infinispan-dev mailing list