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

kvs: refactor commit & fence #1343

Merged
merged 3 commits into from Feb 22, 2018

Conversation

4 participants
@chu11
Copy link
Contributor

chu11 commented Feb 20, 2018

In preparation for issue #1337 and not making that PR huge, this does a decent-refactoring on the commit & fence. The core change is the commit & fence data structures are now more decoupled. The commit data structure no longer contains a pointer to a fence and instead copies data in from the fence and stores it internally. The need for this is hopefully somewhat obvious for #1337 .

As a consequence, the internal fence data structure was cleaned up. I'm really happy with this refactoring, as the fence data structure now logically represents a "fence" more accurately. In that fences are no longer mergeable, can't have > 1 name, can't have more than one fence's operations stored in it, etc.

@chu11

This comment has been minimized.

Copy link
Contributor Author

chu11 commented Feb 20, 2018

hit a #731, restart build

@garlick

This comment has been minimized.

Copy link
Member

garlick commented Feb 20, 2018

When does the deep copy of the ops happen? That is potentially costly for a large value.

(Can it be avoided with json_incref/decref?)

@coveralls

This comment has been minimized.

Copy link

coveralls commented Feb 20, 2018

Coverage Status

Coverage decreased (-0.02%) to 78.882% when pulling 02e5764 on chu11:issue1337-part2 into f7247dd on flux-framework:master.

@chu11

This comment has been minimized.

Copy link
Contributor Author

chu11 commented Feb 20, 2018

The deep copy occurs when the commit is created, i.e. when it is "ready", i.e. when the fence count has been reached. We want to specifically have a fence's operations/names array not modified when a merge happens, which obviates the need for a copy at some point.

Now that I think of it, a shallow copy is probably safe here. As the array is the only thing we care about being new. The contents can still be references to the old values.

@garlick

This comment has been minimized.

Copy link
Member

garlick commented Feb 20, 2018

Ah that sounds good then.

As an aside, the use of "fence" and "commit" in KVS module is confusing to me. I think we ought to transition at some point to terms like the following:

transaction - a set of operations that are atomically applied to the namespace

commit - a request to apply a set of operations to the namespace

fence - a distributed (collective) request to apply a set of operations to the namespace

A commit/fence will be represented by one transaction, but a transaction may "contain" multiple commits when merging occurs.

We are already using these terms in the user facing API. We should try to make the server code match for clarity IMHO. It's my fault because at some point I refactored duplicate commit and fence code, and decided that a "commit" was just a special case of a fence. I think for the sake of clear terminology, it would have been better to go the other way.

@chu11 chu11 force-pushed the chu11:issue1337-part2 branch from e23ef6e to f3f4656 Feb 20, 2018

@chu11

This comment has been minimized.

Copy link
Contributor Author

chu11 commented Feb 20, 2018

looking through the code, I think that replacing the json_deep_copy() directly with json_copy() is safe here.

I'll go ahead and write up an issue for your comments above.

@chu11

This comment has been minimized.

Copy link
Contributor Author

chu11 commented Feb 21, 2018

hmmm. Saw

FAIL: t0001-basic.t 44 - flux-help command list can be extended

and

FAIL: t0015-cron.t 8 - restarted job restarts repeat count

and

PASS: t0016-cron-faketime.t 7 - flux-cron tab works for month
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.

possibly not related to this PR? Unless an outright corruption bug on my part, not sure how this would have caused the 1st & 3rd issues. Caused by an underlying bug we haven't seen in travis before? Gonna restart.

@codecov-io

This comment has been minimized.

Copy link

codecov-io commented Feb 21, 2018

Codecov Report

Merging #1343 into master will decrease coverage by 0.06%.
The diff coverage is 84.61%.

@@            Coverage Diff             @@
##           master    #1343      +/-   ##
==========================================
- Coverage    78.3%   78.24%   -0.07%     
==========================================
  Files         156      156              
  Lines       28407    28411       +4     
==========================================
- Hits        22245    22229      -16     
- Misses       6162     6182      +20
Impacted Files Coverage Δ
src/modules/kvs/fence.c 93.33% <100%> (+5.69%) ⬆️
src/modules/kvs/kvs.c 65.45% <75%> (-0.29%) ⬇️
src/modules/kvs/commit.c 79.07% <84.78%> (+0.6%) ⬆️
src/broker/module.c 83.79% <0%> (-1.68%) ⬇️
src/common/libflux/response.c 83.73% <0%> (-1.63%) ⬇️
src/broker/content-cache.c 73.43% <0%> (-1.3%) ⬇️
src/common/libflux/mrpc.c 85.49% <0%> (-1.18%) ⬇️
src/broker/modservice.c 80.58% <0%> (-0.98%) ⬇️
src/common/libutil/base64.c 95.07% <0%> (-0.71%) ⬇️
src/common/libflux/handle.c 83.66% <0%> (-0.5%) ⬇️
... and 5 more
@chu11

This comment has been minimized.

Copy link
Contributor Author

chu11 commented Feb 21, 2018

Running make -j32 check, on occasion I've been able to get some errors on catalyst. So perhaps I messed something up. Or if it isn't related to this PR, should hunt down what the issue is. So no merging for now.

@garlick

This comment has been minimized.

Copy link
Member

garlick commented Feb 21, 2018

On the errors above: there is no instance running during the flux-help test, and no KVS module loaded during the cron tests, so it seems impossible that it has anything to do with this PR.

Did you find some new failures on catalyst?

@chu11

This comment has been minimized.

Copy link
Contributor Author

chu11 commented Feb 21, 2018

The errors I'm seeing are seemingly random and all over the place. I've seen errors in basic, cron, pmi, kvs-stress, kvs-namespace, content-sqlite, wreck, content-cache.

I was able to see these errors on master. I ran make -j32 check against tag v0.8.0 a few times, and it unquestionably worked there. Taking a look.

@garlick garlick added this to To do in multi-user parallel jobs via automation Feb 22, 2018

@garlick garlick moved this from To do to In progress in multi-user parallel jobs Feb 22, 2018

chu11 added some commits Feb 14, 2018

modules/kvs: Decouple commit & fence
Copy several internal pieces of data from fence into commit, such
as ops and names.  Do not store fence internally in a commit
anymore.  Add new getter functions commit_get_ops(), commit_get_names(),
and commit_get_flags() as a result.

Adjust commit_mgr_merge_ready_commits() to merge based on the contents
within commit and not call fence_merge().

Update unit tests appropriately.
modules/fence: Remove fence_merge()
With changes to commit_mgr_merge_ready_commits(), this function was
no longer used.
modules/kvs: Refactor fence names array
With recent changes, fence no longer needs to store an array
of names, it need only store the single name of the fence.

As a consequence, fence_get_json_names() is now fence_get_name()
and returns a const char * instead of a json_t *.

With this change, the fence data structure now more closely maps
to what a "fence" is, as it can only contain one name, and the
set of operations on that name.

Update unit tests appropriately.

@chu11 chu11 force-pushed the chu11:issue1337-part2 branch from f3f4656 to 02e5764 Feb 22, 2018

@chu11

This comment has been minimized.

Copy link
Contributor Author

chu11 commented Feb 22, 2018

just rebased

@garlick

This comment has been minimized.

Copy link
Member

garlick commented Feb 22, 2018

Did the json_copy() change make it in?

@chu11

This comment has been minimized.

Copy link
Contributor Author

chu11 commented Feb 22, 2018

yup

@garlick

This comment has been minimized.

Copy link
Member

garlick commented Feb 22, 2018

Restarted a builder that had failed apt-get

@garlick

This comment has been minimized.

Copy link
Member

garlick commented Feb 22, 2018

Looks good!

@garlick garlick merged commit f2074ee into flux-framework:master Feb 22, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls Coverage decreased (-0.02%) to 78.882%
Details

multi-user parallel jobs automation moved this from In progress to Done Feb 22, 2018

@chu11 chu11 self-assigned this Feb 23, 2018

@grondo grondo referenced this pull request May 10, 2018

Closed

0.9.0 Release #1479

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.