Skip to content
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

Backup lost if "maxIdle" property is used #9153

Closed
MeYoGui opened this issue Oct 21, 2016 · 8 comments

Comments

Projects
None yet
3 participants
@MeYoGui
Copy link

commented Oct 21, 2016

Hi,

I'm facing an issue with an IMap distributed on two different nodes.

I'm using this IMap with :

  • only one "Async Backup"
  • MaxIdleSeconds set to 10 seconds.
  • readBackupData set to false
  • Default eviction-policy (NONE)

In the beginning I'm putting some values in the map but after that the values are only accessed and not updated for quite a long period (like 10 or 15 minutes).

What is the problem ?

In the beginning (before 10 seconds elapsed), the backup is working great ...

image

But after 10 seconds : all the backups are lost !

image

If I change the amount of seconds for the MaxIdle property to an higher value (let's say 300 seconds) then everything is working well until 300 seconds.

The backups gets evicted if I use MaxIdle property, is that a normal behavior ?

For information : using a "sync" backup didn't solve the problem at all.
The only "workaround"is to use a TTL instead but that's not what I want because my values are not updated for a certain amount of time and I want eviction if not "accessed" for 10 seconds.

I don't have any workaround here and it's quite a severe issue to integrate Hazelcast in our system.
If you want more information, don't hesitate.

Hazelcast version : 3.7.2

@jerrinot jerrinot added the Team: Core label Oct 21, 2016

@MeYoGui MeYoGui changed the title Backup lost if max idle too low ? Backup lost if "maxIdle" property is used Oct 21, 2016

@jerrinot

This comment has been minimized.

Copy link
Contributor

commented Oct 21, 2016

@MeYoGui: thanks for reporting this. this appears as a bug to me.
@ahmetmircik: I guess this looks like a weakness in the MaxIdleSeconds option to me, am I right?

@jerrinot jerrinot added this to the 3.8 milestone Oct 21, 2016

@ahmetmircik

This comment has been minimized.

Copy link
Member

commented Oct 21, 2016

Hi @MeYoGui, if you are using imap#get, can you please try to get value via EntryProcessor by using imap#executeOnKey? You can touch backup entry with EntryBackupProcessor in this case and expiration time will be shifted.

@MeYoGui

This comment has been minimized.

Copy link
Author

commented Oct 22, 2016

Hi @ahmetmircik,
Yes I'm using get() method from IMap.
I'll try your solution with the executeOnKey() method as you propose. I'll let you know if it's working.

I'm just not sure about the performance of this way of doing... Is that efficient ? (I'm doing almost 3k get/s)
Nevertheless, I keep thinking that a get should touch the backup.

@MeYoGui

This comment has been minimized.

Copy link
Author

commented Oct 24, 2016

I tried via the EntryProcessor. It worked well, the backup is now touched and I haven't seen any lack of performance.

I still see two negative points about this :

  • the code is less intuitive now
  • we lose the stats about the "get" behavior

You may update your documentation to tell about this behavior as this is not expected at all (and quite dangerous : backup is lost), don't you think ?

Are you still going to change the get() method to touch the backup ?

@MeYoGui

This comment has been minimized.

Copy link
Author

commented Oct 26, 2016

Hi @ahmetmircik, any news about this issue ? What is the plan for this ?

@ahmetmircik

This comment has been minimized.

Copy link
Member

commented Oct 26, 2016

Sorry just seen your comment, indeed my suggestion was a workaround. When we have a feasible solution, we will update this ticket. Please watch this issue for the updates and thanks for reporting it.

@ahmetmircik ahmetmircik reopened this Oct 26, 2016

@jerrinot jerrinot modified the milestones: Backlog, 3.8 Dec 6, 2016

@ahmetmircik ahmetmircik self-assigned this Jan 4, 2017

@ahmetmircik ahmetmircik modified the milestones: 3.8, Backlog Jan 4, 2017

@jerrinot jerrinot modified the milestones: 3.9, 3.8 Jan 24, 2017

@jerrinot

This comment has been minimized.

Copy link
Contributor

commented Jan 24, 2017

I am moving this into 3.9 as it requires major changes with consequences.
I see this is a serious deficiency and I'll do my best to have this in the plan for 3.9.

@MeYoGui

This comment has been minimized.

Copy link
Author

commented Jan 24, 2017

Allright, I'll keep an eye on this 👍 Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.