[infinispan-dev] Partial updates in 2LC

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] Partial updates in 2LC

Galder Zamarreno
Hey Radim,

We've had some chats in the past where we discussed the behaviour of non-tx 2LC and partial updates. I've wrote a couple of tests [1] to see how things behave: 

For a repl read-write, entity cache, if the failure happens on the async FutureUpdate call, that's fine because the Tombstone has already been sent and the cache won't return anything.

If the failure happens when the Tombstone is sent, we seem to have a problem because it results in stale data in the node that failed to apply the Tombstone. The FutureUpdate that comes after the Tombstone cannot apply because it doesn't find the Tombstone.

Sync logs any errors but does not propagate them [2]. Is there any reason for not rethrowing the exception? I tried to rethrow it and the JDBC transaction rolls back, which is not too bad cos at least that way both nodes contain the last committed data.

As a side note, the CorrectnessTestCase subclasses are not running by default, we should change that.

Cheers,
Galder



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

Re: [infinispan-dev] Partial updates in 2LC

Galder Zamarreno
Forgot to point out, here is where Sync logs the exception:
https://github.com/infinispan/infinispan/blob/master/hibernate/cache-v53/src/main/java/org/infinispan/hibernate/cache/v53/impl/Sync.java#L78

On Fri, Dec 14, 2018 at 10:05 AM Galder Zamarreno <[hidden email]> wrote:
Hey Radim,

We've had some chats in the past where we discussed the behaviour of non-tx 2LC and partial updates. I've wrote a couple of tests [1] to see how things behave: 

For a repl read-write, entity cache, if the failure happens on the async FutureUpdate call, that's fine because the Tombstone has already been sent and the cache won't return anything.

If the failure happens when the Tombstone is sent, we seem to have a problem because it results in stale data in the node that failed to apply the Tombstone. The FutureUpdate that comes after the Tombstone cannot apply because it doesn't find the Tombstone.

Sync logs any errors but does not propagate them [2]. Is there any reason for not rethrowing the exception? I tried to rethrow it and the JDBC transaction rolls back, which is not too bad cos at least that way both nodes contain the last committed data.

As a side note, the CorrectnessTestCase subclasses are not running by default, we should change that.

Cheers,
Galder



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

Re: [infinispan-dev] Partial updates in 2LC

Radim Vansa
You're right, it would be wiser for the Sync to let the exception be
propagated. I can't recall why I've caught the exception terminally.

About CorrectnessTestCase - this is a stress test, and as such we're not
running it by default. TBH it's been a while since I've last started
that... It also has some parameters that I used to tune manually
(commenting certain parts), such as running evictAll which dramatically
lowers the likelihood of other events to happen.

Radim

On 12/14/2018 10:08 AM, Galder Zamarreno wrote:

> Forgot to point out, here is where Sync logs the exception:
> https://github.com/infinispan/infinispan/blob/master/hibernate/cache-v53/src/main/java/org/infinispan/hibernate/cache/v53/impl/Sync.java#L78
>
> On Fri, Dec 14, 2018 at 10:05 AM Galder Zamarreno <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hey Radim,
>
>     We've had some chats in the past where we discussed the behaviour
>     of non-tx 2LC and partial updates. I've wrote a couple of tests
>     [1] to see how things behave:
>
>     For a repl read-write, entity cache, if the failure happens on the
>     async FutureUpdate call, that's fine because the Tombstone has
>     already been sent and the cache won't return anything.
>
>     If the failure happens when the Tombstone is sent, we seem to have
>     a problem because it results in stale data in the node that failed
>     to apply the Tombstone. The FutureUpdate that comes after the
>     Tombstone cannot apply because it doesn't find the Tombstone.
>
>     Sync logs any errors but does not propagate them [2]. Is there any
>     reason for not rethrowing the exception? I tried to rethrow it and
>     the JDBC transaction rolls back, which is not too bad cos at least
>     that way both nodes contain the last committed data.
>
>     As a side note, the CorrectnessTestCase subclasses are not running
>     by default, we should change that.
>
>     Cheers,
>     Galder
>
>     [1]
>     https://github.com/galderz/infinispan/commit/2934e0b3e8ab9af5fb1471c5fdbb0716e5a11c31
>     [2]
>     https://github.com/infinispan/infinispan/blob/master/hibernate/cache-v53/src/main/java/org/infinispan/hibernate/cache/v53/impl/Sync.java
>

--
Radim Vansa <[hidden email]>
JBoss Performance Team

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