[nodejs] Re: Node.js Clustering and interprocess communication

[Murat T.]

Performance wasn't the reason I was looking for an alternative, but 
performance of the alternatives were important. Application has become very 
complex without a proper schema with redis as I had to keep the relation of 
the data within the app. If I could use simple javascript objects, it 
wouldn't solve all the problems I had but it would help a lot.

Then I tried mongodb with mongoose and I managed to remove 300+ lines of 
codes, which is 1/3 of the current application, because of having a proper 
schema and a semi relational data, and I regained my sanity. 

On Friday, March 16, 2012 6:26:43 PM UTC+11, Антон Бравин wrote:
>
> You have a large load on the server? Do not think that the replacement of 
> radis on Mongo may be quite lower power at server side?
>
> пятница, 16 марта 2012 г. 9:31:23 UTC+4 пользователь Murat T. написал:
>>
>> Hi Guys,
>>
>> Those are the exact things I wanted. I have played with clusterhub but in 
>> the end switched to mongo. It reduced the complexity of the application. It 
>> seems Redis wasn't suitable for this job, as I deleted 300+ lines of code 
>> after the switch.
>>
>> Thanks again,
>>
>> On Saturday, March 10, 2012 1:54:44 AM UTC+11, Murat T. wrote:
>>>
>>> Hi,
>>>
>>> I have been developing a game since last month and there are a couple of 
>>> things which bothers me.
>>>
>>> I am using socket.io, and storing all the data into redis. However, 
>>> most of my data is temporary and doesn't need to go into redis. If in case 
>>> I restart the node, those temporary information in redis must be deleted 
>>> anyway. The reason I am storing in redis is that I want to make sure it can 
>>> scale in the future. Current design allows that.
>>>
>>> However, I have been doing some small benchmarks and noticed that I 
>>> won't need to scale node to multiple machines. If I can have 8/16 cores in 
>>> one server, and fork workers using clustering mechanism, everything should 
>>> be more than enough. So, I want to eliminate redis and store everything in 
>>> javascript objects, which is fine for me, since I don't need to save any 
>>> state. (I have somethings to save and will still use redis for those cases, 
>>> but for most cases I don't need it)
>>>
>>> The main reason is that I read and write a lot of small data and I need 
>>> to write lots of code to do that, which I don't need if only I can use 
>>> simple javascript objects.
>>>
>>> If I eliminate redis, I will have some objects which may have more than 
>>> 100.000 elements. I have been testing the performance of interprocess 
>>> communication, and it takes almost a second to send large objects between 
>>> children. (If I am not doing something wrong)
>>>
>>> So, is there any way to simplify the app or improve this performance? Do 
>>> I have to use a key value store for sharing large objects across other 
>>> nodes. I just want to have a couple of objects, read and write a lot of 
>>> data and share between processes.
>>>
>>> Thanks in advance,
>>>
>>>
>>>
>>>
>>>

-- 
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

Re: [nodejs] Re: Eido: Tex+lisp style doumentation language

[Belleve Invis]

I will add its documentation soon.
Then, English is not my native language, so that this progress may be slow.

在 2012年3月13日星期二UTC+8下午1时39分47秒，jesusabdullah写道：
>
> As a latex and lisp fan, this looks sweet! Could use a better readme
> though. You should put what you said in this email into it! :)
>
> --Josh
>
> On Sat, Mar 10, 2012 at 9:36 AM, Belleve Invis  
> wrote:
> > Overall compilation progress:
> >
> > Source doc --parse-> Source Tree (lisp style) -- evaluation -> Generated
> > content
> >
> > And its output actions is controlled by the document itself (fileOut and
> > consoleOut marco).
> >
> > 在 2012年3月11日星期日UTC+8上午1时32分22秒，Belleve Invis写道：
> >>
> >> Hi. I am a node developer from China and I made eido for making 
> douments.
> >>
> >> link: http://github.com/be5invis/eido
> >>
> >> Its kernel is Lisp and its syntax looks like TeX. Its system is entirely
> >> based on marcos --- or "functons". defun is provided. It uses eager
> >> evaluation in most cases with some special auto-quoting rules defined by
> >> functions (for example: quote itself and lambda).
> >>
> >> Its basic syntax is \marco{arg}{arg}{{raw_arg}}{arg} and
> >>
> >> :marco{arg}{arg}
> >> indented block
> >> for last argument.
> >>
> >> {arg} patterns will contain nested expression with {{raw}} does not.
> >>
> >> Currently it is still under development, however, you can see some
> >> examples in my moescript project:
> >> https://github.com/be5invis/moescript/tree/master/src/doc
> >>
> >> The command path/to/eidoc index.ed will generate a HTML page at
> >> ../../doc/index.html .
> >
> > --
> > 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
>
> -- 
> Joshua Holbrook
> Engineer
> Nodejitsu Inc.
> j...@nodejitsu.com
>
>

-- 
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

Re: [nodejs] Nominate me for a NodeConf 2012 Streams talk

[Mikeal Rogers]

I've been doing this for a while and have done events with shorter and longer 
timeslots. I spend most of my year speaking and I've run some pretty well 
received events. 

it's not about one talk, it's about 2 full days. some people can do great 40 
minute talks, most can't, but that is irrelevant when the talks are framed in 
the scope an entire day of curated content with a stated purpose. it means 
there is a larger goal for the day that can't be achieved by just one or two 
talks.

I can remember lots of great talks at 40 minutes, but there was also the rest 
of the day that I forgot about quickly. my goal is to have two great DAYS, not 
a few great talks over two days you mostly forget.

My goal isn't to have a good conference, it's to have the best conference 
anyone has ever attended :) 

-- 
Mikeal Rogers
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Friday, March 16, 2012 at 7:20 PM, Dean Landolt wrote:

> 
> 
> On Fri, Mar 16, 2012 at 9:58 PM, Stewart Mckinney  (mailto:lordma...@gmail.com)> wrote:
> > I'm really not sure about that; I've been to forty minute talks that kept 
> > me rapt from beginning to end.
>  
> Same here. In fact, more often than not -- I've been pretty lucky (and pretty 
> selective) with the conferences I've attended. But I personally haven't seen 
> too much trouble with the 40 minute standard. That said...
>  
> > I feel it would just support weaker subject matter. Granted the reverse 
> > nomination scheme would ease some of that pain but it's really easy for 
> > someone to stand in front of someone else and give a talk that sounds 
> > really exciting at first blush but there's really nothing to it after the 
> > first ten to twenty minutes.
> > 
> 
>  
> Exactly. This format does a wonderful job of keeping that from happening :D
>  
> > I think saying that forty minutes is a "lecture" is pretty unfair and 
> > overbearing. This isn't a two hour and fifty minute "session" class at a 
> > university... and I've even been to talks that were four hours long and 
> > incredibly engaging.
> > 
> 
>  
> Is that the exception or the rule? I'm guessing the former -- let's not get 
> crazy ;)
>  
> > Why not just focus on the content and then let the timing work itself out? 
> > Doesn't a arbitrary limit seem, well... arbitrary? 
> > 
> 
> 
> I tend to agree but I can't see how this could possibly work for scheduling 
> purposes. People need to know what they're getting into -- both speakers and 
> attendees. This isn't a local meetup we're talking about. 
>  
> > Don't you think you will be doing certain subjects/speakers injustice? I 
> > mean, some people just operate in "long form". I don't think there's 
> > anything wrong with short form, either, but to "each
> > subject its own".
> > 
> 
> 
> I agree with this sentiment as well, but as Nuno said, don't sign up to speak 
> if you arent up for it. Same goes for conference goers -- if you don't think 
> the format is for you you should probably stay home. What matters is that the 
> format is communicated clearly, especially if it's a little experimental. 
> It's hard to argue that Mikeal hasn't done that. 
> 
> I'm personally not sure how I feel about the short timeslots either but I'm 
> really curious to see how it turns out. If anything we need more 
> experimentation with conference formats, not less. 
> 
> -- 
> 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

-- 
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

Re: [nodejs] Nominate me for a NodeConf 2012 Streams talk

[Dean Landolt]

On Fri, Mar 16, 2012 at 9:58 PM, Stewart Mckinney wrote:

> I'm really not sure about that; I've been to forty minute talks that kept
> me rapt from beginning to end.


Same here. In fact, more often than not -- I've been pretty lucky (and
pretty selective) with the conferences I've attended. But I personally
haven't seen too much trouble with the 40 minute standard. That said...


> I feel it would just support weaker subject matter. Granted the reverse
> nomination scheme would ease some of that pain but it's really easy for
> someone to stand in front of someone else and give a talk that sounds
> really exciting at first blush but there's really nothing to it after the
> first ten to twenty minutes.
>

Exactly. This format does a wonderful job of keeping that from happening :D


> I think saying that forty minutes is a "lecture" is pretty unfair and
> overbearing. This isn't a two hour and fifty minute "session" class at a
> university... and I've even been to talks that were four hours long and
> incredibly engaging.
>

Is that the exception or the rule? I'm guessing the former -- let's not get
crazy ;)


> Why not just focus on the content and then let the timing work itself out?
> Doesn't a arbitrary limit seem, well... arbitrary?
>

I tend to agree but I can't see how this could possibly work for scheduling
purposes. People need to know what they're getting into -- both speakers
and attendees. This isn't a local meetup we're talking about.


> Don't you think you will be doing certain subjects/speakers injustice? I
> mean, some people just operate in "long form". I don't think there's
> anything wrong with short form, either, but to "each
> subject its own".
>

I agree with this sentiment as well, but as Nuno said, *don't sign up to
speak if you arent up for it*. Same goes for conference goers -- if you
don't think the format is for you you should probably stay home. What
matters is that the format is communicated clearly, *especially* if it's a
little experimental. It's hard to argue that Mikeal hasn't done that.

I'm personally not sure how I feel about the short timeslots either but I'm
really curious to see how it turns out. If anything we need more
experimentation with conference formats, not less.

-- 
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

Re: [nodejs] Nominate me for a NodeConf 2012 Streams talk

[Stewart Mckinney]

I'm really not sure about that; I've been to forty minute talks that kept
me rapt from beginning to end.

I feel it would just support weaker subject matter. Granted the reverse
nomination scheme would ease some of that pain but it's really easy for
someone to stand in front of someone else and give a talk that sounds
really exciting at first blush but there's really nothing to it after the
first ten to twenty minutes.

I think saying that forty minutes is a "lecture" is pretty unfair and
overbearing. This isn't a two hour and fifty minute "session" class at a
university... and I've even been to talks that were four hours long and
incredibly engaging.

Why not just focus on the content and then let the timing work itself out?
Doesn't a arbitrary limit seem, well... arbitrary? Don't you think you will
be doing certain subjects/speakers injustice? I mean, some people just
operate in "long form". I don't think there's anything wrong with short
form, either, but to "each
subject its own".

Just my .02

On Fri, Mar 16, 2012 at 6:25 PM, Nuno Job  wrote:

> The thing is this is not about what you, the speaker, has to talk about
> and things he can show in dept.
> This is about the audience, and they have an attention span of 10/20
> minutes.
>
> This means extra work for you, the speaker, that needs to filter and
> choose what content the audience should head about. But for the audience it
> means that during that time period the usage of their time as optimal, at
> the cost of your work. But hey, don't sign up to speak if you arent up for
> it :)
>
> Personally I like to do talks between 14/20 minutes, but when someone asks
> me for 40 I got like WTF. I'll be bored to death by the end of it I'll be
> asking for beer.
>
> Nuno
>
> On Fri, Mar 16, 2012 at 9:42 PM, Marco Rogers wrote:
>
>> Hmmm, not sure how I feel about this. I won't argue because I'm positive
>> it won't do much good. But do you see as the venue for people who want more
>> in depth talks about node? I think the community needs that as well.
>>
>> Either way, I have some ideas about how to make an awesome 20 minutes
>> about streams.
>>
>> :Marco
>>
>>
>> On Thursday, March 15, 2012 4:35:52 PM UTC-7, Mikeal Rogers wrote:
>>>
>>> yes, it's a talk, not a tutorial.
>>>
>>> btw, TED talks are all between 10 and 20 minutes :)
>>>
>>> On Mar 15, 2012, at March 15, 20124:33 PM, Stewart Mckinney wrote:
>>>
>>> Wait; is that for real? ( 20 minute limit? )
>>>
>>> On Thu, Mar 15, 2012 at 6:53 PM, Mikeal Rogers 
>>> wrote:
>>>
 All talks are 20 minutes this year :)

 On Mar 15, 2012, at March 15, 20123:38 PM, Marco Rogers wrote:

 The call for speakers is open for NodeConf 2012. I want to talk about
 streams in node. Last year I only got a half hour to cover a large topic.
 This may be a simliar situation. But at a high level you an vote for any or
 all of these.

 - What do we mean by streams? require('stream'). How these relate to
 net sockets and fs streams.
 - What are some best practices for working with streams?
 - How to take advantage of custom streams to do cool things in node
 without breaking things or ruining efficiency
 - How to add stream compatibility to your module
 - How to maintain state across streams. When would you even want to do
 this? See 
 https://github.com/**polotek/procstreams

 Feel free to suggest others. Dont forget to fill out the form.

 http://www.nodeconf.com/

 :Marco @polotek

 --
 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+unsubscribe@**googlegroups.com
 For more options, visit this group at
 http://groups.google.com/**group/nodejs?hl=en?hl=en



 --
 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+unsubscribe@**googlegroups.com
 For more options, visit this group at
 http://groups.google.com/**group/nodejs?hl=en?hl=en

>>>
>>>
>>> --
>>> Job Board: http://jobs.nodejs.org/
>>> Posting guidelines: https://github.com/joyent/**node/wiki/Mailing-List-*
>>> *Posting-Guideline

Re: [nodejs] _chmod taking large amounts of execution time

[Ben Noordhuis]

On Sat, Mar 17, 2012 at 02:04, Patrick Quinn  wrote:
> No, it doesn't.  I'm currently trying to find the problem by progressively
> rebuilding the application.  While I do that... is there anything in the
> node.js runtime environment (no libraries) that could cause a program to
> spend 10%-25% of its execution time in _chmod?

Not in node.js itself, the core itself doesn't touch files, it only reads them.

Something you could try is to run your app through dtruss. It's a tool
that logs syscalls, maybe it can tell what's getting chmod'ed.

-- 
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

Re: [nodejs] _chmod taking large amounts of execution time

[Patrick Quinn]

No, it doesn't.  I'm currently trying to find the problem by progressively 
rebuilding the application.  While I do that... is there anything in the 
node.js runtime environment (no libraries) that could cause a program to 
spend 10%-25% of its execution time in _chmod?

On Friday, March 16, 2012 7:26:15 PM UTC-4, Ben Noordhuis wrote:
>
> On Sat, Mar 17, 2012 at 00:13, Patrick Quinn wrote:
> > My full code is about 1000 lines spread over a dozen files.  Is there 
> some
> > subset that would be helpful?
>
> Principle of exclusion: if you strip your program down to the core,
> does it still happen?
>

-- 
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

Re: [nodejs] _chmod taking large amounts of execution time

[Ben Noordhuis]

On Sat, Mar 17, 2012 at 00:13, Patrick Quinn  wrote:
> My full code is about 1000 lines spread over a dozen files.  Is there some
> subset that would be helpful?

Principle of exclusion: if you strip your program down to the core,
does it still happen?

-- 
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

Re: [nodejs] _chmod taking large amounts of execution time

[Patrick Quinn]

My full code is about 1000 lines spread over a dozen files.  Is there some 
subset that would be helpful?

The snippet above is representative of what I'm seeing in the profiler.  I 
can send more snippets if that's useful.  The program doesn't receive any 
user input.  Its only output is a single console.log statement (and 
removing that does nothing for the problem).  It doesn't open files, read 
directories, open sockets, or really do anything fancy whatsoever.  It just 
loops a few thousand times simulating random hands from a card game.  As I 
mentioned, the only external libraries I use are events and underscore.  

On Friday, March 16, 2012 7:00:00 PM UTC-4, Ben Noordhuis wrote:
>
> On Fri, Mar 16, 2012 at 23:36, Patrick Quinn wrote:
> > OSX Lion
>
> Okay, can you post your full code?
>

-- 
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

Re: [nodejs] _chmod taking large amounts of execution time

[Ben Noordhuis]

On Fri, Mar 16, 2012 at 23:36, Patrick Quinn  wrote:
> OSX Lion

Okay, can you post your full code?

-- 
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

[nodejs] Re: cancel fileupload, send error back immediately

[coffeecup]

my node version is 0.6.13 not 6.9.13 :)

-- 
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

Re: [nodejs] _chmod taking large amounts of execution time

[Patrick Quinn]

OSX Lion

On Friday, March 16, 2012 5:42:19 PM UTC-4, Ben Noordhuis wrote:
>
> On Fri, Mar 16, 2012 at 19:57, Patrick Quinn wrote:
> > I've been profiling my code and the most expensive function reported
> > is the C++ function _chmod.  It appears about 4 times as often as my
> > most expensive Javascript function.
> >
> > My program doesn't use the filesystem.  It's very simple.  It prints
> > one line to the console and only has 2 "require" calls that aren't my
> > code: underscore, and EventEmitter2 (require("events") exhibits the
> > same problem).
> >
> > I've done some grepping through node and its dependencies, and I'm
> > scratching my head.  _chmod is apparently called by many functions and
> > I don't see anything in common between them.
> >
> > Is this an internal node.js thing?  Is it anything to be concerned
> > about or is there anything I can do to prevent it?  Any insight would
> > be greatly appreciated.
> >
> > Thanks!
> >
> > Example:
> >
> >4998.8%  _chmod
> > 69   13.8%LazyCompile: *Player.draw /my/project/path/
> > player.js:192
> > 38   55.1%  Function: Player.doCleanup /my/project/path/
> > player.js:119
> > 36   94.7%LazyCompile: *Player.doPlay /my/project/path/
> > player.js:99
> > 36  100.0%  LazyCompile: *Player.onPlayChosen /my/project/
> > path/player.js:168
> > 36  100.0%LazyCompile: *EventEmitter.emit /my/project/
> > path/node_modules/eventemitter2/lib/eventemitter2.js:242
> >
> > Player.draw /my/project/path/player.js:192 is as follows
> >
> >Player.prototype.draw = function(n) {
> >  var card, drawn, _i, _len;
> >  drawn = this.take(n);
> >  for (_i = 0, _len = drawn.length; _i < _len; _i++) {
> >card = drawn[_i];
> >this.hand[card.id] = card;
> >  }
> >  return drawn;
> >};
> >
> > this.take(n) returns an array.  this.hand is an object initialized
> > using curly brackets.  card.id is an integer.
>
> On what platform is this? _chmod looks like a function from the Windows 
> CRT.
>

-- 
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

Re: [nodejs] Nominate me for a NodeConf 2012 Streams talk

[Nuno Job]

The thing is this is not about what you, the speaker, has to talk about and
things he can show in dept.
This is about the audience, and they have an attention span of 10/20
minutes.

This means extra work for you, the speaker, that needs to filter and choose
what content the audience should head about. But for the audience it means
that during that time period the usage of their time as optimal, at the
cost of your work. But hey, don't sign up to speak if you arent up for it :)

Personally I like to do talks between 14/20 minutes, but when someone asks
me for 40 I got like WTF. I'll be bored to death by the end of it I'll be
asking for beer.

Nuno

On Fri, Mar 16, 2012 at 9:42 PM, Marco Rogers wrote:

> Hmmm, not sure how I feel about this. I won't argue because I'm positive
> it won't do much good. But do you see as the venue for people who want more
> in depth talks about node? I think the community needs that as well.
>
> Either way, I have some ideas about how to make an awesome 20 minutes
> about streams.
>
> :Marco
>
>
> On Thursday, March 15, 2012 4:35:52 PM UTC-7, Mikeal Rogers wrote:
>>
>> yes, it's a talk, not a tutorial.
>>
>> btw, TED talks are all between 10 and 20 minutes :)
>>
>> On Mar 15, 2012, at March 15, 20124:33 PM, Stewart Mckinney wrote:
>>
>> Wait; is that for real? ( 20 minute limit? )
>>
>> On Thu, Mar 15, 2012 at 6:53 PM, Mikeal Rogers 
>> wrote:
>>
>>> All talks are 20 minutes this year :)
>>>
>>> On Mar 15, 2012, at March 15, 20123:38 PM, Marco Rogers wrote:
>>>
>>> The call for speakers is open for NodeConf 2012. I want to talk about
>>> streams in node. Last year I only got a half hour to cover a large topic.
>>> This may be a simliar situation. But at a high level you an vote for any or
>>> all of these.
>>>
>>> - What do we mean by streams? require('stream'). How these relate to net
>>> sockets and fs streams.
>>> - What are some best practices for working with streams?
>>> - How to take advantage of custom streams to do cool things in node
>>> without breaking things or ruining efficiency
>>> - How to add stream compatibility to your module
>>> - How to maintain state across streams. When would you even want to do
>>> this? See 
>>> https://github.com/**polotek/procstreams
>>>
>>> Feel free to suggest others. Dont forget to fill out the form.
>>>
>>> http://www.nodeconf.com/
>>>
>>> :Marco @polotek
>>>
>>> --
>>> 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+unsubscribe@**googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/**group/nodejs?hl=en?hl=en
>>>
>>>
>>>
>>> --
>>> 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+unsubscribe@**googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/**group/nodejs?hl=en?hl=en
>>>
>>
>>
>> --
>> 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+unsubscribe@**googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/**group/nodejs?hl=en?hl=en
>>
>>
>>  --
> 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
>

-- 
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 t

Re: [nodejs] Nominate me for a NodeConf 2012 Streams talk

[Mikeal Rogers]

Define "in depth"?

Any talk at a conference will fail to give a thorough understanding of a 
subject no matter the length. Educational research shows that "lecture style" 
education is the worst way to teach anything, people need to hands on 
experience. This is even more true in the technology world because we all learn 
something new every day through reading and experience.

A talk can do a lot, it can excite you about something you didn't know, it can 
explore the third rails of a particular area of technology imparting shared 
experience on the audience. When talks are best they provide something to think 
about and discuss *after* the talk, in the hallways and at the parties after 
speaking.

I think about it this way; even if you can't teach someone something in a talk, 
but you can teach them *why* they would want to learn it. In most cases, the 
shorter the better.

Also, the NodeConf programme is unlike anything you've seen at a conference. 

Maybe I'm too ambitious, but each day of NodeConf will have a theme and the 
speaker content will walk linearly through a beginning, middle and an end. I'm 
using the reverse call for speakers to build that programme and i'll work with 
every speaker individually to make sure the content has a flow throughout the 
entire day. 

So, you, and all the spakers, won't be on the hook for presenting everything 
there is to know about Streams. You'll bite off the chunk that fits you best 
and you'll know where that fits in the larger programme.

Yes, this is very different. No, I don't know that it's been done before, but 
I'm confident I can make it work.

-Mikeal

On Mar 16, 2012, at March 16, 20122:42 PM, Marco Rogers wrote:

> Hmmm, not sure how I feel about this. I won't argue because I'm positive it 
> won't do much good. But do you see as the venue for people who want more in 
> depth talks about node? I think the community needs that as well.
> 
> Either way, I have some ideas about how to make an awesome 20 minutes about 
> streams.
> 
> :Marco
> 
> On Thursday, March 15, 2012 4:35:52 PM UTC-7, Mikeal Rogers wrote:
> yes, it's a talk, not a tutorial.
> 
> btw, TED talks are all between 10 and 20 minutes :)
> 
> On Mar 15, 2012, at March 15, 20124:33 PM, Stewart Mckinney wrote:
> 
>> Wait; is that for real? ( 20 minute limit? )
>> 
>> On Thu, Mar 15, 2012 at 6:53 PM, Mikeal Rogers  
>> wrote:
>> All talks are 20 minutes this year :)
>> 
>> On Mar 15, 2012, at March 15, 20123:38 PM, Marco Rogers wrote:
>> 
>>> The call for speakers is open for NodeConf 2012. I want to talk about 
>>> streams in node. Last year I only got a half hour to cover a large topic. 
>>> This may be a simliar situation. But at a high level you an vote for any or 
>>> all of these.
>>> 
>>> - What do we mean by streams? require('stream'). How these relate to net 
>>> sockets and fs streams.
>>> - What are some best practices for working with streams?
>>> - How to take advantage of custom streams to do cool things in node without 
>>> breaking things or ruining efficiency
>>> - How to add stream compatibility to your module
>>> - How to maintain state across streams. When would you even want to do 
>>> this? See https://github.com/polotek/procstreams
>>> 
>>> Feel free to suggest others. Dont forget to fill out the form.
>>> 
>>> http://www.nodeconf.com/
>>> 
>>> :Marco @polotek
>>> 
>>> -- 
>>> 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
>> 
>> 
>> -- 
>> 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
>> 
>> 
>> -- 
>> 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
> 
> 
> -- 
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: 
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this

Re: [nodejs] best practices for writing cross-platform node applications

[Ted Young]

On Mar 16, 2012, at 3:26 AM, Brandon Benvie wrote:

> Seriously, kind of an itch of mine. Windows understands '/' natively, 
> requiring no translation, The extend of the issue is that Windows roots to a 
> drive or whatever,so /whatever isn't valid but c:/whatever  is.

Just to clarify, you want to use path.resolve() to ensure the drive is included 
in absolute paths, but otherwise there's no path nonsense anyone needs to worry 
about?

Ted

> 
> -- 
> 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

-- 
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

Re: [nodejs] Nominate me for a NodeConf 2012 Streams talk

[Mark Hahn]

>  stoner

Did you hear they are going to make prostitution and pot illegal for
tourists?

On Fri, Mar 16, 2012 at 2:37 PM, Mikeal Rogers wrote:

> stoner :P
>
> On Mar 16, 2012, at March 16, 20121:26 PM, Michael Nisi wrote:
>
> > Amsterdam comes to mind.
> >
> > On Fri, Mar 16, 2012 at 7:42 PM, Mikeal Rogers 
> wrote:
> >> There is a lot of thought that we put in to city selection, everyone
> says "have it in my city" so I'm going to ignore this entire thread.
> >>
> >> -Mikeal
> >>
> >> --
> >> 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
> >
> > --
> > 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
>
> --
> 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
>

-- 
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

Re: [nodejs] Nominate me for a NodeConf 2012 Streams talk

[Marco Rogers]

Hmmm, not sure how I feel about this. I won't argue because I'm positive it 
won't do much good. But do you see as the venue for people who want more in 
depth talks about node? I think the community needs that as well.

Either way, I have some ideas about how to make an awesome 20 minutes about 
streams.

:Marco

On Thursday, March 15, 2012 4:35:52 PM UTC-7, Mikeal Rogers wrote:
>
> yes, it's a talk, not a tutorial.
>
> btw, TED talks are all between 10 and 20 minutes :)
>
> On Mar 15, 2012, at March 15, 20124:33 PM, Stewart Mckinney wrote:
>
> Wait; is that for real? ( 20 minute limit? )
>
> On Thu, Mar 15, 2012 at 6:53 PM, Mikeal Rogers wrote:
>
>> All talks are 20 minutes this year :)
>>
>> On Mar 15, 2012, at March 15, 20123:38 PM, Marco Rogers wrote:
>>
>> The call for speakers is open for NodeConf 2012. I want to talk about 
>> streams in node. Last year I only got a half hour to cover a large topic. 
>> This may be a simliar situation. But at a high level you an vote for any or 
>> all of these.
>>
>> - What do we mean by streams? require('stream'). How these relate to net 
>> sockets and fs streams.
>> - What are some best practices for working with streams?
>> - How to take advantage of custom streams to do cool things in node 
>> without breaking things or ruining efficiency
>> - How to add stream compatibility to your module
>> - How to maintain state across streams. When would you even want to do 
>> this? See https://github.com/polotek/procstreams
>>
>> Feel free to suggest others. Dont forget to fill out the form.
>>
>> http://www.nodeconf.com/
>>
>> :Marco @polotek
>>
>> -- 
>> 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
>>
>>
>>
>> -- 
>> 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
>>
>
>
> -- 
> 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
>
>
>

-- 
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

Re: [nodejs] _chmod taking large amounts of execution time

[Ben Noordhuis]

On Fri, Mar 16, 2012 at 19:57, Patrick Quinn  wrote:
> I've been profiling my code and the most expensive function reported
> is the C++ function _chmod.  It appears about 4 times as often as my
> most expensive Javascript function.
>
> My program doesn't use the filesystem.  It's very simple.  It prints
> one line to the console and only has 2 "require" calls that aren't my
> code: underscore, and EventEmitter2 (require("events") exhibits the
> same problem).
>
> I've done some grepping through node and its dependencies, and I'm
> scratching my head.  _chmod is apparently called by many functions and
> I don't see anything in common between them.
>
> Is this an internal node.js thing?  Is it anything to be concerned
> about or is there anything I can do to prevent it?  Any insight would
> be greatly appreciated.
>
> Thanks!
>
> Example:
>
>    499    8.8%  _chmod
>     69   13.8%    LazyCompile: *Player.draw /my/project/path/
> player.js:192
>     38   55.1%      Function: Player.doCleanup /my/project/path/
> player.js:119
>     36   94.7%        LazyCompile: *Player.doPlay /my/project/path/
> player.js:99
>     36  100.0%          LazyCompile: *Player.onPlayChosen /my/project/
> path/player.js:168
>     36  100.0%            LazyCompile: *EventEmitter.emit /my/project/
> path/node_modules/eventemitter2/lib/eventemitter2.js:242
>
> Player.draw /my/project/path/player.js:192 is as follows
>
>    Player.prototype.draw = function(n) {
>      var card, drawn, _i, _len;
>      drawn = this.take(n);
>      for (_i = 0, _len = drawn.length; _i < _len; _i++) {
>        card = drawn[_i];
>        this.hand[card.id] = card;
>      }
>      return drawn;
>    };
>
> this.take(n) returns an array.  this.hand is an object initialized
> using curly brackets.  card.id is an integer.

On what platform is this? _chmod looks like a function from the Windows CRT.

-- 
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

Re: [nodejs] Nominate me for a NodeConf 2012 Streams talk

[Mikeal Rogers]

stoner :P

On Mar 16, 2012, at March 16, 20121:26 PM, Michael Nisi wrote:

> Amsterdam comes to mind.
> 
> On Fri, Mar 16, 2012 at 7:42 PM, Mikeal Rogers  
> wrote:
>> There is a lot of thought that we put in to city selection, everyone says 
>> "have it in my city" so I'm going to ignore this entire thread.
>> 
>> -Mikeal
>> 
>> --
>> 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
> 
> -- 
> 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

-- 
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

Re: [nodejs] Nominate me for a NodeConf 2012 Streams talk

[Michael Nisi]

Amsterdam comes to mind.

On Fri, Mar 16, 2012 at 7:42 PM, Mikeal Rogers  wrote:
> There is a lot of thought that we put in to city selection, everyone says 
> "have it in my city" so I'm going to ignore this entire thread.
>
> -Mikeal
>
> --
> 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

-- 
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

[nodejs] cancel fileupload, send error back immediately

[coffeecup]

hello, i'm using node v 6.9.13 
this is bugging me for a while now, how can i cancel a ongoing fileupload 
and send the error back immediately? 
for example if the file is too large i don't want the user to wait until he 
has finaly uploaded his file to get a proper error message.

i tried req.client.destroy() but haven't had any success passing a message 
back, status in chrome says only "failed".





-- 
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

[nodejs] Re: How to properly cancel a file uploading request?

[Sandro Pasquali]

This should actually terminate the connection:

request.abort();

I've also experimented with:

request.connection.destroy();

On Tuesday, February 7, 2012 12:11:43 AM UTC-5, Mophy Xiong wrote:
>
> Hi AJ, 
>
> It seems req.pause() is a right way to do this. The reason it didn't 
> work well for our situation is a bug in node v0.6.x, according to this 
> post: http://groups.google.com/group/nodejs/t/a7386d38ee9e3d9d 
>
> Thank you. 
>
> Regards, 
> Mophy 
>
> On Feb 7, 10:54 am, Mophy Xiong  wrote: 
> > Hi AJ, 
> > 
> > Thank you for your reply. But it seems that doesn't stop the uploading 
> > at all. The server continues getting the formidable progress event, 
> > and the browser is still uploading, and the 'upload limit exceeded' 
> > message is shown after the file is completely uploaded. 
> > 
> > Regards, 
> > Mophy 
> > 
> > On Feb 7, 1:52 am, AJ ONeal  wrote: 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > > How about 
> > 
> > > req.pause() 
> > > res.status = 400; 
> > > res.end('upload limit exceeded'); 
> > 
> > > That will stop the data from coming in and the client may stay 
> connected 
> > > despite your response, but should eventually timeout in a harmless 
> fashion. 
> > 
> > > AJ ONeal 
> > 
> > > On Mon, Feb 6, 2012 at 8:03 AM, Mophy Xiong  
> wrote: 
> > > > Update: 
> > 
> > > > After changing the following line: 
> > 
> > > >if (err.code === 'ECONNRESET'){ 
> > 
> > > > to: 
> > 
> > > >if (err.code === 'ECONNRESET' || err.code === 'EPIPE'){ 
> > 
> > > > We do can always cancel the request now. But we don't know if this 
> > > > will cause any potential problems, like file/device handle/id 
> problem 
> > > > or any other OS level problems. So, if you can figure it out, please 
> > > > let us know. 
> > 
> > > > In another hand, we found after we canceled the uploading request, 
> > > > there will be 1 or 2 or 3 segment files lay in the uploading 
> > > > directory. And this is not from the reverse proxy, 'cause they will 
> > > > show up even if we access the upload handler directly. For example, 
> > > > after we canceled the uploading abc.7z (of 10M size), there will be 
> > > > _random_name_a.7z, _random_name_b.7z in the uploading directory 
> (yes, 
> > > > we did emptied this directory before uploading). Each segment file 
> may 
> > > > be 32K or 64K size. Dose this means we didn't cancel the request 
> > > > gracefully or something else? 
> > 
> > > > Thanks in advance. 
> > 
> > > > Regards, 
> > > > Mophy 
> > 
> > > > On Feb 6, 1:16 pm, Mophy Xiong  wrote: 
> > > > > Hi all, 
> > 
> > > > > We are writing a file uploading handler, by using formidable. 
> Since 
> > > > > the file could be large, say 50M, we want to cancel the uploading 
> > > > > request if some necessary fields are missing or user quota 
> exceeded, 
> > > > > so user do not need to wait until the file is completely uploaded 
> to 
> > > > > see the response, and save our server from processing the 
> unnecessary 
> > > > > uploading request. 
> > 
> > > > > It works just fine. By using req.client.destroy() or 
> > > > > res.connection.destroy(), the browser stops uploading immediately. 
> > 
> > > > > Until we put it behind a reverse proxy nginx. The nginx server 
> will 
> > > > > firstly buffer the whole uploading body before it passes the 
> control 
> > > > > to our uploading handler, so we don't have a chance to cancel the 
> > > > > uploading before it is completely uploaded. 
> > 
> > > > > Then we use node-http-proxy to replace the nginx server, which 
> will 
> > > > > not buffer the request automatically. 
> > 
> > > > > But after we cancel the request in the uploading handler, the 
> reverse 
> > > > > proxy node-http-proxy server will not do the same to the actual 
> > > > > client, which means the browser is still busy uploading. Then we 
> add a 
> > > > > proxyError listener to the proxy, like this: 
> > 
> > > > > server.proxy.on('proxyError', function(err, req, res){ 
> > > > > console.log('proxyError:'); 
> > > > > console.dir(err); 
> > > > > if (err.code === 'ECONNRESET'){ 
> > > > > res.connection.destroy(); 
> > > > > } 
> > 
> > > > > }); 
> > 
> > > > > Sometimes, this will success, if the err is { [Error: socket hang 
> up] 
> > > > > code: 'ECONNRESET' }, the connection is successfully reset, and 
> the 
> > > > > browser stops uploading right away. But sometime not, if the err 
> is 
> > > > > { [Error: write ECONNRESET] code: 'ECONNRESET', errno: 
> 'ECONNRESET', 
> > > > > syscall: 'write' }, the res.connection.destroy() will just issue 
> > > > > another proxyError: { [Error: write EPIPE] code: 'EPIPE', errno: 
> > > > > 'EPIPE', syscall: 'write' }, and the browser continues it's 
> uploading 
> > > > > request. 
> > 
> > > > > Are we doing something wrong here? 
> > 
> > > > > Any suggestion is appreciated, thanks in advance. 
> > 
> > > > > Regards, 
> > > > > Mophy 
> > 
> > > > -- 
> > > > Job Board:http://jobs.nodejs.org/ 
> > > > Po

[nodejs] _chmod taking large amounts of execution time

[Patrick Quinn]

I've been profiling my code and the most expensive function reported
is the C++ function _chmod.  It appears about 4 times as often as my
most expensive Javascript function.

My program doesn't use the filesystem.  It's very simple.  It prints
one line to the console and only has 2 "require" calls that aren't my
code: underscore, and EventEmitter2 (require("events") exhibits the
same problem).

I've done some grepping through node and its dependencies, and I'm
scratching my head.  _chmod is apparently called by many functions and
I don't see anything in common between them.

Is this an internal node.js thing?  Is it anything to be concerned
about or is there anything I can do to prevent it?  Any insight would
be greatly appreciated.

Thanks!

Example:

4998.8%  _chmod
 69   13.8%LazyCompile: *Player.draw /my/project/path/
player.js:192
 38   55.1%  Function: Player.doCleanup /my/project/path/
player.js:119
 36   94.7%LazyCompile: *Player.doPlay /my/project/path/
player.js:99
 36  100.0%  LazyCompile: *Player.onPlayChosen /my/project/
path/player.js:168
 36  100.0%LazyCompile: *EventEmitter.emit /my/project/
path/node_modules/eventemitter2/lib/eventemitter2.js:242

Player.draw /my/project/path/player.js:192 is as follows

Player.prototype.draw = function(n) {
  var card, drawn, _i, _len;
  drawn = this.take(n);
  for (_i = 0, _len = drawn.length; _i < _len; _i++) {
card = drawn[_i];
this.hand[card.id] = card;
  }
  return drawn;
};

this.take(n) returns an array.  this.hand is an object initialized
using curly brackets.  card.id is an integer.

-- 
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

[nodejs] Re: Finding native memory leaks in node

[mscdex]

On Mar 16, 4:46 pm, Jimb Esser  wrote:
> The server in question is not an http server, but a back-end
> simulation server running physics simulation for an online game using
> a Bullet native library.  Yeah, I know, not exactly a typical (or
> perhaps wise...) use of node.js.  We're 95% certain the Bullet module
> is the culprit, but that is hundreds of thousands of lines of 3rd
> party C++ code, not something feasible to poke in, and, like most
> physics simulations, not particularly deterministic when combined with
> the randomness of network latency and real user actions.  Stand alone
> stress tests we've tried never exhibit the problem, and since it takes
> a fully loaded server a day to exhibit it, it's not likely to
> reproduce in a development environment.  That being said, it
> consistently does reproduce on the production servers, so that is,
> theoretically, an easy way to debug it with post-mortem debugging
> (albeit with a day-long turn-around to test fixes).  Heap dumps are a
> much more reliable way of tracking down heap issues in a large system
> than any "poke at different parts of the system at random" method, I
> was just hoping there was an easy way to get them reliably...

FWIW I wonder if either of these javascript bullet ports are worth
trying/looking into?: https://github.com/adambom/bullet.js/ and
https://github.com/kripken/ammo.js/

-- 
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

[nodejs] Re: Finding native memory leaks in node

[Jimb Esser]

The server in question is not an http server, but a back-end
simulation server running physics simulation for an online game using
a Bullet native library.  Yeah, I know, not exactly a typical (or
perhaps wise...) use of node.js.  We're 95% certain the Bullet module
is the culprit, but that is hundreds of thousands of lines of 3rd
party C++ code, not something feasible to poke in, and, like most
physics simulations, not particularly deterministic when combined with
the randomness of network latency and real user actions.  Stand alone
stress tests we've tried never exhibit the problem, and since it takes
a fully loaded server a day to exhibit it, it's not likely to
reproduce in a development environment.  That being said, it
consistently does reproduce on the production servers, so that is,
theoretically, an easy way to debug it with post-mortem debugging
(albeit with a day-long turn-around to test fixes).  Heap dumps are a
much more reliable way of tracking down heap issues in a large system
than any "poke at different parts of the system at random" method, I
was just hoping there was an easy way to get them reliably...

I'll try poking around in a gdb dump, although I'm guessing the
default heap isn't going to have any allocation site information on
the heap entries, but it might show some useful information, at least
it should allow me to quickly sample the heap to determine what the
primary content type is (strings, floats, ints, etc) is that's
leaking, which may provide some insight.

On Mar 16, 8:34 am, George Stagas  wrote:
> You can pinpoint the leak by writing stress tests. Don't wait days for
> the leak to show in production. Find which component causes it. Make a
> list of suspects. If it's an http server, start with simple requests.
> Does the memory go up? No? Maybe it's the db? Try a million
> read/writes. Did you find the component that leaks? Follow the chain
> of events, commenting out suspicious code and trying again until the
> leak disappears.
>
> 2012/3/16 robot1125 :
>
>
>
>
>
>
>
> >> So, my general question, how do people go about debugging memory leaks
> >> in native code in node (or node itself)?
>
> > You may find this interview with Brian Cantrill of Joyent interesting.
>
> >http://www.infoq.com/interviews/operating-nodejs-production-bryan-can...
>
> > He discusses some of the tools they use to debug node apps in
> > production at Joyent.  Some of them require running under their
> > homebrew OS, but the discussion may give you some ideas.
>
> > --
> > 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

-- 
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

Re: [nodejs] Nominate me for a NodeConf 2012 Streams talk

[Isaac Schlueter]

Mikeal: I'm sure you can agree that the fact that NodeConf isn't in
Oakland is pretty tragic.


On Fri, Mar 16, 2012 at 11:42, Mikeal Rogers  wrote:
> There is a lot of thought that we put in to city selection, everyone says 
> "have it in my city" so I'm going to ignore this entire thread.
>
> -Mikeal
>
> --
> 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

-- 
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

Re: [nodejs] Nominate me for a NodeConf 2012 Streams talk

[Mikeal Rogers]

There is a lot of thought that we put in to city selection, everyone says "have 
it in my city" so I'm going to ignore this entire thread.

-Mikeal

-- 
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

[nodejs] Re: BayNode Meetup next Thursday: Engine.IO (Socket.IO Next) and LocalNode

[Bry]

Did you guys ever get the chance to upload the talk about engine.io on 
youtube or vimeo? Thanks.

On Friday, January 13, 2012 3:06:35 PM UTC-5, Adam Crabtree wrote:
>
> Since the groups still new, and this is only our second meetup, with our 
> first being close to 4 months ago... In case anyone's interested:
>
> http://www.meetup.com/BayNode/events/47701272/
>
> We got a surprise for you this month! Guillermo Rauch of LearnBoost will 
> be presenting on the next generation of Socket.IO that he's been working on 
> and David Gouldin of Votizen will be talking about his experience as a 
> member of the "Return of the Starcraft" 2011 Node Knockout team and our 
> entry LocalNode which was runner-up in the Utility category! As always 
> there will be delicious food, hand-selected beers and tasty iced teas and 
> sodas.
>
>
> LocalNode  by David 
> Gouldin
>
> Winner of "The Unauthorized Node Knockout 2 
> Awards"
>  
> (;P) as judged by Eran Hammer of OAuth fame, LocalNode was an install-free, 
> configuration-free web proxy to share any site on your LAN. David Gouldin 
> will discuss what it was like participating in Node 
> Knockout 2011, 
> and the issues we faced building a web proxy in node and the browser using 
> XHR2 , 
> WebSockets
>  and Socket.io.
>
>  
>
> Engine.IO by Guillermo Rauch
>
> The next generation of Socket.IO core, Engine.IO is the future of 
> Socket.IO's realtime communication. Guillermo Rauch is the father of 
> realtime communication in node and arguably shares some of the credit for 
> node's success with his amazing work.
>
>  
>
> David Gouldin
>
> @dgouldin 
>
> https://github.com/dgouldin
>
> https://www.votizen.com/
>
>  
>
> Guillermo Rauch
>
> @rauchg 
>
> http://www.devthought.com/
>
> https://github.com/guille
>
> https://www.learnboost.com/
>
>
> Cheers,
> Adam Crabtree
>
> --
> Better a little with righteousness
>than much gain with injustice.
> Proverbs 16:8 

-- 
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

Re: [nodejs] Nominate me for a NodeConf 2012 Streams talk

[Marcin Zawadzki]

Yes, I can help to manage organizing nodeconf in Berlin.

W dniu piątek, 16 marca 2012, 10:48:22 UTC+1 użytkownik theCole napisał:
>
> mikeal -- bring nodeconf to berlin!
>
>

-- 
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

[nodejs] Re: Node.js Clustering and interprocess communication

[Marcin Zawadzki]

But you have to be carefull when using 
socket.io-clusterhub. 
There could be a race condition as in normal c++ multithreaded environment. 
When you set/change the variable in first thread, and then the second 
request goes to the second thread, then in this second thread you can have 
the old value in this variable, because maybe the event was not already 
handled (maybe second request was too fast :) )

W dniu poniedziałek, 12 marca 2012, 18:48:04 UTC+1 użytkownik Evan napisał:
>
> This is a very similar problem to what I've been fighting as well (also 
> for a game).  
> Personally, I didn't feel any of the packages I had found met my needs, so 
> I created this: http://actionherojs.com/. 
>
> I'm working on support for both pure-node distributed data and for a 
> common task queue.  It's still pre V1, but I am always happy to have 
> feedback.
>
> On Friday, March 9, 2012 8:54:44 AM UTC-6, Murat T. wrote:
>>
>> Hi,
>>
>> I have been developing a game since last month and there are a couple of 
>> things which bothers me.
>>
>> I am using socket.io, and storing all the data into redis. However, most 
>> of my data is temporary and doesn't need to go into redis. If in case I 
>> restart the node, those temporary information in redis must be deleted 
>> anyway. The reason I am storing in redis is that I want to make sure it can 
>> scale in the future. Current design allows that.
>>
>> However, I have been doing some small benchmarks and noticed that I won't 
>> need to scale node to multiple machines. If I can have 8/16 cores in one 
>> server, and fork workers using clustering mechanism, everything should be 
>> more than enough. So, I want to eliminate redis and store everything in 
>> javascript objects, which is fine for me, since I don't need to save any 
>> state. (I have somethings to save and will still use redis for those cases, 
>> but for most cases I don't need it)
>>
>> The main reason is that I read and write a lot of small data and I need 
>> to write lots of code to do that, which I don't need if only I can use 
>> simple javascript objects.
>>
>> If I eliminate redis, I will have some objects which may have more than 
>> 100.000 elements. I have been testing the performance of interprocess 
>> communication, and it takes almost a second to send large objects between 
>> children. (If I am not doing something wrong)
>>
>> So, is there any way to simplify the app or improve this performance? Do 
>> I have to use a key value store for sharing large objects across other 
>> nodes. I just want to have a couple of objects, read and write a lot of 
>> data and share between processes.
>>
>> Thanks in advance,
>>
>>
>>
>>
>>

-- 
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

Re: [nodejs] nodejs 0.4.9 and mongoose 2.5.9 hangs on SSD

[Mark Hahn]

Your problem has to be a bad ssd.  The fact that different code triggers
the problem is not surprising.

-- 
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

Re: [nodejs] Re: Recommendation for test framework for objects which util.inherits EventEmitter.

[Nuno Job]

Shameless promotion of my own projects: Feel free to try dscape/specify,
would be great to get some feedback. If it's an event emitter or something
else should make no difference.

Nuno

On Fri, Mar 16, 2012 at 4:37 PM, Douglas Martin wrote:

> l allow for the serial execution of async tests.

-- 
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

[nodejs] Re: Recommendation for test framework for objects which util.inherits EventEmitter.

[Douglas Martin]

Try it  (https://github.com/doug-martin/it), 
it will allow for the serial execution of async tests.

On Friday, March 16, 2012 6:29:47 AM UTC-5, Chris Dew wrote:
>
> I really like Mocha, but I have a problem ordering the execution of async 
> tests:
>
>
> http://stackoverflow.com/questions/9736429/how-can-i-execute-async-mocha-tests-nodejs-in-order
>  
>
> Thanks,
>
> Chris.
>
> On Friday, 16 March 2012 09:02:20 UTC, Chris Dew wrote:
>>
>> Thanks, I'll have a look at Mocha.
>>
>> On Thursday, 15 March 2012 21:40:19 UTC, Chad Retz wrote:
>>>
>>> What I do in Mocha is simply take the done callback and call it with 
>>> success once I hit the event and either have a timeout otherwise or call 
>>> the done callback with an error on an "end" if I know the proper event 
>>> wasn't emitted.
>>>
>>> On Thursday, March 15, 2012 12:26:43 PM UTC-5, Chris Dew wrote:

 I'm currently using Vows, but finding it difficult to write tests to 
 respond to the firing of events from objects which util.inherits 
 EventEmitter.

 Has anyone had success testing EventEmitters in other frameworks?

 Thanks,

 Chris.

>>>

-- 
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

Re: [nodejs] fs.watch and fs.watchFile

[C. Mundi]

On Fri, Mar 16, 2012 at 8:53 AM, Dan North  wrote:

> When you watch a file you're actually watching an inode (a magic number
> that represents the file). If that file gets deleted and another one with
> the same name gets created, it's not the same file (it will have a
> different inode). Likewise if you replace a file with mv(1).
>
> This is the difference between tail -f and tail -F for example: the latter
> watches to see if the file is replaced by another. If gedit is saving the
> current buffer into a temporary file then moving it over the new one (a
> common approach because moving a file is atomic) you will no longer see
> watch events on the new file.
>
> You can add another watch to the directory containing the file, then
> you'll see the create, remove, rename, etc. events in that and you should
> be able to spot what's going on and create a new watch for the new file
> (and close the old one of course).
>
>
Hi Dan. You're right.  Watchign teh directory allows me to see all of the
machinations of gedit, like this sequence from a single "Save" action:

 event is: rename
filename provided: .goutputstream-QDILBW
event is: change
filename provided: .goutputstream-QDILBW
event is: change
filename provided: .goutputstream-QDILBW
event is: rename
filename provided: test.txt~
event is: rename
filename provided: test.txt~
event is: rename
filename provided: .goutputstream-QDILBW
event is: rename
filename provided: test.txt

and I can do that all day and my node.js watcher script never gets tired.
Of course we know that copies and deletes are both flagged as rename
events.  So I guess we see why it is safer to watch the enclosing directory
and then ask questions about the files.  I'm still not completely
comfortable, but I think I can stay safe.

Thanks!

-- 
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

Re: [nodejs] fs.watch and fs.watchFile

[C. Mundi]

Yep.  I get that.  And that's why an editor might mess things up.  But see
also my post a moment ago in which I use the 'mv' command.  I'm going to do
an example like you suggest watching the immediately enclosing directory
inode.


On Fri, Mar 16, 2012 at 8:53 AM, Dan North  wrote:

> When you watch a file you're actually watching an inode (a magic number
> that represents the file). If that file gets deleted and another one with
> the same name gets created, it's not the same file (it will have a
> different inode). Likewise if you replace a file with mv(1).
>
> This is the difference between tail -f and tail -F for example: the latter
> watches to see if the file is replaced by another. If gedit is saving the
> current buffer into a temporary file then moving it over the new one (a
> common approach because moving a file is atomic) you will no longer see
> watch events on the new file.
>
> You can add another watch to the directory containing the file, then
> you'll see the create, remove, rename, etc. events in that and you should
> be able to spot what's going on and create a new watch for the new file
> (and close the old one of course).
>
>
> On 16 March 2012 15:44, C. Mundi  wrote:
>
>>
>>
>> On Fri, Mar 16, 2012 at 7:33 AM, Ben Noordhuis wrote:
>>
>>> On Fri, Mar 16, 2012 at 06:34, C. Mundi  wrote:
>>> > I am aware that there are platform-specific issues with watching
>>> files.  But
>>> > I am getting strange-bad results just on Linux.  Please tell me I am
>>> doing
>>> > something silly below.
>>> >
>>> > var fs = require('fs');
>>> >
>>> > function act(curr, prev) {
>>> >   console.log('the current mtime is: ' + curr.mtime);
>>> >   console.log('the previous mtime was: ' + prev.mtime);
>>> > };
>>> >
>>> > function act2(event,file) {
>>> >   console.log('event is: ' + event);
>>> >   if (file) {
>>> > console.log('filename provided: ' + file);
>>> >   } else {
>>> > console.log('filename not provided');
>>> >   }
>>> > };
>>> >
>>> > // ucomment one or the other (but not both!) of the following lines:
>>> > // fs.watchFile('test.txt', act);
>>> > // fs.watch('test.txt', act2);
>>> >
>>> > When I use fs.watch + act2, and simply repeatedly 'touch' the file
>>> (about
>>> > once per second) the first two events are 'change' and the next three
>>> are
>>> > 'rename' (!) and then program just stops producing output.  It's as if
>>> the
>>> > events are eitehr never fired or never handled.  I understand that
>>> this is
>>> > based (on Linux) on inotify?
>>> >
>>> > So I switch to fs.watchFile + act.  Again, I 'touch' the test file
>>> about
>>> > once per second.  This always produces an event.  The problem is,
>>> about 30%
>>> > of the time one touch produces two events!  And about 5% of the time,
>>> one
>>> > touch produces three events!  I understand that this is actually a
>>> polling
>>> > solution, and...
>>> >
>>> > My own naive polling code does not have these problems.  At least it
>>> does
>>> > not seem to.
>>> >
>>> > I need the action to run reliably (which seems to eliminate fs.watch)
>>> and
>>> > exactly once (which seems to eliminate fs.watchFile) so it seems I am
>>> stuck
>>> > with my own clunky polling solution.  Again: Am I doing something
>>> silly?
>>> >
>>> > Thanks!
>>>
>>> With what version of Node and what kernel are you seeing this?
>>> fs.watch() should be the more reliable option provided you don't flood
>>> it with events.
>>>
>>> `uname -a` will tell you your kernel version, `sysctl
>>> fs.inotify.max_queued_events` shows the size of the event backlog
>>> (16384 on most systems).
>>>
>>> -
>>
>>
>> Hi  Ben.  Thank for your reply.  I should have included this of course:
>> My kernel is updated to
>>
>> $ uname -a
>> Linux zaphod 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:48:51 UTC 2012
>> x86_64 x86_64 x86_64 GNU/Linux
>>
>> and
>>
>> $ sysctl fs.inotify.max_queued_events
>> fs.inotify.max_queued_events = 16384
>>
>> as expected.
>>
>> Ok, I think I found the problem, but I do not understand.
>>
>> When I literally use "touch" to touch test.txt, both fs.watch and
>> fs.watchFile work as advertised.  But if I open test.txt with an editor
>> (gedit for example) and Save it from there, that's when the problems
>> happen.  I guess I'm not too surprised at the multiple events (the editor
>> might do that) but the spurious renames are interesting (maybe caching a
>> copy and then replacing the origianal?) and what I absolutely do no
>> understand is why the fs.watch solution actually jams.  For example:
>>
>> start my script
>> literally 'touch test.txt' a few times -- ok
>> now "Open" test.txt in gedit and "Save" twice -- get a combination of
>> changed and renamed events
>> At this point, the script is no longer getting and/or responding to
>> events.
>> 'touch test.txt' --> script does nothing
>> close gedit
>> 'touch test.txt' --> script does nothing
>>
>> So it appears that gedit has somehow hijacked or suppressed future events.
>>
>> If I start up a secon

Re: [nodejs] fs.watch and fs.watchFile

[C. Mundi]

Also, doing a 'mv test.txt other.txt' seems to go completely unnoticed by
fs.watch.  I expected a 'renamed' event while inotify tracked the actual
filesystem object (not the name which is used only initially to pick the
file).

I must be braindead.  I knew switching to decaff this month was a bad
idea...



On Fri, Mar 16, 2012 at 8:44 AM, C. Mundi  wrote:

>
>
> On Fri, Mar 16, 2012 at 7:33 AM, Ben Noordhuis  wrote:
>
>> On Fri, Mar 16, 2012 at 06:34, C. Mundi  wrote:
>> > I am aware that there are platform-specific issues with watching
>> files.  But
>> > I am getting strange-bad results just on Linux.  Please tell me I am
>> doing
>> > something silly below.
>> >
>> > var fs = require('fs');
>> >
>> > function act(curr, prev) {
>> >   console.log('the current mtime is: ' + curr.mtime);
>> >   console.log('the previous mtime was: ' + prev.mtime);
>> > };
>> >
>> > function act2(event,file) {
>> >   console.log('event is: ' + event);
>> >   if (file) {
>> > console.log('filename provided: ' + file);
>> >   } else {
>> > console.log('filename not provided');
>> >   }
>> > };
>> >
>> > // ucomment one or the other (but not both!) of the following lines:
>> > // fs.watchFile('test.txt', act);
>> > // fs.watch('test.txt', act2);
>> >
>> > When I use fs.watch + act2, and simply repeatedly 'touch' the file
>> (about
>> > once per second) the first two events are 'change' and the next three
>> are
>> > 'rename' (!) and then program just stops producing output.  It's as if
>> the
>> > events are eitehr never fired or never handled.  I understand that this
>> is
>> > based (on Linux) on inotify?
>> >
>> > So I switch to fs.watchFile + act.  Again, I 'touch' the test file about
>> > once per second.  This always produces an event.  The problem is, about
>> 30%
>> > of the time one touch produces two events!  And about 5% of the time,
>> one
>> > touch produces three events!  I understand that this is actually a
>> polling
>> > solution, and...
>> >
>> > My own naive polling code does not have these problems.  At least it
>> does
>> > not seem to.
>> >
>> > I need the action to run reliably (which seems to eliminate fs.watch)
>> and
>> > exactly once (which seems to eliminate fs.watchFile) so it seems I am
>> stuck
>> > with my own clunky polling solution.  Again: Am I doing something silly?
>> >
>> > Thanks!
>>
>> With what version of Node and what kernel are you seeing this?
>> fs.watch() should be the more reliable option provided you don't flood
>> it with events.
>>
>> `uname -a` will tell you your kernel version, `sysctl
>> fs.inotify.max_queued_events` shows the size of the event backlog
>> (16384 on most systems).
>>
>> -
>
>
> Hi  Ben.  Thank for your reply.  I should have included this of course: My
> kernel is updated to
>
> $ uname -a
> Linux zaphod 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:48:51 UTC 2012
> x86_64 x86_64 x86_64 GNU/Linux
>
> and
>
> $ sysctl fs.inotify.max_queued_events
> fs.inotify.max_queued_events = 16384
>
> as expected.
>
> Ok, I think I found the problem, but I do not understand.
>
> When I literally use "touch" to touch test.txt, both fs.watch and
> fs.watchFile work as advertised.  But if I open test.txt with an editor
> (gedit for example) and Save it from there, that's when the problems
> happen.  I guess I'm not too surprised at the multiple events (the editor
> might do that) but the spurious renames are interesting (maybe caching a
> copy and then replacing the origianal?) and what I absolutely do no
> understand is why the fs.watch solution actually jams.  For example:
>
> start my script
> literally 'touch test.txt' a few times -- ok
> now "Open" test.txt in gedit and "Save" twice -- get a combination of
> changed and renamed events
> At this point, the script is no longer getting and/or responding to events.
> 'touch test.txt' --> script does nothing
> close gedit
> 'touch test.txt' --> script does nothing
>
> So it appears that gedit has somehow hijacked or suppressed future events.
>
> If I start up a second instance of node (leaving the first one running)
> then the second instance does receive and respond to events triggered by
> 'touch test.txt' while the first instance remains stuck.
>
> Ok, this is probably not about node.  But people using node might want to
> know about this behavior.  I certainly did not expect a userspace app like
> gedit to affect whether inotify events get to node.
>
>
>

-- 
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

Re: [nodejs] fs.watch and fs.watchFile

[Dan North]

When you watch a file you're actually watching an inode (a magic number
that represents the file). If that file gets deleted and another one with
the same name gets created, it's not the same file (it will have a
different inode). Likewise if you replace a file with mv(1).

This is the difference between tail -f and tail -F for example: the latter
watches to see if the file is replaced by another. If gedit is saving the
current buffer into a temporary file then moving it over the new one (a
common approach because moving a file is atomic) you will no longer see
watch events on the new file.

You can add another watch to the directory containing the file, then you'll
see the create, remove, rename, etc. events in that and you should be able
to spot what's going on and create a new watch for the new file (and close
the old one of course).


On 16 March 2012 15:44, C. Mundi  wrote:

>
>
> On Fri, Mar 16, 2012 at 7:33 AM, Ben Noordhuis  wrote:
>
>> On Fri, Mar 16, 2012 at 06:34, C. Mundi  wrote:
>> > I am aware that there are platform-specific issues with watching
>> files.  But
>> > I am getting strange-bad results just on Linux.  Please tell me I am
>> doing
>> > something silly below.
>> >
>> > var fs = require('fs');
>> >
>> > function act(curr, prev) {
>> >   console.log('the current mtime is: ' + curr.mtime);
>> >   console.log('the previous mtime was: ' + prev.mtime);
>> > };
>> >
>> > function act2(event,file) {
>> >   console.log('event is: ' + event);
>> >   if (file) {
>> > console.log('filename provided: ' + file);
>> >   } else {
>> > console.log('filename not provided');
>> >   }
>> > };
>> >
>> > // ucomment one or the other (but not both!) of the following lines:
>> > // fs.watchFile('test.txt', act);
>> > // fs.watch('test.txt', act2);
>> >
>> > When I use fs.watch + act2, and simply repeatedly 'touch' the file
>> (about
>> > once per second) the first two events are 'change' and the next three
>> are
>> > 'rename' (!) and then program just stops producing output.  It's as if
>> the
>> > events are eitehr never fired or never handled.  I understand that this
>> is
>> > based (on Linux) on inotify?
>> >
>> > So I switch to fs.watchFile + act.  Again, I 'touch' the test file about
>> > once per second.  This always produces an event.  The problem is, about
>> 30%
>> > of the time one touch produces two events!  And about 5% of the time,
>> one
>> > touch produces three events!  I understand that this is actually a
>> polling
>> > solution, and...
>> >
>> > My own naive polling code does not have these problems.  At least it
>> does
>> > not seem to.
>> >
>> > I need the action to run reliably (which seems to eliminate fs.watch)
>> and
>> > exactly once (which seems to eliminate fs.watchFile) so it seems I am
>> stuck
>> > with my own clunky polling solution.  Again: Am I doing something silly?
>> >
>> > Thanks!
>>
>> With what version of Node and what kernel are you seeing this?
>> fs.watch() should be the more reliable option provided you don't flood
>> it with events.
>>
>> `uname -a` will tell you your kernel version, `sysctl
>> fs.inotify.max_queued_events` shows the size of the event backlog
>> (16384 on most systems).
>>
>> -
>
>
> Hi  Ben.  Thank for your reply.  I should have included this of course: My
> kernel is updated to
>
> $ uname -a
> Linux zaphod 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:48:51 UTC 2012
> x86_64 x86_64 x86_64 GNU/Linux
>
> and
>
> $ sysctl fs.inotify.max_queued_events
> fs.inotify.max_queued_events = 16384
>
> as expected.
>
> Ok, I think I found the problem, but I do not understand.
>
> When I literally use "touch" to touch test.txt, both fs.watch and
> fs.watchFile work as advertised.  But if I open test.txt with an editor
> (gedit for example) and Save it from there, that's when the problems
> happen.  I guess I'm not too surprised at the multiple events (the editor
> might do that) but the spurious renames are interesting (maybe caching a
> copy and then replacing the origianal?) and what I absolutely do no
> understand is why the fs.watch solution actually jams.  For example:
>
> start my script
> literally 'touch test.txt' a few times -- ok
> now "Open" test.txt in gedit and "Save" twice -- get a combination of
> changed and renamed events
> At this point, the script is no longer getting and/or responding to events.
> 'touch test.txt' --> script does nothing
> close gedit
> 'touch test.txt' --> script does nothing
>
> So it appears that gedit has somehow hijacked or suppressed future events.
>
> If I start up a second instance of node (leaving the first one running)
> then the second instance does receive and respond to events triggered by
> 'touch test.txt' while the first instance remains stuck.
>
> Ok, this is probably not about node.  But people using node might want to
> know about this behavior.  I certainly did not expect a userspace app like
> gedit to affect whether inotify events get to node.
>
>
>  --
> Job Board: http://jobs.nodejs.o

Re: [nodejs] fs.watch and fs.watchFile

[C. Mundi]

On Fri, Mar 16, 2012 at 7:33 AM, Ben Noordhuis  wrote:

> On Fri, Mar 16, 2012 at 06:34, C. Mundi  wrote:
> > I am aware that there are platform-specific issues with watching files.
> But
> > I am getting strange-bad results just on Linux.  Please tell me I am
> doing
> > something silly below.
> >
> > var fs = require('fs');
> >
> > function act(curr, prev) {
> >   console.log('the current mtime is: ' + curr.mtime);
> >   console.log('the previous mtime was: ' + prev.mtime);
> > };
> >
> > function act2(event,file) {
> >   console.log('event is: ' + event);
> >   if (file) {
> > console.log('filename provided: ' + file);
> >   } else {
> > console.log('filename not provided');
> >   }
> > };
> >
> > // ucomment one or the other (but not both!) of the following lines:
> > // fs.watchFile('test.txt', act);
> > // fs.watch('test.txt', act2);
> >
> > When I use fs.watch + act2, and simply repeatedly 'touch' the file (about
> > once per second) the first two events are 'change' and the next three are
> > 'rename' (!) and then program just stops producing output.  It's as if
> the
> > events are eitehr never fired or never handled.  I understand that this
> is
> > based (on Linux) on inotify?
> >
> > So I switch to fs.watchFile + act.  Again, I 'touch' the test file about
> > once per second.  This always produces an event.  The problem is, about
> 30%
> > of the time one touch produces two events!  And about 5% of the time, one
> > touch produces three events!  I understand that this is actually a
> polling
> > solution, and...
> >
> > My own naive polling code does not have these problems.  At least it does
> > not seem to.
> >
> > I need the action to run reliably (which seems to eliminate fs.watch) and
> > exactly once (which seems to eliminate fs.watchFile) so it seems I am
> stuck
> > with my own clunky polling solution.  Again: Am I doing something silly?
> >
> > Thanks!
>
> With what version of Node and what kernel are you seeing this?
> fs.watch() should be the more reliable option provided you don't flood
> it with events.
>
> `uname -a` will tell you your kernel version, `sysctl
> fs.inotify.max_queued_events` shows the size of the event backlog
> (16384 on most systems).
>
> -


Hi  Ben.  Thank for your reply.  I should have included this of course: My
kernel is updated to

$ uname -a
Linux zaphod 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:48:51 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux

and

$ sysctl fs.inotify.max_queued_events
fs.inotify.max_queued_events = 16384

as expected.

Ok, I think I found the problem, but I do not understand.

When I literally use "touch" to touch test.txt, both fs.watch and
fs.watchFile work as advertised.  But if I open test.txt with an editor
(gedit for example) and Save it from there, that's when the problems
happen.  I guess I'm not too surprised at the multiple events (the editor
might do that) but the spurious renames are interesting (maybe caching a
copy and then replacing the origianal?) and what I absolutely do no
understand is why the fs.watch solution actually jams.  For example:

start my script
literally 'touch test.txt' a few times -- ok
now "Open" test.txt in gedit and "Save" twice -- get a combination of
changed and renamed events
At this point, the script is no longer getting and/or responding to events.
'touch test.txt' --> script does nothing
close gedit
'touch test.txt' --> script does nothing

So it appears that gedit has somehow hijacked or suppressed future events.

If I start up a second instance of node (leaving the first one running)
then the second instance does receive and respond to events triggered by
'touch test.txt' while the first instance remains stuck.

Ok, this is probably not about node.  But people using node might want to
know about this behavior.  I certainly did not expect a userspace app like
gedit to affect whether inotify events get to node.

-- 
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

Re: [nodejs] Re: Finding native memory leaks in node

[George Stagas]

You can pinpoint the leak by writing stress tests. Don't wait days for
the leak to show in production. Find which component causes it. Make a
list of suspects. If it's an http server, start with simple requests.
Does the memory go up? No? Maybe it's the db? Try a million
read/writes. Did you find the component that leaks? Follow the chain
of events, commenting out suspicious code and trying again until the
leak disappears.

2012/3/16 robot1125 :
>> So, my general question, how do people go about debugging memory leaks
>> in native code in node (or node itself)?
>
> You may find this interview with Brian Cantrill of Joyent interesting.
>
> http://www.infoq.com/interviews/operating-nodejs-production-bryan-cantrill
>
> He discusses some of the tools they use to debug node apps in
> production at Joyent.  Some of them require running under their
> homebrew OS, but the discussion may give you some ideas.
>
> --
> 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

-- 
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

Re: [nodejs] fs.watch and fs.watchFile

[Ben Noordhuis]

On Fri, Mar 16, 2012 at 06:34, C. Mundi  wrote:
> I am aware that there are platform-specific issues with watching files.  But
> I am getting strange-bad results just on Linux.  Please tell me I am doing
> something silly below.
>
> var fs = require('fs');
>
> function act(curr, prev) {
>   console.log('the current mtime is: ' + curr.mtime);
>   console.log('the previous mtime was: ' + prev.mtime);
> };
>
> function act2(event,file) {
>   console.log('event is: ' + event);
>   if (file) {
>     console.log('filename provided: ' + file);
>   } else {
>     console.log('filename not provided');
>   }
> };
>
> // ucomment one or the other (but not both!) of the following lines:
> // fs.watchFile('test.txt', act);
> // fs.watch('test.txt', act2);
>
> When I use fs.watch + act2, and simply repeatedly 'touch' the file (about
> once per second) the first two events are 'change' and the next three are
> 'rename' (!) and then program just stops producing output.  It's as if the
> events are eitehr never fired or never handled.  I understand that this is
> based (on Linux) on inotify?
>
> So I switch to fs.watchFile + act.  Again, I 'touch' the test file about
> once per second.  This always produces an event.  The problem is, about 30%
> of the time one touch produces two events!  And about 5% of the time, one
> touch produces three events!  I understand that this is actually a polling
> solution, and...
>
> My own naive polling code does not have these problems.  At least it does
> not seem to.
>
> I need the action to run reliably (which seems to eliminate fs.watch) and
> exactly once (which seems to eliminate fs.watchFile) so it seems I am stuck
> with my own clunky polling solution.  Again: Am I doing something silly?
>
> Thanks!

With what version of Node and what kernel are you seeing this?
fs.watch() should be the more reliable option provided you don't flood
it with events.

`uname -a` will tell you your kernel version, `sysctl
fs.inotify.max_queued_events` shows the size of the event backlog
(16384 on most systems).

-- 
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

Re: [nodejs] Re: Would this ngnix bug affect node?

[Ben Noordhuis]

On Fri, Mar 16, 2012 at 13:49, dhruvbird  wrote:
> On Mar 15, 9:32 am, Ben Noordhuis  wrote:
>> On Thu, Mar 15, 2012 at 14:27, dhruvbird  wrote:
>> > I am assuming we use a significant portion of the ngnix http parser.
>>
>> >http://nginx.org/download/patch.2012.memory.txt
>>
>> We don't[1]. They're both big state machines written in C, that's
>> where the similarity ends.
>>
>> [1]https://github.com/joyent/http-parser
>
> ah! Thanks for the clarification!
>
> I saw this line in the code and thought they were the same: " Based on
> src/http/ngx_http_parse.c from NGINX copyright Igor Sysoev"

Early versions of http_parser borrowed some from nginx but there's
little (maybe nothing) left of that.

-- 
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

[nodejs] nodejs 0.4.9 and mongoose 2.5.9 hangs on SSD

[yyy]

Thought I'd put my little experience to the great ether. Maybe if any of 
you can help a bit, that would be good as well.

I was using node 0.4.9 when I switched to SSD (patriot pyro, 120gb)
Everything seemed to work fine:


   - everything reinstalled just fine.
   - node came up.
   - served up pages as expected. 
   - I could console connect to mongod just fine.  save() and find() all 
   worked as expected


Except... when my little app was fetching a doc, it hangs.(WT???)  Through 
binary chop, I reduced the problem down to my code, 
where I was making a db call.

So... what do you do?  What logs do I look for?

   - mongodb log looked fine.  From mongo, it looked ok.
   - console logging from express didn't yield any useful information.


I decided on a whim and pseudo desperation decided to move up nodejs 
version and voila.  it just worked.
I wish I had more to contribute, but unfortunately, I have no idea why my 
new h/w configuration would cause this problem and 
why the newer version of nodejs fixed it.

The problem component versions are:

nodejs   0.4.9
mongoose 2.5.9
express 2.5.4

I would be happy to investigate further, if any of you can suggest some 
course of action.

Best Wishes.

YYY



-- 
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

[nodejs] Re: Finding native memory leaks in node

[robot1125]

> So, my general question, how do people go about debugging memory leaks
> in native code in node (or node itself)?

You may find this interview with Brian Cantrill of Joyent interesting.

http://www.infoq.com/interviews/operating-nodejs-production-bryan-cantrill

He discusses some of the tools they use to debug node apps in
production at Joyent.  Some of them require running under their
homebrew OS, but the discussion may give you some ideas.

-- 
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

Re: [nodejs] best practices for writing cross-platform node applications

[Matt]

On Fri, Mar 16, 2012 at 5:32 AM, Oliver Leics wrote:

> Network-paths might be an exception: \\host\path\to\whatever. But I
> would not be surprised if //hoist/path/to/whatever works too.
>

It does.

-- 
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

[nodejs] Re: Would this ngnix bug affect node?

[dhruvbird]

On Mar 15, 9:32 am, Ben Noordhuis  wrote:
> On Thu, Mar 15, 2012 at 14:27, dhruvbird  wrote:
> > I am assuming we use a significant portion of the ngnix http parser.
>
> >http://nginx.org/download/patch.2012.memory.txt
>
> We don't[1]. They're both big state machines written in C, that's
> where the similarity ends.
>
> [1]https://github.com/joyent/http-parser

ah! Thanks for the clarification!

I saw this line in the code and thought they were the same: " Based on
src/http/ngx_http_parse.c from NGINX copyright Igor Sysoev"

-- 
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

[nodejs] Re: Recommendation for test framework for objects which util.inherits EventEmitter.

[Chris Dew]

I really like Mocha, but I have a problem ordering the execution of async 
tests:

http://stackoverflow.com/questions/9736429/how-can-i-execute-async-mocha-tests-nodejs-in-order
 

Thanks,

Chris.

On Friday, 16 March 2012 09:02:20 UTC, Chris Dew wrote:
>
> Thanks, I'll have a look at Mocha.
>
> On Thursday, 15 March 2012 21:40:19 UTC, Chad Retz wrote:
>>
>> What I do in Mocha is simply take the done callback and call it with 
>> success once I hit the event and either have a timeout otherwise or call 
>> the done callback with an error on an "end" if I know the proper event 
>> wasn't emitted.
>>
>> On Thursday, March 15, 2012 12:26:43 PM UTC-5, Chris Dew wrote:
>>>
>>> I'm currently using Vows, but finding it difficult to write tests to 
>>> respond to the firing of events from objects which util.inherits 
>>> EventEmitter.
>>>
>>> Has anyone had success testing EventEmitters in other frameworks?
>>>
>>> Thanks,
>>>
>>> Chris.
>>>
>>

-- 
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

Re: [nodejs] Nominate me for a NodeConf 2012 Streams talk

[Ilya Dmitrichenko]

On 16 March 2012 09:57, Richard Marr  wrote:
>> I wonder is there any demand for a British NodeConf?
>
> +1

+1
NodeConf in europe anywhere :~)

-- 
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

Re: [nodejs] best practices for writing cross-platform node applications

[Brandon Benvie]

Seriously, kind of an itch of mine. Windows understands 
'/' natively, requiring no translation, The extend of the issue is that 
Windows roots to a drive or whatever,so /whatever isn't valid but 
c:/whatever  is.

-- 
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

Re: [nodejs] Nominate me for a NodeConf 2012 Streams talk

[Richard Marr]

> I wonder is there any demand for a British NodeConf?

+1




On 15 March 2012 23:45, Dave Clements  wrote:

> I wonder is there any demand for a British NodeConf?
>
> I wouldn't mind talking about the possibilities of making that happen.
>
> --
> 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
>



-- 
Richard Marr

-- 
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

Re: [nodejs] Nominate me for a NodeConf 2012 Streams talk

[cole gillespie]

mikeal -- bring nodeconf to berlin!

On Fri, Mar 16, 2012 at 10:03 AM, David Björklund  wrote:

> +1 for an european nodeconf!
> - David Björklund
>
>
>
>
> On Fri, Mar 16, 2012 at 01:45, Matt  wrote:
>
>> People need to talk more about streams.
>>
>> Here's a stream I wrote for Haraka that stores lines of text (of emails
>> for Haraka, but kind of irrelevant), and overflows to a file when it gets
>> too big. The main aim was to be able to just .pipe() into something else,
>> but with a customisable filter in the path of the stream (for example to
>> turn /^\./m => '..' for certain things).
>>
>> It's not finished yet, but might be fun to learn from (it's also why I
>> moaned on twitter about how Streams are currently too hard, but also very
>> very cool).
>>
>> https://gist.github.com/1996244
>>
>> Matt.
>>
>>
>> On Thu, Mar 15, 2012 at 6:38 PM, Marco Rogers wrote:
>>
>>> The call for speakers is open for NodeConf 2012. I want to talk about
>>> streams in node. Last year I only got a half hour to cover a large topic.
>>> This may be a simliar situation. But at a high level you an vote for any or
>>> all of these.
>>>
>>> - What do we mean by streams? require('stream'). How these relate to net
>>> sockets and fs streams.
>>> - What are some best practices for working with streams?
>>> - How to take advantage of custom streams to do cool things in node
>>> without breaking things or ruining efficiency
>>> - How to add stream compatibility to your module
>>> - How to maintain state across streams. When would you even want to do
>>> this? See https://github.com/polotek/procstreams
>>>
>>> Feel free to suggest others. Dont forget to fill out the form.
>>>
>>> http://www.nodeconf.com/
>>>
>>> :Marco @polotek
>>>
>>> --
>>> 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
>>>
>>
>>  --
>> 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
>>
>
>  --
> 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
>

-- 
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

Re: [nodejs] best practices for writing cross-platform node applications

[Oliver Leics]

On Thu, Mar 15, 2012 at 9:25 PM, Isaac Schlueter  wrote:
> This is a great idea for a wiki page, yes.
>
> On Thu, Mar 15, 2012 at 12:44, Ted Young  wrote:
>> paths - how necessary is it to use the path module?  For example, is it
>> necessary to use in require() statements?  fs statements?
>
> Use path.resolve() to resolve paths and make relative paths absolute.
> Do not use path.join() for this.  It is not nearly as smart about
> Windows paths.

Slash "/" works fine on Windows, no need to convert to backslash "\",
no need to run paths for require-statements through the path-module.

If only the path-module would not use backslash on windows to get rid
of all those .replace(/\/, '/')-statements..

If I remember it correctly, Python uses slash within its
path-transforming-libs. On PHP there is a constant
(DIRECTORY_SEPARATOR), but it is a real mess.

Network-paths might be an exception: \\host\path\to\whatever. But I
would not be surprised if //hoist/path/to/whatever works too.

>> system resources - when accessing system resources, best practices?  For
>> example, in python if you want to access /dev/null you can say os.devnull,
>> but there currently is no node equivalent.
>
> I'm not sure what the best answer for /dev/null on windows is.  Igor?  Bert?

On commandline it is:

prog.exe > NUL

-- 
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

Re: [nodejs] Nominate me for a NodeConf 2012 Streams talk

[David Björklund]

+1 for an european nodeconf!
- David Björklund



On Fri, Mar 16, 2012 at 01:45, Matt  wrote:

> People need to talk more about streams.
>
> Here's a stream I wrote for Haraka that stores lines of text (of emails
> for Haraka, but kind of irrelevant), and overflows to a file when it gets
> too big. The main aim was to be able to just .pipe() into something else,
> but with a customisable filter in the path of the stream (for example to
> turn /^\./m => '..' for certain things).
>
> It's not finished yet, but might be fun to learn from (it's also why I
> moaned on twitter about how Streams are currently too hard, but also very
> very cool).
>
> https://gist.github.com/1996244
>
> Matt.
>
>
> On Thu, Mar 15, 2012 at 6:38 PM, Marco Rogers wrote:
>
>> The call for speakers is open for NodeConf 2012. I want to talk about
>> streams in node. Last year I only got a half hour to cover a large topic.
>> This may be a simliar situation. But at a high level you an vote for any or
>> all of these.
>>
>> - What do we mean by streams? require('stream'). How these relate to net
>> sockets and fs streams.
>> - What are some best practices for working with streams?
>> - How to take advantage of custom streams to do cool things in node
>> without breaking things or ruining efficiency
>> - How to add stream compatibility to your module
>> - How to maintain state across streams. When would you even want to do
>> this? See https://github.com/polotek/procstreams
>>
>> Feel free to suggest others. Dont forget to fill out the form.
>>
>> http://www.nodeconf.com/
>>
>> :Marco @polotek
>>
>> --
>> 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
>>
>
>  --
> 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
>

-- 
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

[nodejs] Re: Recommendation for test framework for objects which util.inherits EventEmitter.

[Chris Dew]

Thanks, I'll have a look at Mocha.

On Thursday, 15 March 2012 21:40:19 UTC, Chad Retz wrote:
>
> What I do in Mocha is simply take the done callback and call it with 
> success once I hit the event and either have a timeout otherwise or call 
> the done callback with an error on an "end" if I know the proper event 
> wasn't emitted.
>
> On Thursday, March 15, 2012 12:26:43 PM UTC-5, Chris Dew wrote:
>>
>> I'm currently using Vows, but finding it difficult to write tests to 
>> respond to the firing of events from objects which util.inherits 
>> EventEmitter.
>>
>> Has anyone had success testing EventEmitters in other frameworks?
>>
>> Thanks,
>>
>> Chris.
>>
>

-- 
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

[nodejs] Re: Node.js Clustering and interprocess communication

[Антон Бравин]

You have a large load on the server? Do not think that the replacement of 
radis on Mongo may be quite lower power at server side?

пятница, 16 марта 2012 г. 9:31:23 UTC+4 пользователь Murat T. написал:
>
> Hi Guys,
>
> Those are the exact things I wanted. I have played with clusterhub but in 
> the end switched to mongo. It reduced the complexity of the application. It 
> seems Redis wasn't suitable for this job, as I deleted 300+ lines of code 
> after the switch.
>
> Thanks again,
>
> On Saturday, March 10, 2012 1:54:44 AM UTC+11, Murat T. wrote:
>>
>> Hi,
>>
>> I have been developing a game since last month and there are a couple of 
>> things which bothers me.
>>
>> I am using socket.io, and storing all the data into redis. However, most 
>> of my data is temporary and doesn't need to go into redis. If in case I 
>> restart the node, those temporary information in redis must be deleted 
>> anyway. The reason I am storing in redis is that I want to make sure it can 
>> scale in the future. Current design allows that.
>>
>> However, I have been doing some small benchmarks and noticed that I won't 
>> need to scale node to multiple machines. If I can have 8/16 cores in one 
>> server, and fork workers using clustering mechanism, everything should be 
>> more than enough. So, I want to eliminate redis and store everything in 
>> javascript objects, which is fine for me, since I don't need to save any 
>> state. (I have somethings to save and will still use redis for those cases, 
>> but for most cases I don't need it)
>>
>> The main reason is that I read and write a lot of small data and I need 
>> to write lots of code to do that, which I don't need if only I can use 
>> simple javascript objects.
>>
>> If I eliminate redis, I will have some objects which may have more than 
>> 100.000 elements. I have been testing the performance of interprocess 
>> communication, and it takes almost a second to send large objects between 
>> children. (If I am not doing something wrong)
>>
>> So, is there any way to simplify the app or improve this performance? Do 
>> I have to use a key value store for sharing large objects across other 
>> nodes. I just want to have a couple of objects, read and write a lot of 
>> data and share between processes.
>>
>> Thanks in advance,
>>
>>
>>
>>
>>

-- 
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

Re: [nodejs] Re: HELP! Windows NPM problem

[Ryan Schmidt]

On Mar 16, 2012, at 01:41, Brandon Benvie wrote:

> node runs faster on Windows than it does on Linux

I would not have expected that. Are there tests/results/statistics that back up 
this statement?



-- 
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

Re: [nodejs] Q: connections, the event loop and the one-and-only JS thread

[Anand George]

Really nice explanation of the behavior of the node single threaded
event-loop. Much more elaborate and comprehensive than the typical 'Hello
world' explanation. Wonder if it could be included in a Node.js wiki page.

On Thu, Mar 15, 2012 at 9:04 PM, C. Mundi  wrote:

> This is helpful, and broadens my perspective.  Thanks for cleaning up my
> nomenclature!
> On Mar 15, 2012 3:29 AM, "Jorge"  wrote:
>
>> On Mar 15, 2012, at 6:53 AM, C. Mundi wrote:
>>
>> > I know *what* the following code does.  I want to understand *why*.
>> >
>> > Consider the following client/server pair:
>> >
>> > client.js
>> > var net = require('net');
>> > var conn = net.createConnection(8000, function() {  // 'connect'
>> listener
>> >   console.error('connected to server');
>> >   conn.on('data', function(data) {
>> > var msg = data.toString();
>> > console.error('Got data: ' + msg);
>> > conn.write('Back at ya!');
>> > conn.end();  // Pay close attention!
>> >   });
>> > });
>> >
>> > server.js
>> > var net = require('net');
>> > var server = net.createServer(function(client) {
>> >   console.error('Accepted connection');
>> >   client.on('end', function() {
>> > console.error('Client has closed connection.');
>> >   });
>> >   client.on('data', function(data) {
>> > var msg = data.toString();
>> > console.error('Got data: ' + msg);
>> >   });
>> >   client.write('Welcome');
>> > });
>> >
>> > server.listen(8000, function() {
>> >   console.error('Listening on port 8000');
>> > });
>> >
>> > So we start the server ('node server.js') and then we run the client
>> ('node client.js') and see (as expected) that the server accepts the
>> connection from the client, they exchange a pair of messages and the client
>> exits.  Now let's comment out the 'conn.end()' from the client.  Now the
>> client hangs around until we kill it.  What I want to understand is this:
>> how does the V8 thread know that it should or should not hang around?  The
>> conn.end() is in the 'connect' event listener, which gets registered only
>> after the connection is established.  (And it is important to notice that
>> if the connection had been refused, then the client would have exited with
>> an error.)  My mental model goes like this, and I would like some feedback:
>> >
>> > During the execution of each event loop, node memoizes every async call
>> long enough to see if the callback could be called.  As long as there is at
>> least one pending callback (and no error or explicit exit() call) the event
>> loop keeps running.  Ok.  Now let's suppose the server accepts the
>> connection.  The 'connect' event is caught by the listener callback in the
>> client.  And after this 'connect' callback executes... node hangs around,
>> because the 'connect' callback registered a callback for the 'data' event.
>>  And event handlers are persistent, so execution keeps looping if the
>> conn.end() is not present.  Now, somehow, conn.end() breaks us out of the
>> loop, at which point there is nothing left to do *and* nothing left to wait
>> for, so client.js exits.  My guess is that the conn.end() call unregisters
>> all the event handlers associated with the connection object conn, at which
>> point node has nothing left to do.
>> >
>> > Am I even close to the right way of thinking about this?
>> >
>> > Thanks!
>>
>> The server (server.js): .createServer() creates a socket and then
>> .listen() puts it into listen for and accept connections mode, node notices
>> that the app is listening for connections so it must flag the event loop
>> not to quit (it's really .listen() who flags it, see below). Remove the
>> server.listen() or add a server.close() and node will remove the flag and
>> then it will quit.
>>
>> WRT the client (client.js): createConnection() creates a socket and tries
>> to connect to a host,port. Node flags the event loop not to quit until that
>> connection attempt either fails or succeeds. If the connection succeeds,
>> node will remove the flag only after the connection ends/is closed.
>>
>> For example, in the case of ev_async events, the ones that threads_a_gogo
>> (which is an über awesome module btw, check it out! :-) uses, to flag the
>> event loop not to quit yet there's an ev_ref() call:
>>
>>
>> https://github.com/xk/node-threads-a-gogo/blob/master/src/threads_a_gogo.cc#L691
>>
>> and it's thread.create() who calls it, so that node won't quit as long as
>> there's a thread alive.
>>
>> to remove the flag then I do an ev_unref() call:
>>
>>
>> https://github.com/xk/node-threads-a-gogo/blob/master/src/threads_a_gogo.cc#L358
>>
>> and I do that in thread.destroy(), for obvious reasons.
>>
>> All these ev_ref()s add up, e.g. if I .create() 3 threads and then
>> .destroy() 2 of them, there will still be one thread ev_ref()d, so the
>> event loop/node won't quit yet.
>>
>> This is how node 'learns' whether to quit or not.
>>
>> Hope it helps. Cheers,
>> --
>> Jorge.
>>
>> --
>> Job Board: http://jobs.nodejs.org/
>> Posting