[infinispan-dev] IRC chat: HB + I9

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[infinispan-dev] IRC chat: HB + I9

Galder Zamarreño
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@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


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] IRC chat: HB + I9

Paul Ferraro
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 <[hidden email]> 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@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
>

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] IRC chat: HB + I9

Radim Vansa
On 05/16/2017 05:06 PM, Paul Ferraro 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?

I have worded that a bit incorrectly - it offers no benefits in terms of
number of RPCs you have to execute. Yes, keeping the replication
semantics, replication should hold the cached data on all nodes instead
of only single node.

The thing is that 2LC currently tweaks the actual mode so extensively
that the maintenance burden is too much on 2LC itself. I perceive the
difference between cache modes in the algorithm how operations are
routed through the cluster, not only how these entries are stored
(though that's just the other face of the coin). And while I've mostly
kept the 'storage' part, the routing has changed very much in order to
support transparent repeatable-read isolation which I expect from a DB.
(Note: while Infinispan claims to support RR, the meaning is different
than traditional DBs' RR - actually it's a hybrid between RR and
snapshot isolation [1])

[1]
https://github.com/infinispan/infinispan/blob/master/documentation/src/main/asciidoc/glossary/glossary.asciidoc#repeatable-read

>
> Paul
>
> On Tue, May 16, 2017 at 9:03 AM, Galder Zamarreño <[hidden email]> 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@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 <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] IRC chat: HB + I9

Galder Zamarreño
In reply to this post by Paul Ferraro
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 <[hidden email]> 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 <[hidden email]> 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@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
>>


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] IRC chat: HB + I9

Galder Zamarreño
One final thing, [1] requires ISPN-7853 fix, which will be part of 9.0.1.

I know the branch currently points to 9.1.0-SNAPSHOT. That was just simply cos I tested out the fix in master first.

Cheers,
--
Galder Zamarreño
Infinispan, Red Hat

> On 23 May 2017, at 15:07, Galder Zamarreño <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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@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
>>>
>


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] IRC chat: HB + I9

Radim Vansa
In reply to this post by Galder Zamarreño
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 <[hidden email]> 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 <[hidden email]> 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@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 <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] IRC chat: HB + I9

Sanne Grinovero-3
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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@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 <[hidden email]>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] IRC chat: HB + I9

Paul Ferraro
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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@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 <[hidden email]>
>> JBoss Performance Team
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] IRC chat: HB + I9

Galder Zamarreño
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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@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 <[hidden email]>
>>> JBoss Performance Team
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] IRC chat: HB + I9

Steve Ebersole

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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@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 <[hidden email]>
>>> JBoss Performance Team
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] IRC chat: HB + I9

Galder Zamarreño
Thx Steve for your input.

Seems like everyone agrees moving to Infinispan might be best option, so I'll be sending a proposal to the list in the next few days.

Cheers,
--
Galder Zamarreño
Infinispan, Red Hat

> On 25 May 2017, at 15:31, Steve Ebersole <[hidden email]> wrote:
>
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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@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 <[hidden email]>
> >>> JBoss Performance Team
> >>>
> >>> _______________________________________________
> >>> infinispan-dev mailing list
> >>> [hidden email]
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...