[infinispan-dev] IRC chat: HB + I9

Wed May 24 12:04:12 EDT 2017

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