The problems from my 1+ year experience with CLS

[iliakan]

I'm writing it as a note to myself and maybe other guys who plan/use CLS (continuation-local-storage).

I met several practical problems with it. But my another issue hangs about half-year+ without an answer (not even sure if it's actual any more, after AL updates), so I'm not asking anything from devs. Anyway I'm not using CLS for anything serious any more.

Just noting the things I met for a year+ of trying to make it work (with occasional success), so that people know the difficulties ahead, cause some of them are rather hidden.

The patching problem:

• There are many modules which do not support CLS. Namely, bluebird, mongoose, a bunch of others. CLS just doesn't work with them or works with serous bugs (ye I know why).
• Most modules can be monkeypatched to support CLS. But that's only possible if the needed functionality is exported, otherwise I need to fork/really patch it.
• In practice the monkeypatch tends to break on new major versions of the modules. Then repatching takes time to dive deep into the updated module once again.

The private versions patching problem:

• Even if I manage to patch something, like bluebird v3, there's a chance that a 3rd-party module in my app uses it's own version of bluebird, say v2, deep inside it's node_modules hierarchy.
• So I must watch not only over modules I need, but also track any module in the node_modules tree of my app, to see if there's a private version of a CLS-unfriendly module, and patch that. Every module/submodule/subsubmodule/... must support CLS or be patched for it.
• That greatly extends the area of maintenance I need to do to keep everything CLS'able. Also gives so much space for bugs in case if something updates and I miss it.

The dangerous bugs problem:

• The bugs introduced by a missed CLS-unfriendly updates of a module or it's submodule may be subtle yet really destructive and hard to fix back. Imagine a payment going to a wrong account. Or a regular user getting an admin view of page with all the secret information.
• That prevents relying on CLS even if though mostly works.

I admire the idea behind the module/async-listener. Async chains in Node.JS are like green threads. A context for an async chain is so cool, it's a must. It's like thread local variables, widely used by so many systems.

Maybe there's something that can be done in the node core to make it work everywhere, make every module CLS'able without critical perf loss?

It would be great to get more attention to the module and its functionality from the minds of the community.

[holm]

All of the above exactly mirrors my experiences from using CLS for about a year. We still use it, as I have not found any other way to have "thread local storage" in Node. I admire CLS for coming up with a solution that mostly works.

Coming to Node with a background in Java, Python and Ruby, the lack of async chains was the biggest surprise. I still wonder how people properly track transactions, authentication and other contextual data through a large system.

[othiym23]

As of Node 6, Trevor Norris's AsyncWrap API is a documented, stable part of the core Node API. It would be excellent to port CLS to take advantage of AsyncWrap when it's available, as I believe that it addresses a number of the points raised above (and Trevor is a much better steward of AsyncWrap than I've been able to be for async-listener, which is after all only my backport of Trevor's previous sketch at this kind of API). It would also be excellent to see CLS extended to directly incorporate all of the known shims for packages like Bluebird that require a little extra help to work with CLS.

If anyone felt like taking on that work, I would be happy to add them to the repo and list of owners on npm, because it's quite clear to me that my other commitments don't afford me the time to take on that work, which is pretty time-consuming and finicky.

[ofrobots]

AsyncWrap is indeed a good alternative to async-listener, but it doesn't provide enough functionality to cover the continuation-local-storage use cases.

OP mentioned 'the patching problem'. I call it the 'user space queuing problem' (more details here). It stems from the fact that any user space code (JS or native) could queue callbacks can resume them in a context different. The status quo here has been to discover such code, and get them monkey patch them to ensure they continue working. This is a never ending battle.

IMO a longer term solution would be to

1. Get the concept of 'async context' into the language and/or host environment.
2. Have the module authors (e.g. bluebird) uphold the contract with the language, by ensuring their modules propagate the async context.

Ideally we want this to work with no monkey patching at all.

Authors of bluebird have indicated that they have little interest in propagating context for continuation-local-storage; they do propagate the current domain, however, since domains are part of core. This is an understandable position, and bluebird is not the only module with this disposition.

In my opinion, to get a solution that is better than 'mostly works', we need:

1. AsyncWrap in node.js.
2. Zones in TC39. This brings in the concept of async context into the language.

[RobinQu]

I think cls should remains as a basic component to deal with async contexts/zones.
Should we propose a new repo to implement APIs compatible to Zone in TC39?
Or a major version bump should happen if we shift to those APIs.

[Qard]

I don't think CLS would ever change its API to match zones. Likely a new polyfill would implement the zones API and people would just start using that.

It's possible CLS might start using a zones polyfill internally though, at some point. Currently it uses an async-listener polyfill, and there's some effort happening to upgrade to an async_wrap polyfill.

[RobinQu]

What's the point of using CLS API if Zone from TC39 has already provided a
similar set of APIs?

On Tue, Aug 23, 2016 at 6:21 AM, Stephen Belanger notifications@github.com
wrote:

I don't think CLS would ever change its API to match zones. Likely a new
polyfill would implement the zones API and people would just start using
that.

It's possible CLS might start using a zones polyfill internally though, at
some point. Currently it uses an async-listener polyfill, and there's some
effort happening to upgrade to an async_wrap polyfill.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#59 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAU6FT80f9AUCg8_YlQTb9DFRp_qLvsiks5qiiDigaJpZM4HZ9ff
.

[Qard]

Zones are lower level. CLS is purely just meant to be a data structure to store data scoped to the execution context, and likely it'd remain as just that.

If someone wants deeper control of how the async contexts are linked, they can reach for whatever Zones API polyfill surfaces.