[AC-4245] Arrow application build crashes due to timeout during NPM install
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | n/a |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2016-08-31T20:19:14.000+0000 |
Affected Version/s | n/a |
Fix Version/s | n/a |
Components | Arrow Builder |
Labels | n/a |
Reporter | Parijat sahai |
Assignee | Shak Hossain |
Created | 2016-07-26T15:46:57.000+0000 |
Updated | 2016-08-31T20:19:14.000+0000 |
Description
I'm getting the following error frequently during the build:
2016-07-26T11:36:22-04:00 | npm ERR! Linux 3.13.0-88-generic|
2016-07-26T11:36:22-04:00 | npm ERR! node v0.12.4|
2016-07-26T11:36:22-04:00 | npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "i" "--production" "--unsafe-perm"|
2016-07-26T11:36:22-04:00 | npm ERR! npm v2.10.1|
2016-07-26T11:36:22-04:00 | npm ERR! code ECONNRESET|
2016-07-26T11:36:22-04:00 | npm ERR! errno ECONNRESET|
2016-07-26T11:36:22-04:00 | npm ERR! syscall read|
2016-07-26T11:36:22-04:00 | npm ERR! network read ECONNRESET|
2016-07-26T11:36:22-04:00 | npm ERR! network and is related to network connectivity.|
2016-07-26T11:36:22-04:00 | npm ERR! network This is most likely not a problem with npm itself|
2016-07-26T11:36:22-04:00 | npm ERR! network |
Please advise what is going on. After several attempts the build succeeds, so clearly the issue is elsewhere.
Hello, Please provide details of your environment. Also, it would be helpful if you provide a sample code that regenerates the issue. Thanks.
What kind of details? Would the following help?
Please look at the edited description of the ticket. The error I'm now consistently getting during the deployment is that one. Now my app simply won't deploy. Nothing has changed at our end, so it's strange that this issue has come up.
Do you have any status update on this issue? Any workaround or any fix? I just upgraded the Arrow CLI to version 5.3.1 hoping that might resolve the issue but no change - the deployment fails every time at the same place and I really need to get past this issue:
I decided to upgrade the Appcelerator to 5.3.1 and also ran "npm update -g" to bring all modules up to date. Not sure if that caused it, but for some reason, my application successfully deployed this time. That said, the "acs list" and other "acs" CLI commands have stopped working with some node.js error on "form-data" module. I have started to use "appc cloud list" and similar commands as a result. Any ideas?
Well, the deployment errors came back again yesterday and it wouldn't deploy for hours of trying. For some reason, just a few minutes ago, the application successfully deployed. However, the application crashes almost instantly when any API calls are made that cause it to access the ArrowDB database. So, until the ArrowDB issue is resolved, this problem isn't over it seems.
I believe the root cause of at least the initial report of this is CLOUDSRV-4875, as issues with ArrowDB from the queries were bringing down registry server (which would affect logging, in, downloading connectors, and deployments) That has been resolved, so I would be curious to know what the new set of issues are. Do you have an updated stack trace?
I'm also getting the exact same "Failed to install dependencies." error as shown in the second log window of the original report above. No dependency errors are actually reported, and if I re-run the same command several times, eventually it succeeds. See log below:
When you are "running the build" what command are you using? Can I also see a copy of your package.json of your project?
I run "appc publish --force" to build. Contents of package.json are below. {noformat} { "name": "my_arrow", "description": "", "version": "1.0.0", "author": "BG", "license": "", "framework": "none", "keywords": [ "appcelerator", "arrow" ], "repository": {}, "private": true, "dependencies": { "arrowdb": ">=1.0.6", "async": "^1.4.0", "lodash": "^3.10.1", "pkginfo": "^0.3.0", "stripe": "^4.6.0", "validator": "^5.2.0", "twilio": "^2.9.1", "request": "^2.72.0", "sendgrid": "^3.0.7", "handlebars": "^4.0.5", "juice": "^2.0.0", "moment": "^2.13.0", "csprng": "^0.1.1" }, "devDependencies": { "grunt": "^0.4.5", "grunt-contrib-clean": "^0.6.0", "grunt-contrib-jshint": "^0.10.0", "grunt-kahvesi": "^0.1.0", "grunt-mocha-test": "^0.11.0", "mocha": "^1.21.4", "should": "^4.0.4" }, "main": "app.js", "healthCheck": true, "engines": { "node": "0.12.7" } } {noformat}
I'm using the same command as what Barry mentioned. My package.json is the following:
Btw, I find it really odd that issues with ArrowDB would affect registry server at Appcelerator - how lean are you running your operations that you can't have separate servers and redundancy and failover for ANY of your servers? Unbelievable and highly unprofessional I must say!
I disagree. We specifically run our infrastructure on the same infrastructure as our public customers as a point of pride. Customers are welcome to purchase a VPC for themselves if they like, but typically they do that for organizational reasons. We certainly could set one up for ourselves, but we specifically choose not to. We also have multiple servers for redundancy, but the issue here was separate and appears to be due to a bug in MongoDB code.
This is a NPM issue. You can get a similar thing to happen by just doing a
npm install arrow --loglevel verbose
However, there is still some work around figuring what is triggering it and how to stop it. We will work on that ASAP.If what you're saying is correct, then I have to assume that EVERY customer of Appcelerator has been impacted by this MongoDB bug. If there are any mission-critical applications being run by your customers, I would expect that either your customers would be fleeing from Appcelerator by now or screaming like crazy because it has been more than 4 days since the issue arose. If neither of that has happened, then it seems no customer trusts Appcelerator's public infrastructure enough to run their mission-critical applications and probably only run peripheral applications that go unnoticed when they are down for such an extended amount of time. Hence, Appcelerator cannot pride itself about its infrastructure being able to support mission-critical applications on their cloud. And blaming the outage on a third-party software doesn't help - it should have been tested by Appcelerator before deploying on their public cloud and, for the worst case scenario, Appcelerator should have done rollback planning in the case things go horribly wrong, which is what happened here. Clearly, contingency planning wasn't done and customers are now being asked to wait patiently during the 100+ hour outage - give me a break!
[~parijatsahai] I don't believe it's a fruitful exercise to go down this path. You are more than welcome to contact support if you have additional questions. My point initially was to say I believe we've addressed the first issue and not lead down a complete explanation of our operations practices. We take all of our customer's applications very seriously. I will only say that we have many enterprise customers both on public cloud and VPC. Once we were able to identify the issue, we immediately restored service to all public cloud users (VPC users are unaffected). I understand a percentage of users are affected by this issue related to the bug I mentioned (which is related to a very specific use case) and we are addressing those ASAP.
This ticket has been cloned and moved to API-1325 to see what we can do to address the issue.
You said "we immediately restored service to all public cloud users". However, our application continues to get ArrowDB errors "503 Service Unavailable. No server is available to handle this request." - clearly the ArrowDB service hasn't been restored in over 4 days now. Thanks for acknowledging and reproducing the issue with the build. Hopefully we will have a quick resolution. I'm still at a loss to understand why only 2 customers have reported this issue and how I'm the first one to do that - it would impact either ALL or NONE of the customers - there probably aren't many Arrow customers, are there? If you put yourself in my shoes, you'd understand how scary this looks.
The build issue is intermittent. NPMJS has many, many registries. It does not seem to affect everyone all the time. You could have cached the dependencies in your .npm folder, meaning that you wouldn't redownload them. There are a lot of variables that affect this, which is why not everyone would encounter it. http://status.npmjs.org/
Hello, [~parijatsahai], are you still having the issue?
The issue with timeout was resolved after we changed the Node engine version on the Arrow app's package.json file to 4.x.