My sails.js app is running under PM2, and I'd like PM2 to be able to restart the app, which it does in the case of a crash. The thing is, when sails fails to load a hook, for instance, if a DB is not available at startup, then the graceful sails.lower() is called internally by sails, but the actual node process does not exit (no process.exit() is called after the lowering) by the core sails code. This has the result of PM2 not knowing that sails has shutdown, and therefore not starting it back up again.
This all happens in the initial bootstrapping of the app, and is before any of my code is called, so I have no control over it.
Does anybody have any suggestions of how I may solve this?
I'm thinking I could write a custom core hook that could hook into the sail.on('lowered', fn) and call a process.exit() on receiving that event. Ideas?
Many thanks.
I've ended up writing a hook to accomplish what I need. The hook listens for the sails.on('lower') (not 'lowered' as the documentation says!!) and waits a configurable time then calls a process.exit() with a configurable exit code.
If anyone else needs it, create the follwoing api/hooks/exitOnLower.js file...
module.exports = function (sails) {
return {
defaults: {
__configKey__: {
name : 'exitOnlower',
wait : 10000,
active: true,
// exitCode : 2
}
},
initialize: function (cb) {
var active = sails.config[this.configKey].active;
var timeout = sails.config[this.configKey].wait;
var exitCode = sails.config[this.configKey].exitCode;
if (!active) {
return cb();
}
sails.on('lower', function () {
sails.log.verbose("[hook:killOnLower] Sails lower detected, exiting in %sms...", timeout);
setTimeout(function () {
sails.log.warn("[hook:killOnLower] exiting app");
process.exit(exitCode ? exitCode : null);
}, timeout)
});
return cb();
}
};
};
Sails doesn't call process.exit when it lowers because the Sails app might have been started programmatically (via sails.lift() or sails.lower()), and exiting the process in this way would quit the script that called Sails as well.
The fact is that Node scripts are supposed to exit automatically when there's nothing left in the event loop. You can verify this yourself by creating a new Sails app with sails new, and creating a test script in that directory like:
/* testscript.js */
var Sails = require('sails');
Sails.load({hooks: {grunt: false, views: false}}, function(err) {
console.log('lifted sails!');
Sails.lower(function(err) {
console.log('lowered sails!');
});
});
Do node testscript.js on the command line and you'll see the two logs, and then the command prompt again.
All this is to demonstrate that if your app is not lowering, it's because something is keeping it from doing so. The most likely thing would be the database adapter. Some adapters (like Postgres) keep TCP connections alive for awhile. If you wait 30 seconds or so you'll likely see the process exit automatically. If 30 seconds is too long to wait, and if you're not calling Sails programmatically, you can certainly call process.exit yourself. You can wait for the lower event, and then give Sails a bit of time to clean up first:
sails.on('lower', function() {
// Give Sails five seconds to shut down before pulling the plug.
setTimeout(
function() { process.exit(1); },
5000
);
});
Put that in your config/bootstrap.js and you should be good to go.
If you want to find out what's actually hanging your process and preventing it from exiting right now, try the excellent why-is-node-running module.
Note: at the time of this posting, the lower event is incorrectly documented on Sailsjs.com as lowered. This will be fixed ASAP.
Related
My Visual Studio code extension allows users to deploy and debug applications on remote devices.
To do this I need to have the application "installed" in a local folder that will then be synchronized to the target using rsync.
Some languages/tools provide a simple and standardized way to do this (ex: dotnet publish, for .NET core apps), others don't.
To be flexible and let users choose the method they prefer, my extension relies on a task with a specific name to perform the operation.
I have a resolveDebugConfiguration function that executes the task and then fills out the information inside debug connection to let user debug his app.
As long as this is a single task, this is not an issue. I can start it using vscode.tasks.executeTask and wait for its completion using OnEndTaskProcess. The task should be shell/process and a non-zero exit code means failure. I also check OnEndTask, to be sure that I don't miss other kinds of completition (ex: an invalid path in the cmd field or the user defined a custom task etc.).
Some users may want to have a more complex structure for this. For example having their deployment tasks depend on a build task, to ensure that the latest version is deployed, or perform additional operations in between, so I no longer have a single task, but a chain of tasks connected via dependson.
This is ok and still works...until it fails.
Or, better, until one of the dependency tasks fail.
In this case, I have no notification from OnEndTaskProcess or even OnEndTask and the tasks after the failed one remain inside vscode.tasks.taskExecutions list forever, it seems.
So my resolveDebugConfiguration function never returns and vscode remains in the "starting debugger" state forever...
My code looks like this:
// retrieve task given its name
const tasks = await vscode.tasks.fetchTasks();
var deploy: vscode.Task | undefined = undefined;
for (var task of tasks) {
switch (task.name) {
case "deploy":
deploy = task;
break;
}
}
if (deploy === undefined) {
// error message telling user that he has to define a task named "deploy"
return null;
}
var emitter = new EventEmitter();
// the process event arrives before the generic terminate one (checked inside vscode sources)
vscode.tasks.onDidEndTaskProcess(e => {
if (e.execution.task.name === "deploy") {
emitter.emit("terminated", e.exitCode);
}
});
vscode.tasks.onDidEndTask(e => {
// check if task is still running, otherwise report an error
var taskexecutions = vscode.tasks.taskExecutions;
for (var taskexecution of taskexecutions) {
if (taskexecution.task.name === "deploy") {
return;
}
}
emitter.emit("terminated", -1);
});
try {
var execution = await vscode.tasks.executeTask(deploy);
}
catch (e) {
// catch execution exceptions and show a message to the user
return null;
}
var code = await new Promise<Number>((resolve, reject) => {
emitter.on("terminated", code => resolve(code));
});
if (code !== 0) {
// deploy task failed
return null;
}
// local deployment succeeded, move on...
Some of the tasks may take a long time, so using a timeout may be a solution worse than the problem.
It would be nice to have OnEndTask called even when a dependency fails, preventing the actual task from running, but this does not seem to happen.
I plan to open an issue on vscode github repo, but maybe someone has a solution that doesn't involves changes to the ide itself.
I am new to OpenUI5/QUnit testing. Sorry for the newbie question.
I have added a very basic async QUnit test into my OpenUI5 project:
QUnit.test( "Test async", function( assert ) {
var done = assert.async();
setTimeout(function() {
assert.ok(true);
done();
});
});
This test passes without errors as expected.
Then I have commented out everything except for
var done = assert.async();
The test runs indefinitely without failing. I would expect that it fails after some timeout.
Pressing the "Abort" button just changes the label to "Aborting" but does not fail the test.
I have search the QUnit documentation, that suggest adding
assert.timeout( 1000 ); // Timeout of 1 second
that should be an equivalent to global setting
QUnit.config.testTimeout( 1000 );
But using either crash my test with
assert.timeout is not a function
or
QUnit.config.testTimeout is not a function
I have tried running the test in Chrome, Firefox and IE11 with the same results.
Can anyone tell me what I am doing wrong?
I have found the answer myself. The correct syntax is:
QUnit.config.testTimeout = 1000;
It is then valid for all the subsequent tests. Alternatively I can write
assert.timeout(1000);
at the beginning of the test method - must be before assert.async()
I am new to protractor-cucumber. I am trying to execute below step definition from protractor conf.js.
this.Given(/^I go to sparqHomePage$/, function (callback) {
homepage.goToHomePage()
homepage.login(data[0].UserName,data[0].Password).then(callback);
});
this.Then(/^I create a process$/, function () {
homepage.clickDesign();
homepage.clickFlowDesigner();
console.log(params.flow.procName + ' '+ params.flow.procDesc);
designPage.createNewProc(params.flow.procName, params.flow.procDesc);
});
this.Then(/^I should see process is saved in db$/, function (callback) {
var sql = "select * from process where name = ?";
sql = mysql.format(sql, params.flow.procName);
console.log(sql);
dbConn.query(sql, function(err, rows, fields){
if(!err) {
procDbObj = rows;
console.log(rows);
expect(procDbObj[0].name).to.eventually.equal( params.flow.procName);
expect(procDbObj[0].description).to.eventually.equal(params.flow.procDesc).and.notify(callback);
}
});
});
As soon as I start the execution, the console log shows, feature file execution was completed, but the actual execution is not yet completed.
In my 3rd step I am doing some db validation based on the step 1 and step 2 actions. As cucumber trying to execute all the steps before the completion of real execution with browser, my 3rd test is always failing.
How can I make cucumber to wait for step execution is completed before moving to the next step.
You are calling
homepage.goToHomePage() and homepage.login(data[0].UserName,data[0].Password).then(callback);. Are both methods correct promises that are correctly handled? It now looks like it is calling both methods but giving a direct callback before resolving the promise.
As Ross stated, you can also chain the promises, but first be sure the promises are correctly handled
Edit:
As Ross stated, you can also chain the promises, but first be sure the promises are correctly handled.
You can also return the promise in stead of the callback, just use it as this
this.Given(/^I go to sparqHomePage$/, function () {
homepage.goToHomePage();
return homepage.login(data[0].UserName,data[0].Password);
});
homepage.goToHomePage()
homepage.login(data[0].UserName,data[0].Password).then(callback);
I'm not sure exactly what is happening in the first line but I assume thats going to be doing a click, you will need to make that return a promise and re-write it like
homepage.goToHomePage().then(()=>{
homepage.login(data[0].UserName,data[0].Password).then(callback);
})
And then follow this pattern for the rest of your code as I can see this same issue throughout
I am new to writing test cases using protractor for non angular application. I wrote a sample test case.Here the browser closes automatically after running test case.How can I prevent this. Here is my code
var submitBtnElm = $('input[data-behavior=saveContribution]');
it('Should Search', function() {
browser.driver.get('http://localhost/enrollments/osda1.html');
browser.driver.findElement(by.id('contributePercentValue')).sendKeys(50);
submitBtnElm.click().then(function() {
});
});
I was also struggling with a similar issue where i had a test case flow where we were interacting with multiple application and when using Protractor the browser was closing after executing one conf.js file. Now when I looked into the previous response it was like adding delay which depends on how quick your next action i performed or it was hit or miss case. Even if we think from debugging perspective most of the user would be performing overnight runs and they would want to have browser active for couple of hours before they analyze the issue. So I started looking into the protractor base code and came across a generic solution which can circumvent this issue, independent of any browser. Currently the solution is specific to requirement that browser should not close after one conf.js file is executed, then could be improved if someone could add a config parameter asking the user whether they want to close the browser after their run.
The browser could be reused for future conf.js file run by using tag --seleniumSessionId in command line.
Solution:
Go to ..\AppData\Roaming\npm\node_modules\protractor\built where your
protractor is installed.
Open driverProvider.js file and go to function quitDriver
Replace return driver.quit() by return 0
As far as my current usage there seems to be no side effect of the code change, will update if I came across any other issue due to this change. Snapshot of code snippet below.
Thanks
Gleeson
Snapshot of code snippet:
Add browser.pause() at the end of your it function. Within the function itself.
I found Gleeson's solution is working, and that really helped me. The solution was...
Go to %APPDATA%Roaming\npm\node_modules\protractor\built\driverProviders\
Find driverProviders.js
Open it in notepad or any other text editor
Find and Replace return driver.Quit() to return 0
Save the file
Restart your tests after that.
I am using
node v8.12.0
npm v6.4.1
protractor v5.4.1
This solution will work, only if you installed npm or protractor globally; if you have installed your npm or protractor locally (in your folder) then, you have to go to your local protractor folder and do the same.
I suggest you to use browser.driver.sleep(500); before your click operation.
See this.
browser.driver.sleep(500);
element(by.css('your button')).click();
browser.driver.sleep(500);
Add a callback function in It block and the browser window doesn't close until you call it.
So perform the action that you need and place the callback at your convenience
var submitBtnElm = $('input[data-behavior=saveContribution]');
it('Should Search', function(callback) {
browser.driver.get('http://localhost/enrollments/osda1.html');
browser.driver.findElement(by.id('contributePercentValue')).sendKeys(50);
submitBtnElm.click().then(function() {
// Have all the logic you need
// Then invoke callback
callback();
});
});
The best way to make browser NOT to close for some time, Use browser.wait(). Inside the wait function write logic for checking either visibilityOf() or invisibilityOf() of an element, which is not visible or it will take time to become invisible on UI. In this case wait() keep on checking the logic until either condition met or timeout reached. You can increase the timeout if you want browser visible more time.
var EC=protractor.ExpectedConditions;
var submitBtnElm = $('input[data-behavior=saveContribution]');
it('Should Search', function() {
browser.driver.get('http://localhost/enrollments/osda1.html');
browser.driver.findElement(by.id('contributePercentValue')).sendKeys(50);
submitBtnElm.click().then(function() {
browser.wait(function(){
EC.invisibilityOf(submitBtnElm).call().then(function(isPresent){
if(isPresent){
return true;
}
});
},20000,'error message');
});
});
I'm sure there is a change triggered on your page by the button click. It might be something as subtle as a class change on an element or as obvious as a <p></p> element with the text "Saved" displayed. What I would do is, after the test, explicitly wait for this change.
[...]
return protractor.browser.wait(function() {
return element(by.cssContainingText('p', 'Saved')).isPresent();
}, 10000);
You could add such a wait mechanism to the afterEach() method of your spec file, so that your tests are separated even without the Protractor Angular implicit waits.
var submitBtnElm = $('input[data-behavior=saveContribution]');
it('Should Search', function() {
browser.driver.get('http://localhost/enrollments/osda1.html');
browser.driver.findElement(by.id('contributePercentValue')).sendKeys(50);
submitBtnElm.click().then(function() {
});
browser.pause(); // it should leave browser alive after test
});
browser.pause() should leave browser alive until you let it go.
#Edit Another approach is to set browser.ignoreSynchronization = true before browser.get(...). Protractor wouldn't wait for Angular loaded and you could use usual element(...) syntax.
Protractor will close browsers, that it created, so an approach that I am using is to start the browser via the webdriver-reuse-session npm package.
DISCLAIMER: I am the author of this package
It is a new package, so let me know if it solves your problem. I am using it with great success.
Hi I having written one simple application which uses the asynchronous socket functions. I am facing some problems while closing the socket.
I am using 5 second timer before calling the async_connect on the socket. In some cases the connection is not happening and timer expires. When timer is expired I am closing the socket tcp_socket.close(). But the thing is my connection callback handler is not at all called with the boost::asio::error::operation_aborted error when i tried to cancel instead of close. The same thing is happening for the next all the async connection invokes.
Eventhough I am closing the tcp socket and destroying the client_session object join() call on the created thread is not coming out means io_service::run() is still running not exiting...:-( I don't know why this is happening... tried lot of other ways still facing the same problem.
I am not getting what is the problem, all suggestions and solutions will be appreciated.
My real code some what look like this.
class client_session
{
public:
client_session(boost::asio::io_service& io_service_ )tcp_socekt_(io_service_),
timer_(io_service_)
{
}
~client_session()
{
tcp_socket_.close();
}
void OnTimerExpired(const boost::system::error_code& err)
{
if( err ) tcp_socket_.close();
}
//Its just for example this will be called from upper layer of my module. giving some information about the server.
void connect()
{
//Here am starting the timer
timer_.expires_from_now(boost::posix_time::seconds(2));
timer_.async_wait(boost::bind(&OutgoingSession::OnTimerExpiry, this,PLACEHLDRS::error));
.......
tcp_socket_.async_connect(iterator->endpoint(), boost::bind( &OutgoingSession::handle_connect, this, _1, iterator));
......
}
void OnConnect(const boost::system::error_code& err)
{
//Cancelling the timer
timer_.cancel();
.....
//Register for write to send the request to server
......
}
private:
tcp::socket tcp_socket_;
deadline_timer timer_;
}
void main()
{
boost::asio::io_service tcp_io_service;
boost::asio::io_service::work tcp_work(tcp_io_service);
boost::thread* worker = new boost::thread(&boost::asio::io_service::run,&tcp_io_service);
client_session* csession = new client_session(tcp_io_service);
csession->connect();
sleep(10);
tcp_io_service.stop();
delete csession;
worker.join(); //Here it not coming out of join because io_service::run() is not exited yet.
cout<<"Termination successfull"<<endl;
}
There seem to be a couple of different things wrong with the posted code. I would suggest starting with smaller steps i.e. along the lines of
start and stop asio worker thread cleanly ( see explanation below )
add code to start timer: handle OnTimerExpired correctly, check error code
add in code for async_connect: when connect handler is called, cancel timer and check error code.
add in other asynchronous operations, etc.
For one, when you cancel the timer in the connect handler, the OnTimerExpired handler will be invoked with boost::asio::operation_aborted and then you close the socket, which is probably not what you want to do.
Further, you give the io_service work, yet still call stop. Generally if you give the io_service work, you want to stop the execution thread by removing the work (e.g. This can be accomplished by means of storing work in a smart pointer and resetting it) and letting the currently started asynchronous operations finish cleanly.