On Wednesday, 14 November 2012 19:46:28 UTC, Forrest L Norvell wrote: > > On Wednesday, November 14, 2012 at 11:29 AM, pie_lard wrote: > > I think the problem with the examples you've posted there is that you are > creating a domain for every query() call and also having to remember to > wrap the callback in bind() or intercept(). That's too much of a burden > for every call - particularly when the official node docs imply that one > simply has to create a domain during the early stage of an incoming request > and from then on exceptions will be caught properly. > > The danger of using a slide deck as a reference is that the examples are > contrived to give me something simple to live-code to in a presentation. If > you're willing to make liberal use of domain.bind(), there's no reason why > you can't just have one domain for a whole class of requests and add > long-lived connections to the domain directly (although then it becomes > more important to analyze the lifecycle of the domains and ensure that > you're disposing of them properly when they're no longer needed). > > That wouldn't work in the case of pooled connections (or any pooled resources that outlive requests) because you'd just have to add the connection to the domain as soon as you require it (and remove it when you've finished). In which case you'd be better off if domains simply could be installed and then 'followed' every callback from that point onwards. No need for your code to ensure it hasn't switched domains.
> It's worth mentioning that domains are simple objects and are pretty cheap > to create -- mostly just the cost of creating a new EventEmitter and adding > a couple closures to it. Unless your code is super-hot, it shouldn't add > very much overhead to run a specific request in a domain. > Yes - I'm not questioning the performance of domains at all. > I'm not a node expert but I can't help but wonder if domains would be > easier to use if they simply stayed in place across all callbacks and > didn't have this notion of 'owning' EventEmitters. That way all you would > need to do is install a domain and never have to worry about whether your > pooled resources are going to dump you into a different domain at some > point. > > Essentially that's what uncaughtException does; the added value of domains > is that it adds context to errors and lets you perform cleanup and recovery > in a manner similar to what you'd get with exceptions in the synchronous > case. > I agree that domains are needed precisely to maintain the context (eg. I can't send an error to a client if I've lost track of the response object - which I would do with simple uncaughtExceptions). > Maybe this would only work if node were to maintain a stack of domains - > I'm not sure of the implications of that. > > Domains can be nested -- only the current innermost domain will receive > error events. This is handled by a stack internally to the domain code. > You could get multiple listeners on a domain by adding additional > listeners, although you'd have to clean them up at the end of the scope > manually. Probably better just to create a new domain. > Yes - I saw that in the docs. I suppose what I'm asking amounts to: would it matter if domains simply didn't keep track of EventEmitters - what would be the implications? I think that might make nesting simpler (and could possibly happen automatically whereas it doesn't at the moment to prevent resource leaks). > I realise I'm probably missing something important here ;) Either what > I'm suggesting wouldn't work or couldn't be easily implemented. I see > there's another discussion going on on this list about node modules that > seem to be alternatives to domains (or are they built on domains somehow?), > > I'm aware of very few third-party modules taking advantage of domains so > far. If anybody else knows of any, it would be awesome to hear about it. > I assume that any external library built on top of uncaughtExceptions won't be able to track all callbacks without wrapping a lot of the standard library functions or something like that. I mean, domains are the best solution because they are built into node and can thus do things that an external module can't (easily anyway). > > F > Finally - I think perhaps the solution to my problem might be to change my connection pool code so that the create() function creates the resource and then checks whether a domain is installed. If one is installed then it should immediately remove the new resource from the domain. From then on the resource will belong to no domain and any errors will be caught by whatever domain is installed at the time. Again, though, it feels like I'm writing code to make domains behave in a way that would be sensible as a default. -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
