Isolates removed

[Isaac Schlueter]

The Isolates feature was intended to make it possible to run
child_process.fork() in a thread, rather than a full process. The
justification was to make it cheaper to spin up new child node
instances, as well as allowing for fast message-passing using shared
memory in binary addons, while retaining the semantics of node's
child_process implementation by keeping them in completely isolated v8
instances.

It was a very informative experiment, but has ultimately turned out to
cause too much instability in node's internal functionality to justify
continuing with it at this time. It requires a lot of complexity to
be added to libuv and node, and isn't likely to yield enough gains to
be worth the investment.

We're going to roll back the changes in master that were added to
support Isolates, and instead focus on Domains and other things that
promise to increase stability and make debugging easier. This change
will land in 0.7.3. It's entirely possible that we may decide to use
v8 isolates in some future version of node, but they will not be in
0.8.

If you were eagerly looking forward to using this feature, and find
yourself shocked or frustrated by this decision, please contact me
directly. It's not our intention to leave anyone stuck, and I do
understand that this feature was promised for some time. If this
causes hardship for you, let's figure out another way to get your use
cases handled.

It's never easy to back-pedal, but doing experimental things means
sometimes finding out that you were headed in the wrong direction.
The sooner we make this change, the easier it will be.

Thanks.

[Mikeal Rogers]

3 cheers for focusing on debugging and stability!

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

[Diogo Resende]

+1

I think stability, debugging and modularity are good goals for 0.8.

---
Diogo R.

[geddesign]

@Isaac I'm a little disappointed because this feature was going to make Node more able to do intense CPU-bound operations without blocking everything else, a limitation that is one of Node's biggest criticisms. The browsers elegantly solve this problem with web workers. Is there a reason Node couldn't use web workers or something like it to solve the issue?

[Mikeal Rogers]

This may be the first time in the history of the internet that Web Workers have been referred to as "elegant" :)

Keep in mind that Web Workers use message passing and, outside of some experimental code in Chrome, entirely serialize the contents of the message which is easily accomplished with the same performance using system processes in node 0.6.x.

-Mikeal

On Feb 3, 2012, at February 3, 20121:54 PM, geddesign wrote:

@Isaac I'm a little disappointed because this feature was going to make Node more able to do intense CPU-bound operations without blocking everything else, a limitation that is one of Node's biggest criticisms. The browsers elegantly solve this problem with web workers. Is there a reason Node couldn't use web workers or something like it to solve the issue?

[Isaac Schlueter]

geddesign,

You can do this today with child processes. Nothing about the
child_process module is being removed from the plans except the
{thread:true} argument, which requires a lot of internal changes to
support.

The drawback of using child processes instead of threads is that (a)
it's a bit more expensive to fire them up, and (b) all communication
has to be over a serialized channel (unless you use something like
shm_open).

Regarding (a), you still have the cost of starting the v8 context in
an isolate, so it's not *that* much of a savings. Regarding (b), web
workers serialize everything to json and back just like node's
child_process.fork() approach.

There are other semantic differences between processes and threads, of
course. They're very different from the system's point of view, and
so maintaining the same semantics with both approaches was part of
what made this feature so difficult.

[Marco Rogers]

+1

The only thing I disagree with is taking the frustration offline. People should be able to express themselves here. They should share their use cases that they feel are being hampered, and the response should be posted here as well so that everyone can benefit.

:Marco

[Isaac Schlueter]

Good point. I should clarify:

Complaining out in the open is perfectly fine, too. But, I want
people to know that if this affects them, and they don't want to
publicize the inner workings of their technology, they're also welcome
to complain to me directly, and we'll make it right.

[Ted Young]

I would be interested in how people are currently using shared memory for IPC in node.  Any success stories?

Ted Young

radicalDESIGNS

[geddesign]

Thanks for the clarification. Makes sense.

[Tane]

Thanks for clarification on this going ahead - disappointing but completely understandable and I'd rather know earlier than later.

The current app I'm working makes heavy use of child_process.fork to call jsdom processes, avoiding high memory use in the core app (jsdom seems to be leaky but because v8-profiler doesn't work with >0.4.x and the author seemed to have abandoned it, it's hard to pinpoint where the issue exactly is) and did anticipate isolates landing in 0.8 - so the design may need to be reconsidered down the line - but at least for now it's not a large user base and the data extracted via jsdom can be cached.

If you do have any questions about my use case, please feel free to ping me off-list (the current dev is under NDA so I can't go into detail here).

- Tane

[Ben Taber]

Check out the 3.6.2 branch of v8-profiler. Worked for me on 0.5.x, but
haven't tried it recently.

https://github.com/dannycoates/v8-profiler/commit/fc0822268e3e0269649d0d641956e567ddad3186

https://github.com/dannycoates/v8-profiler/tree/3.6.2

[C. Mundi]

Kudos to you Isaac and the node dev community for putting a value on stability with prudent acts and transparent communication. 

I recently decided to try node despite my sense that it might turn out to be just a little too hot and trendy.  I chose to accept that risk.  So decisions like this, communicated like this, make me feel very good about investing in node.  Thank you!

[Mark Hahn]

>  it might turn out to be just a little too hot and trendy 

I know it isn't 1.0 but I've been using it in production for a year and loving it.

[rektide]

> but has ultimately turned out to cause too much instability in node's internal functionality to justify continuing with it at this time.

please specify, elaborate, explain or make note upon this conflict, as
if in warning to those who would have wished to pursue the cause
further.

[C. Mundi]

Echoing Mark Hahn...

I'm not a slave to version numbers (not naming names, but we all know some 3.x FOSS with beta quality) but I am always wary of hype.  And I have to say node lives up to its hype and the dev community has a refreshingly mature dedication for quality.  Three cheers!

On Feb 6, 2012 3:05 PM, "Mark Hahn" <ma...@hahnca.com> wrote:

>  it might turn out to be just a little too hot and trendy 

I know it isn't 1.0 but I've been using it in production for a year and loving it.

[Ben Noordhuis]

Retrofitting thread safety onto a code base that wasn't designed for
it leaves a very wide margin for obscure bugs. Offset against the
potential benefits (which were questionable and probably not
bottlenecks to most people*) the choice was not hard to make.

* Mostly faster worker start-up times and faster inter-worker communication.

[Jeff Barczewski]

+1 stability and debugging first

[Liam]

Jorge Chamorro wrote a native module to allow workers based on threads
and Isolates, and was planning to enable inter-thread communication
via Buffers. The workers don't provide the Node API, just a way to run
CPU-intensive JS out of the main thread.

He didn't release the code publicly, but shared it with a few folks
(including me) and it works.

Jorge?

[Liam]

Turns out he did publish the code

https://github.com/xk/node-threads-a-gogo

[Bruno Jouhier]

Hi Liam,

The project exists but it is just an empty shell. I'm working with
Jorge to package/document and we'll publish soon.

We already published the JASON utility (https://github.com/xk/JASON)
but the threads part is still in the works. Stay tuned...

Bruno

[Liam]

Hey Bruno,

Perhaps post the API summary, and some example code?

You might get some good feedback here as you're polishing it for
release...

Liam

[Liam]

Hey Jorge & Bruno, any progress? Maybe you should just post what
you've got to github...

On Feb 8, 7:35 am, Bruno Jouhier <bjouh...@gmail.com> wrote:

> Hi Liam,
>
> The project exists but it is just an empty shell. I'm working with
> Jorge to package/document and we'll publish soon.
>
> We already published the JASON utility (https://github.com/xk/JASON)
> but the threads part is still in the works. Stay tuned...
>
> Bruno
>
> On Feb 8, 12:21 pm, Liam <networkimp...@gmail.com> wrote:
>
> > Turns out he did publish the code
>
> >https://github.com/xk/node-threads-a-gogo
>
> > On Feb 7, 6:34 pm, Liam <networkimp...@gmail.com> wrote:
>
> > > Jorge Chamorro wrote a native module to allow workers based on threads

> > > andIsolates, and was planning to enable inter-thread communication

[Bruno Jouhier]

Hi Liam,

Jorge is working on it and I'm trying to help with the little time I have. It should show up on GitHub soon. Stay tuned.

Bruno

[Jorge]

For those of you who felt sad like I did when I read this :-/, and just in case you didn't notice yet the other thread "[nodejs] Evil threads [ANN] Threads a GoGo" ;-)

threads_a_gogo is out and ready for you to use: <http://github.com/xk/node-threads-a-gogo>

It lets you create -up to thousands of- JavaScript threads to run JS code in parallel with node's main thread, using all the available cpu cores, in v8 isolates, from within a single node process. It comes with the familiar API that you already know and love from node's asynchronous IO calls, in both event emitter (listeners) and continuation passing (callbacks) styles.

If you've downloaded the version 0.1.0 of threads_a_gogo already, please update now to the latest v0.1.1 that fixes a tiny (32 bytes) leak that was happening when a thread emits an event.

Cheers,
--
Jorge.

[Jorge]

On Mar 13, 2012, at 2:14 PM, Jorge wrote:
> On Feb 3, 2012, at 10:28 PM, Isaac Schlueter wrote:

>> (...)
> (...)

> If you've downloaded the version 0.1.0 of threads_a_gogo already, please update now to the latest v0.1.1 that fixes a tiny (32 bytes) leak that was happening when a thread emits an event.

Please update now to the latest v0.1.2 that (now truly) fixes that tiny (32 bytes) leak.
--
Jorge.

[alFReD NSH]

I have tried threads_a_gogo for something, didn't find anything wrong about it and it's much easier to use than forking or clustering for some cases.

[Jorge]

On Mar 22, 2012, at 3:54 PM, alFReD NSH wrote:
> On Wednesday, 21 March 2012 18:24:13 UTC+8, Jorge wrote:
>>
>> Please update now to the latest v0.1.2 that (now truly) fixes that tiny (32 bytes) leak.
>

> I have tried threads_a_gogo for something, didn't find anything wrong about it and it's much easier to use than forking or clustering for some cases.

I'm glad to hear you say that :-)

I'd love to hear what others' experiences have been.

In my unbiased :-P opinion it's much easier, the code is more readable, runs much faster, and requires less memory (less than 1/4th):

https://gist.github.com/2018811
https://github.com/xk/node-threads-a-gogo/

Cheers,
--
Jorge.

[Andrew Finnell]

Isolates was my last saving grace while doing NodeJS research. I am attempting to do a proof of concept for a product I am working on.

Scenario:

10,000 distinct'ish workers on a single machine. As it stands I'd need to spawn 10,000 separate nodejs instances which amounts to about 300 gigs of memory for a very simple task. I was hoping that Isolates or something similar that could share common memory in some fashion would of alleviated this problem. I could maybe have 200 nodejs clusters that each run 50 internal instances. I do not need to share variables etc across threads or processes. I am very appreciate and understanding of the mailbox/message model for communication between processes. I just need to reduce the handle/memory requirements to something more manageable. 

Of all the workers, the idea is that a single one can go down and I still have all the other ones working. In a typical Java implementation one might create a cluster of a few VM nodes 3-5. Even in this scenario 1 node going down would bring down a substantial number of workers and the memory overhead of running a JVM is too high. 

In a little more detail, lets say I wanted to create a management framework that allowed developers to write their own nodejs applications that could run in the management framework. I might need to spawn 400 instances of App A, 100 of App B, 90 or App C, etc. The separate instances of the Apps do not share state nor need to. The key issue I am facing is that these app's are written independently of each other, thus it makes it difficult to run them all in the same event loop. Too many bad things can happen with differently written apps. 

Any suggestions? I have been looking into Vert.x as an alternative. 

-

Andrew

[Ben Noordhuis]

Isolates wouldn't have helped you. Each isolate has a 5-10 MB memory
footprint so 10,000 isolates need at least 50 GB of memory. Never mind
that all the context switching will likely kill you.

Java or Erlang may work better for you. It's certainly possible to
fire up 10K Java threads but you probably need to tweak the JVM a
little (decrease stack size, that sort of thing.)

[Marak Squires]

If you are looking to spawn 10k worker nodes all on the same machine, you are probably doing it wrong. Try scaling out, instead of up. Maybe node isn't the right choice for what you are trying to do.

As for spawning up several hundred instances of a node.js application, we've put a lot of work into our node application server haibu ( https://github.com/nodejitsu/haibu )

--

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

--

-- 

Marak Squires

Co-founder and Chief Evangelist

Nodejitsu, Inc.

marak....@gmail.com

[Andrew Finnell]

Thank you for the reply,

I did come across your product. So if you put any work into getting Google to bring up your product, it worked.

I cannot use any application management system until I solve the problem of being able to run 10,000 instances of an "app". Ultimately I have control over how these apps are written so I can create a framework in nodejs that was essentially a nodejs fragment. But I like the idea of creating a system that allows one to run the app outside of the system as well as inside of it. In all reality, without writing an app framework, I'll have this same issue in Erland and Java. Spawning 10,000 threads in Java is also unreasonable and smells of a bad design. 

Clustering multiple of these "apps" in a single nodejs isn't out of the issue. But they would have to be agnostic as to which apps are running and I would need to control how many apps run in X number of nodes. I saw threads a gogo and thought this would help but after reviewing it, it solves another issue I was having (CPU intensive calculations). 

I think I may have a design issue to work out first that has nothing to do with NodeJS. I have looked at Erlang before, mostly because that is what RabbitMQ was written in. I really like what nodejs would give me. The ability to write short, event driven I/O applications. That is exactly what I need. It's just a matter of finding a way to run thousands of these.  

The requirements are:

Apps should be code complete. All the code needed to run the app is there (no fragments)

Apps cannot bring down other apps if they crash