Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
nodejs
Home
+ new post
About this group
Join this group
Message from discussion Domains and connection pools
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
pie_lard  
View profile  
 More options Nov 14 2012, 3:11 pm
From: pie_lard <pie_l...@yahoo.com>
Date: Wed, 14 Nov 2012 12:11:03 -0800 (PST)
Local: Wed, Nov 14 2012 3:11 pm
Subject: Re: [nodejs] Domains and connection pools
Print | View thread | Show original | Report this message | Find messages by this author

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.

 
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.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google