Your SlideShare is downloading. ×
CLS & asyncListener: asynchronous observability for Node.js
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

CLS & asyncListener: asynchronous observability for Node.js

2,009

Published on

Slides from my presentation at PDXNode in October 2013 before RealtimeConf. Thanks to Tracy Abrahms, Ben Acker, and the rest of the PDXNode community for accommodating and hosting me at the last …

Slides from my presentation at PDXNode in October 2013 before RealtimeConf. Thanks to Tracy Abrahms, Ben Acker, and the rest of the PDXNode community for accommodating and hosting me at the last minute!

Published in: Technology, Design
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,009
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. continuation-local storage https://github.com/othiym23/continuationlocal-storage
  • 2. cls needed a way to pass around per-request state that wouldn’t break (or change) user code stashing state on the side of req and res is yucky thread-local storage is nice but Node is single-threaded and we’re thinking about chains of continuations, so each set of values needs to be tied to a specific request chain
  • 3. a dirt-simple example var  cls  =  require('continuation-­‐local-­‐storage');       function  magic()  {      console.log("value  is  %s",  cls.getNamespace('test').get('value'));   }       var  test  =  cls.createNamespace('test');   test.run(function  ()  {      test.set('value',  'hi  there!');      setImmediate(magic);   });   test.set('value',  'oh  no!');  
  • 4. things to note magic does not have test in scope inside test.run, values have their own scope test’s values persist across the call to setImmediate
  • 5. what’s going on? namespace.run clones the current context the contexts are entered and exited like domains the state is persisted across process.nextTick, timers, and all other core async functions
  • 6. {create,add,remove}AsyncListener https://github.com/joyent/node/pull/6011 https://github.com/othiym23/async-listener
  • 7. THERE’S NO WAY I’M LETTING ANOTHER THING AS SLOW AS DOMAINS IN CORE – TREVNORRIS
  • 8. srs bzns very powerful but low-level API captures every async event in the Node process and makes it observable makes it simple to pass state to callbacks without changing their code also makes it easy to write global error handlers that have some state
  • 9. the API a listener function that is fired for every async event, returns a value that will be passed to the decorators on this async event’s callbacks a bundle of optional before, after, and error callbacks that will be wrapped around functions that this async event is responsible for an optional value that can be passed to before / after / error instead of the results of the listener
  • 10. how it go??! in 0.11.8 and earlier, a JavaScript polyfill that monkeypatches all the things (so, pretty slow) in 0.11.9+, a whole bunch of code in C++ and JavaScript (but still, not a performance king)
  • 11. how it stable? polyfill has pretty good coverage, doesn’t appear to slow apps down too much in practice (just recently solidified enough) polyfill is in use in the New Relic transaction tracer the native version is stable enough that Trevor rewrote domains to use it (and got a nice performance boost when domains aren’t in use)
  • 12. what for? CLS, obviously low-level logging modules pure JS profilers long stacktrace modules making the details of asynchronous execution more observable, basically

×