Storing per-domain data

[SLaks]

I'm trying to write a logging system for a complex web application.

I'd like to be able to associate data with an HTTP request (eg, URL, user ID, IP address). I would then include that data with messages logged from components that aren't aware of HTTP at all (eg, data layer), without having to explicitly pass a context object with every function call.

In effect, I'm trying to duplicate Java's MDC.

After looking around on StackOverflow and mailgroups, it looks like I can do this using the undocumented properties process.domain (to get a reference to the current domain) and domain.data (to store arbitrary information).

How likely are these features to change in the future?
(I'm targetting 0.8 right now, but I hope to move to 0.10)

Are there any alternatives?

I'm particularly concerned after reading this post.

[SLaks]

See also #3733, which doesn't seem to have any conclusion

[SLaks]

On a related note, what is the best way to use domains for HTTP servers?

I've found two different variants, and I'm not sure which one is more correct.

https://github.com/isaacs/domain-http-server/blob/master/domain-http-server.js
https://github.com/baryshev/connect-domain/blob/master/lib/connect-domain.js

[bnoordhuis]

How likely are these features to change in the future?

You saw the mailing list post. We won't go out of our way to break your application but we reserve the right to change the current implementation as the need arises.

On a related note, what is the best way to use domains for HTTP servers?

Can you post that question to the mailing list? The issue tracker is not for support or 'how to?' questions.

[othiym23]

For future reference, process.domain === domain.active, and if you want to store arbitrary information on a domain, you should create your own domain for that and then defensively namespace whatever you want to put on the domain. Using a generic name like domain.data is likely to lead to grief at some point. There are some subtleties around dealing with how domains nest and how you can crawl the domain stack, but that's because domains are intended to provide context to I/O errors, and not a generic means of providing context.

There are a number of us who need this more generic context mechanism. @bnoordhuis, I got together with @isaacs this week to discuss what I need in Node for New Relic to be useful. @SLaks, I'm in the process of putting together a strawman API for something that looks an awful lot like MDC. My goal is to create something with generic and simple enough semantics that can be used as a substrate for domains as well as other kinds of (user-created) tooling. Right now the thought is to land something in 0.12, and I may also try to implement a version of it as a module, much as @isaacs did with streams2 (although that's tough to do efficiently, given how the domains code is scattered all over the place).

@SLaks, you'll also want to take a look at the source of src/node.js, src/node.cc and lib/domain.js to double-check that whatever you've built on top of domains in 0.8 doesn't break on the move to 0.10, because the implementation details (if not the intended semantics) changed a bunch between the two major versions. If you're not trying to change how domains handle errors, you should be fine, but there are some subtleties.

Finally, take a look at https://github.com/newrelic/node-newrelic/blob/master/lib/instrumentation/connect.js#L90-L101 for an example / set of warnings for how to deal with domains in connect, which more or less has its own idiomatic error-handling strategy. You have to engage in some shenanigans to keep connect from swallowing errors before they can get emitted on a domain. This may or may not apply to your use case.

[SLaks]

Is domain.active any less likely to change / more documented than process.domain?

I'll certainly take a look at New Relic; what timeframe are you expecting?

[othiym23]

See also #5243.

[othiym23]

@SLaks Domains have gone from experimental to unstable, and my guess / hope would be that the current API would remain stable and get documented, and neither process.domain or domain.active would go away, but @isaacs would have the definitive answer to that question.

As far as New Relic is concerned, there's a beta version of New Relic's Node support available today, and depending on your use case, it may or may not be useful to you, as it's very much a work in progress. Writing a version of New Relic's transaction tracer for Node has proven to be very challenging, for the reasons discussed in this issue and #3733.