-
Notifications
You must be signed in to change notification settings - Fork 62
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
Graceful stop #205
Graceful stop #205
Conversation
@diasdavid any comments? |
package.json
Outdated
@@ -100,7 +100,7 @@ | |||
"detect-port": "^1.2.2", | |||
"dirty-chai": "^2.0.1", | |||
"go-ipfs-dep": "0.4.13", | |||
"ipfs": "^0.27.5", | |||
"ipfs": "github:ipfs/js-ipfs", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's hold this PR until we have a new release of js-ipfs (it can happen soon).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Codecov Report
@@ Coverage Diff @@
## master #205 +/- ##
=========================================
Coverage ? 86.92%
=========================================
Files ? 17
Lines ? 673
Branches ? 0
=========================================
Hits ? 585
Misses ? 88
Partials ? 0
Continue to review full report at Codecov.
|
@dryajov I've rebased on you changes. The Still waiting on an Could you look into these issues
|
@richardschneider I'm trying to figure out why the tests are failing now, but having been able to do so yet. As for the port issue, we were able to determine that it's not related to |
@dryajov cheers! |
The issue seems to be somehow related to the Skipping the version test allows the rest of the tests to pass. |
@diasdavid @victorbjelkholm any idea of what might be causing this - #205 (comment)? |
@diasdavid Thanks for the ipfs v0.28 release. This PR is now ready for review and merge. |
@richardschneider all CI is failing. Errors: Let's be attentive of everyone's time and request a review or a merge only when the code is fully ready. |
This happens on This issue is basically the same thing at a different point - Those initialization changes should address the CI issues here and then I think we've got green-green-green IPFSD CI! 😁 |
Jenkins and Travis are green ✔️ |
@diasdavid Is this now ready for a merge? |
src/factory-in-proc.js
Outdated
const ipfs = new IPFS(options) | ||
ipfs.once('ready', () => { | ||
ipfs.version((err, _version) => { | ||
if (err) { callback(err) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
needs a return. Otherwise chaos will happen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, extremely bad code!!!
src/ipfsd-daemon.js
Outdated
* | ||
* @param {function()} callback - Called when the process was killed. | ||
* @returns {undefined} | ||
*/ | ||
killProcess (callback) { | ||
// need a local var for the closure, as we clear the var. | ||
const self = this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Self is not needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Disagree, it is needed in subprocess.once('exit', ...
this
should not be used in a lambdaexpression! See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still not finished. CI is also not always green.
src/factory-in-proc.js
Outdated
ipfs.version((err, _version) => { | ||
if (err) { return callback(err) } | ||
callback(null, _version) | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this starting the node? I'm sure this is causing repo lock just to check the version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @dryajov, curious about this as there is a TODO to fix this on the go/js factory. Did the mentioned solution hit roadblocks originally? Can we make an issue and work on it separate from this PR?
src/factory-in-proc.js
Outdated
? node.start(options.args, cb) | ||
: cb() | ||
], (err) => callback(err, node)) | ||
node.exec.once('ready', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something isn't quite right here. the node is created but then what we listen on the ready event is exec
??
I'm reworking |
@dryajov Seems that this PR is being re-purposed. Can we get some closure? |
This change is required to get all CIs green. I'm fine with making the change in a different PR but this would depend on it. I'll create a separate PR. |
@dryajov If it's need then please add it here. I'm just concerned that changes are creeping in here that have nothing to do with stopping. |
@dryajov Travis still fails with a bunch of timeouts |
src/factory-in-proc.js
Outdated
node.init((err) => { | ||
if (err) { return callback(err) } | ||
node.version(callback) | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is very odd to me that we start a new instance of IPFS to get the version. This will create a memory leak + it will lock the repo for a consequent node spawn. @dryajov can you expand why to do it this way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@diasdavid I'm not aware of any other way to get the version - is there a better one you can suggest?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
btw, the instance is not started, it is simply initialized with a repo, to start it we would have to call node.start
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dryajov are you saying that a repo is created to just get the version of ipfs? Sound like the node.version should work offline/un'init for the info it can provide, namely, the impl version.
If it was absolutely impossible (which it isn't), at least there should be a cleanup step here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I thought about just using ipfs-repo
directly to read the version, but it turns out we still need to initialize a repo to get the version, since there is no guarantee that the default repo in ~/.jsipfs
corresponds to the version of the IPFS in our exec
param.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it turns out that the version is read by the repo here - https://github.com/ipfs/js-ipfs/blob/494da7f8c5b35f491f22a986ff5e8c456cc0e602/src/core/components/version.js#L14...L24. I think that's an overkill and we should separate the repo version from the ipfs version, that way we don't need a repo. If noone objects I can go ahead and make that change in IPFS
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a need for a Repo version and IPFS version, that is correct. It should be ok to get the IPFS version without the Repo existing though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed - I'm making the change in IPFS to allow for that.
@@ -68,6 +72,8 @@ class Node { | |||
EXPERIMENTAL: this.opts.EXPERIMENTAL, | |||
libp2p: this.opts.libp2p | |||
}) | |||
|
|||
this.exec.once('ready', () => this.emit('ready')) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why use a different pattern than the one used for ipfs-daemon (new Node + node.start)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe not doing that can end up in race conditions - take a look at maybeOpenRepo, its called by the IPFS constructor through boot(self)
, but it is async, and the only way of knowing when it finished is by hooking into the ready
event.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I'm weird'ed out is that in ipfsd-in-proc
, the IPFS instance starts (and therefore does network activity, lock repo, etc) on the constructor, while in ipfsd-daemon
, the daemon only starts when .start is called. This asymmetry will lead to confusion and debugging issues in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, I see - we're not actually starting the node since IPFS is constructed with both, init
and start
as false, take a look here - https://github.com/ipfs/js-ipfsd-ctl/blob/a61fa50d6834e61465398cd1d54e60ec913358eb/src/ipfsd-in-proc.js#L67...L74. This was done specifically to keep that symmetry with the other types of daemons, the ready
event is there to make sure we don't trip over anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. Makes sense then. Thanks for clarifying :)
So the issue ended up being browser only. By default, if the repo doesn't exist, the static repo version is used, but in the browser the error returned was not being matched correctly, hence to version was being returned at all. The fix in ipfs/js-ipfs#1262, should address that. |
Thank you @dryajov :) I'll release a patch version of js-ipfs as soon as I have decent Internet again (npm is not friendly of in-flight wifi) |
Seems that it is all good \o/ Mac OS fails because Jenkins doesn't remember how to install npm anymore //cc @victorbjelkholm |
api/v0/shutdown
to kill a daemon processSee ipfs/js-ipfs#1192 for background details.
Note that this is blocking on ipfs/js-ipfs#1224. When fixed, change the
package.json
to use the latest ipfs.