On Wednesday, 14 November 2012 19:46:28 UTC, Forrest L Norvell wrote:That wouldn't work in the case of pooled connections (or any pooled
> 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
> The danger of using a slide deck as a reference is that the examples are
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 cheapYes - I'm not questioning the performance of domains at all.
> 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.
> I'm not a node expert but I can't help but wonder if domains would beI agree that domains are needed precisely to maintain the context (eg. I
> 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
> Essentially that's what uncaughtException does; the added value of domains
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 -Yes - I saw that in the docs. I suppose what I'm asking amounts to: would
> I'm not sure of the implications of that.
> Domains can be nested -- only the current innermost domain will receive
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
> I realise I'm probably missing something important here ;) Either whatI assume that any external library built on top of uncaughtExceptions won't
> 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
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).
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
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.