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

[SEMVER-MAJOR] Replace continuation-local-storage with cls-hooked #11

Merged
merged 1 commit into from
Jan 3, 2017

Conversation

josieusa
Copy link
Collaborator

@josieusa josieusa commented Sep 9, 2016

Hello, this is a quick and (not so) dirty alternative to PR #2.

Rationale:

  • Personally, I still like more the approach I used in PR [WIP] Use cls-hooked instead of continuation-local-storage #2, but I just realized it needs further analysis, because I initially forgot to take into account issue async-listener#57.
  • The quickest and most obvious way to address this is, of course, to get rid of async-listener, which already was the long-term goal of my previous PR, anyway. Here it just turned into an immediate goal, that's all.
  • One trivial way to reach this goal immediately is to completely replace continuation-local-storage with cls-hooked quitting any attempt to keep backward compatibility with the former, which is exactly what I did in this PR and is the difference with my previous PR. This should make the commit df60f13no longer necessary, so I reverted it.
  • cls-hooked, however (maybe continuation-local-storage too, I don't care), needs to be required before everything else, in order to not fail silently and catastrophically. So, I also gave proper and detailed instructions about how to do this in the README.md

Anyway, given the very short time I dedicated to this PR, I would consider this a work-in-progress for now.

TODO:

  • Bump version to 2.0.0-alpha.1 when it's more ready for alpha release.

PS
For now, in order to make tests work, after deleting node_modules folder and running npm i, I had to run (NPM v3):

npm r strong-remoting
npm i [email protected]

I suppose this is because loopback PR #2696 maybe hasn't landed in loopback-context yet.

Also, for the same reason, if you test this branch from inside a Loopback app, make sure that loopback-context uses the same version of strong-remoting as the app.

@slnode
Copy link

slnode commented Sep 9, 2016

Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

@slnode
Copy link

slnode commented Sep 9, 2016

Can one of the admins verify this patch?

@@ -2,3 +2,8 @@
=========================

* First release!

2016-08-10, Version 2.0.0-alpha.1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The contents in CHANGES.md is generated by our release tooling, please revert this change.

@josieusa
Copy link
Collaborator Author

Ok, I addressed all the line notes from the mantainer; but before removing the [WIP] in the title I'd like to try this in production, despite having some successful tests already in place. I'll let you know soon.

@bajtos
Copy link
Member

bajtos commented Sep 14, 2016

Ok, I addressed all the line notes from the mantainer; but before removing the [WIP] in the title I'd like to try this in production, despite having some successful tests already in place. I'll let you know soon.

Sounds good, thank you!

@evseevnn-zz
Copy link

evseevnn-zz commented Oct 7, 2016

How soon this come?
I tested code from josieusa:feature/cls-hooked-3
This not work!
I did it like writen in readme.md

Maybe you can prepare worked example or change readme.md?

UPD. Sorry guys! This work, but problem different, just i use [email protected] module. Explaination here

@bajtos
Copy link
Member

bajtos commented Nov 22, 2016

FWIW, #14 has dropped support for Node v0.10 and Node v0.12. There are no blockers now that would prevent us from landing an implementation based on cls-hooked.

@slnode
Copy link

slnode commented Nov 22, 2016

Can one of the admins verify this patch?

@josieusa
Copy link
Collaborator Author

josieusa commented Dec 9, 2016

@bajtos Sorry for the late response! Luckily, I'm testing this in production right now, and I'll tell you if it works for me ASAP.
I'd only mention that in production I'm using Node 6 and loopback 2, but if it works on 2, I don't see any reason why it shouldn't work on LB 3, since the legacy context feature is deprecated on both versions (anyway, Mocha tests are run on LB 3 since it's a dev dependency).
Just one caveat: if the app uses Node 4, other stuff wouldn't break because of this fix, but if the app uses the current context API, the legacy context feature would be used as a fallback, which is not (and likely will never be) fixed by this PR.
TL;DR whoever wishes to use the working current context feature in this PR, should update to Node 6 before.
Thank you.

@bajtos
Copy link
Member

bajtos commented Dec 9, 2016

TL;DR whoever wishes to use the working current context feature in this PR, should update to Node 6 before.

In that case, let's bump up engines.node field in package.json to >=6 (or whatever minimal Node.js version is required for your new code to work correctly). If the fallback mechanism is never used on Node v6 (and newer), then I am fine with removing this fallback mechanism completely and perhaps throwing an error if the required Node.js API is not available.

@josieusa josieusa force-pushed the feature/cls-hooked-3 branch 2 times, most recently from 6c8a470 to f0bb654 Compare December 9, 2016 15:53
josieusa pushed a commit to josieusa/loopback-context that referenced this pull request Dec 9, 2016
As per suggestion of @bajtos in comment #266030074 in PR strongloop#11
@josieusa
Copy link
Collaborator Author

Hello,
I updated the engines.node field to ^4.5 || ^5.10 || ^6.0 instead of just 6.0 because this is the exact version range required by async-hook dependency of this fork (from its package.json).
My tests in production with Node 6 and Loopback 2 are going fine, and they will end around Tuesday.
After the end of the tests, I would like to use this fork permanently in production.
So, since there are no more line notes left to address, what do you think about a merge when my tests end successfully?
I don't need to add more commits, maybe just some edits to README before Tuesday.
Thank you.

Copy link
Member

@bajtos bajtos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PTAL 👇

npm test
```

This adds the `-r` option to `mocha` command, needed in order to pass tests.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please move the -r option to test/mocha.opts file, so that people can run tests using mocha directly. I personally use this frequently, e.g. to run only a single test via mocha -g "test name".

--require cls-hooked

(BTW you pull request does not change package.json despite what README says.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I see that you already have test/mocha.opts. I think we should simply remove this section from README then.

@@ -1,9 +1,9 @@
{
"name": "loopback-context",
"version": "3.0.0-alpha.1",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't change the version number, we will bump it when releasing a new version.

var asyncFn = function() {
async.waterfall([
fn1,
fn2,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, we usually structure our code differently:

async.waterfall([
  function pushToContext(next) {
    // code from fn1
  },
  function pullFromContext(next) {
    // code from fn2
  },
  function verify(next) {
    expect(testValue).to.equal('test-value');
    next();
  },
], done);

josieusa added a commit to josieusa/loopback-context that referenced this pull request Dec 19, 2016
@bajtos bajtos changed the title [WIP] Completely and permanently replace continuation-local-storage with cls-hooked [SEMVER-MAJOR] Replace continuation-local-storage with cls-hooked Dec 19, 2016
@josieusa
Copy link
Collaborator Author

josieusa commented Dec 20, 2016

Hello,
I confirm it works for me using both usage modes, that is, both node -r cls-hooked . and require('cls-hooked'). Issues like strongloop/loopback#2397, strongloop/loopback#2519, strongloop/loopback#2485 didn't occur to me yet since using this fork (UPDATE: except if using when package, see this issue). Though the LB issue 2485 should be load-tested. Someone did a load test here, resulting in improvements but no solution to the when issue, though he hasn't shared test code yet. Because of this, I'll keep using the fork in production with shrinkwrap, in an average-size app with hundreds of users, regardless of whether it gets merged or not.
Thank you

@bajtos
Copy link
Member

bajtos commented Dec 21, 2016

@josieusa awesome, thank you for the update! I am not sure if I'll have time to review and land this before I leave for vacation.

@dehypnosis
Copy link

dehypnosis commented Dec 27, 2016

lose a lot of time again. sad.
i have no idea that how many people using loopback deals with current context problems..

@josieusa
Copy link
Collaborator Author

josieusa commented Dec 28, 2016

@dehypnosis If you want to use this in your app before it gets merged, you can do like this in package.json if your NPM version is recent enough:

...
"dependencies": {
...
    "loopback-context": "github:josieusa/loopback-context#feature/cls-hooked-3",
...
},
...

If you do this, I strongly recommend to edit package.json again afterwards, as soon as this PR gets merged.
Please remember that this PR is not considered to be the official solution (though it works fine for me).

Rework the module to use the new cls-hooked module (which uses AsyncWrap
available since Node v4.5) instead of old continuation-local-storage
(based on very unreliable async-listener).
Copy link
Member

@bajtos bajtos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The patch looks good to me now. In preparation for landing it, I have cleaned up the commit history and git push -f to your feature branch.

@bajtos bajtos merged commit db9387e into strongloop:master Jan 3, 2017
@bajtos
Copy link
Member

bajtos commented Jan 3, 2017

Landed, thank you for your contribution 🎉 and for keeping the ball rolling despite the long time it took to get this work done 🙇

@michaelfreund
Copy link

@bajtos i think the version number is confusing since 3.0.0 seems to be related to LB3. I guess this is wrong. After some tests it seems that LB2.x projects should also include [email protected] to get this changes.

@bajtos
Copy link
Member

bajtos commented Jan 25, 2017

After some tests it seems that LB2.x projects should also include [email protected] to get this changes.

Yes, you should be able to use [email protected] in LB2.x projects too.

i think the version number is confusing since 3.0.0 seems to be related to LB3. I guess this is wrong.

I am afraid it would be similarly confusing if we used 2.0.0, because it would hint relation to LB2.

We can improve the documentation though to make this more clear. Can you contribute this change yourself please? @michaelfreund

@michaelfreund
Copy link

michaelfreund commented Jan 27, 2017

@bajtos I totally agree with the version number. Of course i can contribute. What do you think of including related component information in the docs? Like for the context stuff

Loopback 3.x
Latest Component Version: 3.0.0
Loopback 2.x
Latest Component Version: 3.0.0
Source
https://github.com/strongloop/loopback-context

BTW http://loopback.io/doc/en/lb3/Using-current-context.html#use-a-custom-strong-remoting-phase seems also working in LB2.x but is missing in the docs. Can you confirm? So i can update that too.

@bajtos
Copy link
Member

bajtos commented Feb 17, 2017

@michaelfreund sorry for responding late.

What do you think of including related component information in the docs? Like for the context stuff

I am proposing to add a new section to loopback-context's README with a table similar to
https://github.com/strongloop/loopback-component-explorer#supported-versions

BTW http://loopback.io/doc/en/lb3/Using-current-context.html#use-a-custom-strong-remoting-phase seems also working in LB2.x but is missing in the docs. Can you confirm? So i can update that too.

Yes, custom remoting phases are available in LB 2.x too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants