Expected behavior of clear method #642

Closed
kmaehashi opened this Issue Feb 3, 2014 · 7 comments

Comments

Projects
None yet
4 participants
Owner

kmaehashi commented Feb 3, 2014

For standalone-mode, we expect "clear" method to "reset the model to the initial state."

What is the expected behavior of clear method used in distributed mode, including timing issues between get_diff, put_diff and clear?

@kmaehashi kmaehashi modified the milestones: Near Future, Far Future Mar 3, 2014

@kumagi kumagi modified the milestone: Near Future Mar 3, 2014

Owner

kmaehashi commented Apr 7, 2014

The problem when clear is called in distributed mode is in case that clear is called between get_diff and put_diff so that clear-ed model is overwritten by put_diff.

So in distributed mode, I think clear method should behave like this:

  • Acquire MIX master lock
  • Increment version number
  • Run MIX (so all the other nodes will run get_model and copy empty model from node which received clear)
Owner

suma commented Apr 7, 2014

I think clear should remove diff.
NOTE: Current jubaproxy broadcasts clear to all servers. We have to take care if we run MIX when clear called.

@kmaehashi kmaehashi modified the milestones: 0.5.4, Near Future Apr 7, 2014

Owner

kumagi commented Apr 7, 2014

Proxy should get ZK lock in case clear.
clear methods should be available in all algorithms, so we should make clear method as a default.

Owner

unnonouno commented Apr 14, 2014

I also think diff must to be cleared. A user expects clear method overwrites all models of servers.

Owner

unnonouno commented Apr 14, 2014

How about remaking a driver object on clear method?

Owner

kmaehashi commented Apr 14, 2014

Discussion from meeting on 2014-04-14:

  • MIX triggered before clear and load should be rejected.
  • Provide management of generation number (which increments when clear or load is called) in framework layer, so that we don't have to think of algorithm layer.
Owner

kmaehashi commented Apr 22, 2014

In the meeting on 2014-04-21, we agreed to close this discussion issue and raise another one for implementation. #757

@kmaehashi kmaehashi closed this Apr 22, 2014

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