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

loopback.getCurrentContext() is null #657

Closed
jmenashe opened this issue Jul 8, 2015 · 16 comments
Closed

loopback.getCurrentContext() is null #657

jmenashe opened this issue Jul 8, 2015 · 16 comments

Comments

@jmenashe
Copy link

jmenashe commented Jul 8, 2015

This may be related to #631. This method returns null intermittently for some remote methods. I am using loopback v2.13.0, loopback-datasource-juggler v2.32.0, and async 1.0.0. Here is an example:

function getData(AccountModel, id, callback) {
  var loopback = require('loopback');
  console.error(loopback.getCurrentContext()); // consistently null
}
  AccountModel.getData = getData.bind(this, AccountModel);
  AccountModel.remoteMethod('getData', {
    description: "Get the " + name + "'s data.",
    accepts: [
      {arg: "id", type: "string", description: "The " + name + "'s id", required: true, http: { source: "path" }},
    ],
    http: {verb: "get", path: "/:id/get_data"},
    returns: {arg: "data", type: "object", root: true}
  });
@jmenashe
Copy link
Author

jmenashe commented Jul 8, 2015

Since this seems to be a recurring issue with loopback, is there some workaround? If I can't have access to the request context then it means I can't use these remote method handlers at all.

@raymondfeng
Copy link
Contributor

See strongloop/loopback#1495 strongloop/loopback#1495

Thanks,


Raymond Feng
Co-Founder and Architect @ StrongLoop, Inc.

StrongLoop http://strongloop.com/ makes it easy to develop APIs http://strongloop.com/mobile-application-development/loopback/ in Node, plus get DevOps capabilities http://strongloop.com/node-js-performance/strongops/ like monitoring, debugging and clustering.

On Jul 8, 2015, at 4:24 AM, Jacob Menashe notifications@github.com wrote:

Since this seems to be a recurring issue with loopback, is there some workaround? If I can't have access to the request context then it means I can't use these remote method handlers at all.


Reply to this email directly or view it on GitHub #657 (comment).

@ryedin
Copy link

ryedin commented Aug 6, 2015

so, something recently changed which broke .getCurrentContext in all remote methods? which is why our code that relies on this in all of our before save hooks now no longer works?

And you don't intend to fix the .getCurrentContext bug, but instead are recommending that we implement this code in strongloop/loopback#1495?

I just want to be clear here. Is that what you are effectively saying by the above post?

EDIT: not trying to sound snarky... just want to understand the best way to fix our app now (wait until you fix the .getCurrentContext bug that has been introduced, or attempt to hack the context in via 1495 above)

@ritch
Copy link
Contributor

ritch commented Aug 6, 2015

Since this seems to be a recurring issue with loopback, is there some workaround?

strongloop/loopback#1495 is my proposal for a work around. The downside is that you must manually pass the options.remoteCtx to wherever it is needed.

so, something recently changed which broke .getCurrentContext

This is certainly concerning. We should fix this. We intend to fix any bug that prevents you to use any aspect of LoopBack. But practically speaking, the getCurrentContext() method relies on an extremely obscure and complicated context propagation. This has burned many people, and also has a potential to limit performance under high concurrency.

Personally I recommend to migrate to the strongloop/loopback#1495 work around. I expect this will eventually land as a first class citizen in strong-remoting and loopback core.

not trying to sound snarky

Trust me I can totally relate. I'm building several applications on LoopBack, and I have the same concern that you do. Personally, I have not made the jump to using getCurrentContext() (even though its something I've wanted for quite a while). So moving forward I'm only going to depend on the manual passing of the options object along with a remoteCtx property (the 1495 approach). To me its worth the added pain so I don't have to worry about modules outside of loopback breaking cls (the complex context propagation I mentioned above).

@ryedin
Copy link

ryedin commented Aug 6, 2015

OK, thank you for the detailed response. I will commence adding the context injection and ripping out our reliance on getCurrentContext().

@wprater
Copy link

wprater commented Feb 25, 2016

how would one get context information in a middleware if we're to remove the use of getCurrentContext? we are having major issues now with the strongloop/loopback#1495 "fix"

@jmenashe
Copy link
Author

The simplest way to access the context is to bypass strongloop's remote method tools and specify handlers with express. From there you can access the context directly and pass it along with all of your function calls. It's an unfortunate solution but at the end of the day I would rather have something gritty and consistent than something nifty that works half the time.

@wprater
Copy link

wprater commented Feb 25, 2016

are you saying to remove the remoteMethod calls to setup the endpoints? Or just to not use the getCurrentContext tools or the strongloop/loopback#1495 workaround, which has terrible performance? it's brought our app to the ground.

@jmenashe
Copy link
Author

The former. Actually in our experience the endpoints created with remoteMethod leaked memory pretty badly. For high-volume endpoints we therefore went with straight express.and passed the context around manually.

@wprater
Copy link

wprater commented Mar 6, 2016

that's sad to hear, I cannot remove our remoteMethod as we're close to shipping and they are the basis of our documentation as well.

I did manage to fix the performance issue with the 1495 hack.

@fabien
Copy link
Contributor

fabien commented Oct 6, 2016

@wprater could you please elaborate on the performance issue and possible fix? I'm about to head for the 1495 hack, but I'd like to know if I'm in for more trouble then.

@wprater
Copy link

wprater commented Oct 6, 2016

@fabien you can see my notes here strongloop/loopback#1495 (comment) for a possible work around to fix these issues. but you might also start to read up on the discussions here too strongloop/loopback-context#2

@fabien
Copy link
Contributor

fabien commented Oct 6, 2016

@wprater which notes? Thanks in advance!

@wprater
Copy link

wprater commented Oct 6, 2016

@wprater which notes? Thanks in advance!

@fabien updated the comment above

@stale
Copy link

stale bot commented Aug 23, 2017

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot closed this as completed Sep 6, 2017
@stale
Copy link

stale bot commented Sep 6, 2017

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.

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

No branches or pull requests

9 participants