RE: EntryProcessor in ATOMIC cache and CLOCK versioning mode

[Alexey Goncharuk]

Igniters,

I want to bring community attention to the ticket [1] once again since it
raises a lot of confusion among Ignite users [2] and I would like this to
be addressed in 1.6.

The alternatives for the case when entry processor is used in CLOCK mode
are:
 * Print a warning, but still allow to use invoke() since it will work if
key access is synchronized by external means.
 * Throw an exception and force users to switch to PRIMARY mode when
invoke() is used.

Any thoughts / other suggestions?

-- AG

[1] https://issues.apache.org/jira/browse/IGNITE-2088
[2]
http://apache-ignite-users.70518.x6.nabble.com/Version-issue-with-concurrent-cache-updates-EntryProcessor-td2896.html

[Denis Magda]

Alex,

I would show the warning on a cache startup regarding the consequences
of CLOCK mode usage and add a note to invoke() documentation in advance.

--
Denis

On 2/9/2016 2:29 PM, Alexey Goncharuk wrote:

> Igniters,
>
> I want to bring community attention to the ticket [1] once again since it
> raises a lot of confusion among Ignite users [2] and I would like this to
> be addressed in 1.6.
>
> The alternatives for the case when entry processor is used in CLOCK mode
> are:
>   * Print a warning, but still allow to use invoke() since it will work if
> key access is synchronized by external means.
>   * Throw an exception and force users to switch to PRIMARY mode when
> invoke() is used.
>
> Any thoughts / other suggestions?
>
> -- AG
>
> [1] https://issues.apache.org/jira/browse/IGNITE-2088
> [2]
> http://apache-ignite-users.70518.x6.nabble.com/Version-issue-with-concurrent-cache-updates-EntryProcessor-td2896.html
>

[Alexey Goncharuk]

After a second thought, I think the warning should be printed anyways when
CLOCK versioning mode is used because it does not guarantee happens-before
relationship when cache operations are invoked on different nodes (see an
example in pseudo-code below). Essentially, when cache operations are
invoked on different nodes within a time span smaller or equal than time
sync error, they are considered to be run concurrently.

IgniteCache cache = ignite.cache("name");

cache.put(1, 1);

// Select a random remote node.
ClusterGroup grp = ignite.cluster().forRemotes().forRandom();

ignite.compute(grp).call(new Callable() {
    public Object call() throws Exception {
        cache.put(1, 2); // This does not guarantee to succeed in CLOCK
mode.
    }
});

// This may fail in CLOCK mode.
assert cache.get(1) == 2;

I agree that the documentation must be updated accordingly, and I think the
warning printed should contain a link to the page.

Any other thoughts?

[dsetrakyan]

I don’t think there is anything else that can be done in addition to
printing our a warning and fixing documentation. Looks like an easy fix, I
marked it with “newbie”, so some of the new community members could pick it
up.

On Tue, Feb 9, 2016 at 5:17 AM, Alexey Goncharuk <[hidden email]
> wrote:

> After a second thought, I think the warning should be printed anyways when
> CLOCK versioning mode is used because it does not guarantee happens-before
> relationship when cache operations are invoked on different nodes (see an
> example in pseudo-code below). Essentially, when cache operations are
> invoked on different nodes within a time span smaller or equal than time
> sync error, they are considered to be run concurrently.
>
> IgniteCache cache = ignite.cache("name");
>
> cache.put(1, 1);
>
> // Select a random remote node.
> ClusterGroup grp = ignite.cluster().forRemotes().forRandom();
>
> ignite.compute(grp).call(new Callable() {
>     public Object call() throws Exception {
>         cache.put(1, 2); // This does not guarantee to succeed in CLOCK
> mode.
>     }
> });
>
> // This may fail in CLOCK mode.
> assert cache.get(1) == 2;
>
> I agree that the documentation must be updated accordingly, and I think the
> warning printed should contain a link to the page.
>
> Any other thoughts?
>