My node.js cluster is able to start 2 worker processes and is working fine.
Here is the pseudo code.
But if I open the windows task manager to kill a node.js process, I expected that it'd be restarted. but it threw error (Error: channel closed).
if (cluster.isMaster) {
for (var i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('death', function(worker) {
logger.fatal('worker ' + worker.pid + ' died. Restarting again ...');
cluster.fork();
});
} else {
// Worker processes have a express server.
.........
.........
}
Error:
[2012-03-15 09:46:20.906] [INFO] console - Total CPUs : 2
[2012-03-15 09:46:22.182] [INFO] console - info - 'socket.io started'
[2012-03-15 09:46:22.240] [INFO] console - info - 'socket.io started'
[2012-03-15 12:20:04.973] [FATAL] choicebeat - worker 6928 died. Restarting agai
n ...
[2012-03-15 12:20:05.213] [ERROR] console - Exception in cluster master process:
channel closed
Error: channel closed
at ChildProcess.send (child_process.js:118:33)
at c:\HTML5\LIKEPREF\test\server\node_modules\socket.io-clusterhub\node_modu
les\clusterhub\lib\index.js:150:22
at Array.forEach (native)
at ChildProcess.onmessage (c:\HTML5\LIKEPREF\test\server\node_modules\socket
.io-clusterhub\node_modules\clusterhub\lib\index.js:149:15)
at ChildProcess.emit (events.js:88:20)
at Pipe.onread (child_process.js:102:16)
Looks like something wrong with socket.io-clusterhub. Is it a some kind of configuration error or a bug ?
The issue has been solved in latest clusterhub version 0.1.2
socket.io-clusterhub uses clusterhub internally, so if you update your socket.io-clusterhub, it should work.
Ref: https://github.com/fent/socket.io-clusterhub/issues/1#issuecomment-4538131
Related
I wrapped a module using Electron Packager. Because it has heavy computation, i put it in a sub process that would be forked from renderer.js when user clicks a button on index.html.
Pseudo-code renderer.js from :
let cp = require('child_process');
let subprocess;
function log(msg) {
// A function to log messages sent from subprocess
}
document.querySelector('#create').addEventListener('click', ev => {
subprocess = cp.fork('./subprocess.js');
log('A subprocess has been created with pid: ' + subprocess.pid + ' with exexPath = ' + process.execPath);
subprocess.on('exit', (code, signal) => log(`child process terminated: signal = ${signal} ; code = ${code}`));
subprocess.on('error', log);
subprocess.on('message', log);
});
The real problem is: this subprocess runs smoothly when i call electron ./ from console in working directory, but the build generated by Electron Packager wouldn't.
The subprocess does not show up in Task Manager, or rather, it is terminated as soon as it appears. The log says child process terminated: signal = null ; code = 1.
Although i guarded at the beginning of subprocess.js with this to catch uncaughtException
process.on('uncaughtException', (err) => {
process.send(`Caught exception: ${err}`);
});
Nothing is recorded in log. What should i do to overcome this situation?
System specs:
Window 10
Node 8.6
Electron 1.7.12
Electron Packager 10.1.2
I have experienced this too. One reason i came up with was because the child process will be the child process of electron itself.
In my case, it will not recognize the node modules i defined.
I suggest using spawn with the spawn process being node.exe. But that will not be practical once you build your app.
I am using watson conversation service on node js application.
while trying to push application to bluemix. (through command prompt)
After uploading all the files..
0 of 1 instance running, 1 starting
0 of 1 instance running, 1 starting
0 of 1 instance running, 1 starting
0 of 1 instance running, 1 starting
0 of 1 instance running, 1 crashed
FAILED
Start unsuccessful
Kindly help what's the issue..
command prompt
'My coding
var watson=require('watson-developer-cloud');
var conversation =watson.conversation({
url: 'https://gateway.watsonplatform.net/conversation/api',
username:' ',
password:' ',
version:'v1',
version_date:'2017-06-20'
});
var context={};
context.hour=-1;
function prompt(question,callback){
var stdin=process.stdin,
stdout=process.stdout;
stdin.resume();
stdout.write(question);
stdin.once('data',function(data){
callback(data.toString().trim());
});
}
function tConvert(time){
time=time.toString().match(/^([01]\d2[0-3])(:)([0-5]\d)(:[0-5]\d)?$/)||[time];
if(time.length>1){
time=time.slice(1);
time[5]=+time[0]<12?'AM':'PM';
time[0]=+time[0]%12||12;
}
return time.join('');
}
function convMessage(message){
var d=new Date();
var n=tConvert(d.getHours() + ':' + d.getMinutes() + ':00');
context.hour=(n.split(':'))[0];
context.minute=(n.split(':'))[1];
conversation.message({
workspace_id:'09ee7558-0d3e-4af3-8429-14e60be348d7',
input:{'text':message},
context:context
},function(err,response){
if(err){
console.log('error:',err);
}else {
console.log('Watson: ' + response.output.text[0])
prompt('You: ', function(input){
convMessage(input);
});
context=response.context;
}
});
}
convMessage('Hi.');
Your program might run locally. However, to run as Bluemix Node.js app on Cloud Foundry it needs to meet certain requirement. A web app is expected and the health manager checks on the expected port whether your app is alive. If the app cannot be detected it is considered "dead" and the logs will show it as "crashed".
Take a look at the sample app "Conversation Simple" and the main file "server.js" for how the port info is handled.
As an alternative for your code, you could consider setting a health check type of process. It would indicate Bluemix / Cloud Foundry that you don't deploy a regular (Web) app, but something running in the background or executed once.
So I'm starting out with protractor, and I want to debug my test code:
describe('stuff', function(){
it('should find the specs item, and its empty', function(){
browser.debugger();
gotoHome();
var allItems = element.all('li in model.tags');
var specsDashboardElement;
for (var i=0 ; i < allItems.length; ++i) {
var elem = allItems[i];
var text = elem.findElement(by.css('.li-title').getText()); // does this even work?? dunno
if (text == "Specs")
specsDashboardElement = elem;
}
expect(specsDashboardElement.isDisplayed()).toBe(true);
});
});
I've followed these instructions, but this is the output I see on the node.js debugger console:
D:\src\apps\j1-test.module>protractor debug conf.js
< debugger listening on port 5858
connecting... ok
break in C:\Users\j\AppData\Roaming\npm\node_modules\protractor\lib\cli.js:7
5 * Values from command line options override values from the config.
6 */
7 'use strict';
8
9 // Coffee is required here to enable config files written in coffee-script.
debug> cont
< ------------------------------------
< PID: 9756 (capability: chrome #1)
< ------------------------------------
< debugger listening on port 5858
debug>
and that's it. no matter how many types I type 'cont', nothing happens.
I've tried following the instructions for debugging in WebStorm, with much the same result (output on the WebStorm debug console:
"C:\Program Files\nodejs\node.exe" --debug-brk=2259 C:\Users\j\AppData\Roaming\npm\node_modules\protractor\lib\cli.js
conf.js
debugger listening on port 2259
PID: 2708 (capability: chrome #1)
debugger listening on port 2259
).
I'm using node 0.10.26 (64 bit) on windows 8
Ideas anyone?
That was a Protractor issue, which should be fixed now:
"Fix is in - should be out next release. Thanks for your patience, everyone." - #juliemr
from GitHub issue #552
EDIT: Released in 0.20.0 version! (0.20.1 for Windows users). See Protractor changelog.
I'm trying to run following node js application as mentioned https://github.com/joyent/node/issues/2194
var util = require("util"),
dgram = require("dgram"),
cluster = require('cluster');
var udp = dgram.createSocket("udp4");
var port = 1190;
if (cluster.isMaster) {
for (i = 0; i < 2; i++) {
cluster.fork();
}
} else {
util.log("starting udp server on port " + port);
udp.on("error", function (error) {
util.log("failed to bind to UDP port - " + error)
});
udp.bind(port);
}
The app exits immediately with the following output:
23 May 23:22:13 - starting udp server on port 1190
23 May 23:22:13 - starting udp server on port 1190
events.js:72
throw er; // Unhandled 'error' event
^
Error: write ENOTSUP - cannot write to IPC channel.
at errnoException (child_process.js:980:11)
at ChildProcess.target.send (child_process.js:455:16)
at Worker.send (cluster.js:401:21)
at sendInternalMessage (cluster.js:394:10)
at handleResponse (cluster.js:177:5)
at respond (cluster.js:192:5)
at Object.messageHandler.queryServer (cluster.js:242:5)
at handleMessage (cluster.js:197:32)
at ChildProcess.EventEmitter.emit (events.js:117:20)
at handleMessage (child_process.js:318:10)
Does anyone know what is going on? When running this without cluster, everything is fine.
It seems that cluster does not support udp?
Some specs:
Window 7 x64
node js 0.10.7
It says in the link your provided that support for UDP clustering was added in v0.11.14. It is likely that you simply need to update your version of node.js
I'm trying to debug the child Node.JS process created using:
var child = require('child_process');
child .fork(__dirname + '/task.js');
The problem is that when running in IntelliJ/WebStorm both parent and child process start on the same port.
debugger listening on port 40893
debugger listening on port 40893
So it only debugs the parent process.
Is there any way to set IntelliJ to debug the child process or force it to start on a different port so I can connect it in Remote debug?
Yes. You have to spawn your process in a new port. There is a workaround to debug with clusters, in the same way you can do:
Start your app with the --debug command and then:
var child = require('child_process');
var debug = typeof v8debug === 'object';
if (debug) {
//Set an unused port number.
process.execArgv.push('--debug=' + (40894));
}
child.fork(__dirname + '/task.js');
debugger listening on port 40894
It is a known bug in node.js that has been recently fixed (although not backported to v0.10).
See this issue for more details: https://github.com/joyent/node/issues/5318
There is a workaround where you alter the command-line for each worker process, although the API was not meant to be used this way (the workaround might stop working in the future). Here is the source code from the github issue:
var cluster = require('cluster');
var http = require('http');
if (cluster.isMaster) {
var debug = process.execArgv.indexOf('--debug') !== -1;
cluster.setupMaster({
execArgv: process.execArgv.filter(function(s) { return s !== '--debug' })
});
for (var i = 0; i < 2; ++i) {
if (debug) cluster.settings.execArgv.push('--debug=' + (5859 + i));
cluster.fork();
if (debug) cluster.settings.execArgv.pop();
}
}
else {
var server = http.createServer(function(req, res) {
res.end('OK');
});
server.listen(8000);
}
Quick simple fix ( where using chrome://inspect/#devices )
var child = require('child_process');
child.fork(__dirname + '/task.js',[],{execArgv:['--inspect-brk']});
Then run your app without any --inspect-brk and the main process won't debug but the forked process will and no conflicts.
To stop a fork conflicting when debugging the main process ;
child.fork(__dirname + '/task.js',[],{execArgv:['--inspect=xxxx']});
where xxxx is some port not being used for debugging the main process. Though I haven't managed to easily connect to both at the same time in the debugger even though it reports as listening.
I find that setting the 'execArgv' attribute in the fork func will work:
const child = fork('start.js', [], {
cwd: startPath,
silent: true,
execArgv: ['--inspect=10245'] });
if "process.execArgv" doenst work you have to try:
if (debug) {
process.argv.push('--debug=' + (40894));
}
this worked for me..
There are one more modern way to debug child (or any) process with Chrome DevTools.
Start your app with arg
--inspect
like below:
node --debug=9200 --inspect app/main.js
You will see the message with URL for each child process:
Debugger listening on port 9200.
Warning: This is an experimental feature and could change at any time.
To start debugging, open the following URL in Chrome:
chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:9200/207f2ab6-5700-4fc5-b6d3-c49a4b34a311
Debugger listening on port 9201.
Warning: This is an experimental feature and could change at any time.
To start debugging, open the following URL in Chrome:
chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:9201/97be3351-2ea1-4541-b744-e720188bacfa
Debugger listening on port 9202.
Warning: This is an experimental feature and could change at any time.
To start debugging, open the following URL in Chrome:
chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:9202/8eb8384a-7167-40e9-911a-5a8b902bb8c9
If you want to debug the remote processes, just change the address 127.0.0.1 to your own.