New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[map] Updates with IMap#putTransient should trigger EntryUpdatedListener #10077

Closed
ahmetmircik opened this Issue Mar 14, 2017 · 9 comments

Comments

Projects
None yet
3 participants

@ahmetmircik ahmetmircik added this to the 3.8.2 milestone Mar 14, 2017

@vbekiaris

This comment has been minimized.

Contributor

vbekiaris commented Mar 14, 2017

Test (2 ADDED events are triggered instead of 1 ADDED & 1 UPDATED):

    @Test
    public void testPutTransient_triggersEntryEvents() throws InterruptedException {
        final IMap<String, String> map = getInstance().getMap("testPutTransient_triggersEntryEvents");
        final CountDownLatch addedLatch = new CountDownLatch(1);
        final CountDownLatch updatedLatch = new CountDownLatch(1);
        map.addEntryListener(new EntryAdapter<String, String>() {
            @Override
            public void entryAdded(EntryEvent<String, String> e) {
                addedLatch.countDown();
            }

            @Override
            public void entryUpdated(EntryEvent<String, String> event) {
                updatedLatch.countDown();
            }

        }, true);
        map.putTransient("hello", "world", 0, SECONDS);
        map.putTransient("hello", "another world", 0, SECONDS);
        assertOpenEventually(addedLatch);
        assertOpenEventually(updatedLatch);
    }
@neilstevenson

This comment has been minimized.

neilstevenson commented Apr 28, 2017

See http://stackoverflow.com/questions/43659013/why-does-hazelcast-imap-puttransient-fire-the-entryaddedlistener

The provided code snippet doesn't function correctly on 3.8.1. One ADDED and then seven UPDATED events which is correct, but followed by EVICTED which is incorrect.

@neilstevenson neilstevenson reopened this Apr 28, 2017

@ahmetmircik

This comment has been minimized.

Member

ahmetmircik commented Apr 28, 2017

see this: #10082 (comment)

@ahmetmircik ahmetmircik modified the milestones: 3.9, 3.8.1 Jun 23, 2017

@mmedenjak mmedenjak changed the title from Updates with IMap#putTransient should trigger EntryUpdatedListener to [map] Updates with IMap#putTransient should trigger EntryUpdatedListener Jul 11, 2017

@ahmetmircik

This comment has been minimized.

Member

ahmetmircik commented Jul 12, 2017

@neilstevenson Noticed that there is no javaDoc for the relation of regular put(k,v) and TTL. I would like to close this issue by documenting that relation like this:

If entry has a TTL associated with it (either with map config or with explicit ttl-ed put),put(k,v)only shifts expiration time and doesn't cancel existing TTL.

WDYT?

@neilstevenson

This comment has been minimized.

neilstevenson commented Jul 18, 2017

I view that put(K,V) implies you get the default TTL

It you do put(key1, value1) and put(key2, value2) at the same time, you should expect them to expire together or not at all.

Current behaviour is that they could expire at radically different times, due to previous operations, which doesn't seem right.

@ahmetmircik

This comment has been minimized.

Member

ahmetmircik commented Jul 18, 2017

That can be possible if we choose entry creationTime as TTL-start-time instead of lastUpdateTime. Is this what you want? If yes, this seems a new feature request and we can create a new issue for it.

@neilstevenson

This comment has been minimized.

neilstevenson commented Jul 19, 2017

This should pass

// 1. Put with timeout
imap.put("hello", "world", 5L, TimeUnit.SECONDS);
TimeUnit.SECONDS.sleep(2L);

// 2. Put without timeout
imap.put("hello", "again");
imap.out("goodbye", "issue10077");

// 3. Wait to "prove" timeout has or hasn't occurred
TimeUnit.SECONDS.sleep(10L);

// 4. Test
assertThat(imap.containsKey("hello").equals(imap.containsKey("goodbye")), is(true));

Or something better. Waiting for the timeout isn't quite safe, but you get the idea.

If two keys are inserted without a timeout in step 2, what happened to one of them in step 1 is irrelevant.

@ahmetmircik

This comment has been minimized.

Member

ahmetmircik commented Jul 20, 2017

Ok this makes sense.
But i see this as a behavioral change. Can you file an issue for 4.0?

@ahmetmircik

This comment has been minimized.

Member

ahmetmircik commented Jul 21, 2017

created an issue for the discussion above: #10965

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment