My first though on reading about Domains was also "yay, I can access
request-specific state (for logging, bail-out on abort, etc.) without
having to pass request objects through every single function in the
codebase (including libraries unrelated to http servers)".
There's definitely a desire to be able to do that, and if there's a feature
that lets you do it, people are going to start using it.
James
On Tuesday, 10 July 2012 23:17:20 UTC+1, Elad Ben-Israel wrote:
>
> Not sure exactly what use case Gaurav is interested in, but I was
> interested in this thread because I think there is an unmet need around
> logging which domain-attached context could help solve (even a single
> pointer to a global instance). Logs are emitted everywhere across
> application (and library) stack and in node, mostly via `console.xxx`. One
> useful feature would be to allow, for example, correlating all console logs
> emitted during the processing of an incoming request. A few logging
> libraries do allow pushing context but they all require passing along some
> state throughout the async hoops, which means modifying the way logging is
> done throughout the entire stack.
>
> I found the ability to push implicit context to logs pretty useful in
> debugging large and chatty systems, and it is used in many environments. In
> yakky synchronous multi threaded environments, it's easy to implement
> nowadays using thread local storage. In the async environment of node I am
> wondering if it requires some additional support.
>
> I think proper support from node to this need would be valuable. Domains
> seemed like a natural approach to me, given their basic attribute is
> passing along implicit context across asynchronous call chains, and I ran
> into `process.domain` following this thread of thought.
>
> Cheers,
> Elad.
>
> On Wed, Jul 11, 2012 at 12:51 AM, Isaac Schlueter <i...@izs.me> wrote:
>
>> Consider this the opposite of a blessing.
>>
>> That is not only an undocumented feature, but an undocumented
>> implementation detail of an experimental feature. You can pretty well
>> be assured it will change in a future release. (Though, not in
>> v0.8.x, which is API and ABI frozen.) The reason that it's not
>> documented is because it's sort of a kludgey way to keep track of the
>> current domain, and we want to leave the option open for more elegant
>> or performant approaches in the future.
>>
>> If you want per-request storage, what's wrong with putting stuff on
>> the request object like everyone else does?
>>
>> Sorry if I'm missing the point of your question here. "Thread-local"
>> only really makes sense in servers that spawn a new thread (or
>> thread-like thing) for each request. Node doesn't do that. It's
>> relevant in those environments because threads can preempt one
>> another, so you have to be careful to use thread-safe data structures
>> or else you'll have problems. Node's JavaScript is single-threaded,
>> and cannot be preempted, so you never have that issue. And child
>> processes don't share memory (mostly) so you don't have corruption
>> issues.
>>
>> So, (a) the thing you're talking about doesn't really exist, because
>> (b) you probably don't actually need it. You've got global (which is
>> per-process), module-local (the var's you define in your module),
>> exports (specific to a module, but visible from the outside), and
>> several objects relating to different conceptual constructs (like the
>> req, the req.socket, the response, child processes, etc.) Your
>> program isn't ever preempted, so "thread local" is not relevant here.
>>
>>
>>
>> On Tue, Jul 10, 2012 at 11:53 AM, Elad Ben-Israel
>> <elad.benisr...@gmail.com> wrote:
>> > Done a little bit of digging and found out the undocumented
>> > `process.domain`, which actually allows one to access the current domain
>> > from anywhere. This is very similar to "thread local storage", but it's
>> way
>> > awesomer because it automatically traverses async calls.
>> >
>> > For example (node 0.8.2):
>> >
>> > ```
>> > var domain = require('domain');
>> > var http = require('http');
>> >
>> > function do_some_async_stuff(callback) {
>> > setTimeout(function() {
>> > console.log('url of current request is', process.domain &&
>> > process.domain.url);
>> > return callback();
>> > }, 500);
>> > }
>> >
>> > var server = http.createServer(function(req, res) {
>> > var d = domain.create();
>> >
>> > // attach `req.url` to the domain as arbitrary context
>> > d.url = req.url;
>> >
>> > d.run(function() {
>> > do_some_async_stuff(function(err) {
>> > res.end('done');
>> > });
>> > });
>> > });
>> >
>> > server.listen(5000);
>> > ```
>> >
>> > This is an undocumented feature so I would advise not to use it before
>> > someone from node core gives their blessing.
>> >
>> > Any thoughts from the core maintainers on this? Why did you guys choose
>> not
>> > to document it? Any caveats that people should be aware of?
>> >
>> > Cheers,
>> > Elad.
>> >
>> > On Wed, Jul 4, 2012 at 7:03 AM, Gaurav Vaish <gaurav.va...@gmail.com>
>> wrote:
>> >>
>> >> Hi Elad,
>> >>
>> >> > As far as I know node does not support something like that. One idea
>> >> > that
>> >> > came to mind is to add support for associating arbitrary context to a
>> >> > domain<http://nodejs.org/docs/latest/api/all.html#all_domain> and
>> >> > extract it along the way.
>> >> >
>> >> > I was thinking on trying to hack something like that. Any thoughts?
>> >>
>> >> Do you already have some thoughts on the same?
>> >>
>> >>
>> >> --
>> >> Happy Hacking,
>> >> Gaurav Vaish
>> >> www.m10v.com
>> >>
>> >
>> >
>> >
>> > --
>> > Elad.
>>
>
>
>
> --
> Elad.
>
