I set up a new EC2/Node instance via the Elastic Beanstalk console, but I'm unable to upgrade NodeJS as the button is grayed out.
I tried changing the version of NodeJS in the configuration section, but it didn't upgrade it. In the past either of the options have worked, but I'm not sure why the button is grayed out? I've also tried deploying a sample application and other (supported) versions of NodeJS in the config. I've tried restarting and rebuilding the environment with the new config, but it defaults to Node v4.3.0.
Has anyone encountered this? Am I missing something here? Thanks!
EDIT: This guide states that the option to change configuration is available only when a new compatible version of the platform is available. However, I'm interested in updating NodeJS and not the overall OS.
Those are 2 different things, v4.3.0 (in first image), is the version of the Amazon Linux OS. Is not related to node.
The second image shows the node version you are using (6.10.0). You can tweak that in the config dialog
Related
this is my first question ever. I'm trying to run an Adonis.js app by entering adonis serve --dev at the terminal. The messages are always the same in this succession:
SERVER STARTED
Watching files for changes...
Fatal error in , line 0
Check failed: U_SUCCESS(status).
FailureMessage Object: 000000D7655ECBA0Application crashed, make sure to kill all related running process, fix the issue and re-run the app
The only thing that changes is the FailureMessageObject. My Node version is 12.0, npm 6.9.
I can't say anything seriously working on your situation cause you gave me no detailed data but I know that surely you are doing something wrong.
It could be better if you at least mentioned the version of adonisjs you've been using.
Anyway, if you learned to run your server from a video from someone else's youtube channel, I strongly recommend you to read documentation and stop watching those videos.
And for adonisjs there are 2 different documentation:
adonisjs's Documentation, version 4.1 or less.
You can change the version on top left combo box.
adonisjs's preview Documentation, version 5.0.
Actually the documentation is not still completed at this time but the version is stable. yeah, that's the reason why I wrote preview.
And that's it, start recreating an adonisjs app from documentation guides.
I solved it. It was something with node or npm. I followed this steps enumerated in this post: How to completely remove node.js from Windows. Reinstalled node. Installed Adonis and it's CLI again and created an app and this time the app didn't crashed, and ran smoothly (after that I also created some migrations and they too worked well).
I'm relying on Node version 12.17.x to make use of a specific feature (AsyncLocalStorage) in Lambda and Elasticbeanstalk. But for some reason, the Node.js version does not seem to publicly available. Why do they think that platform "12.x" tells me the real Node version? I want to know the exact minor and patch version, or at least give some news about it...
I had to create a test lambda function that prints process.version, but surprisingly, platform 12.x still uses v12.16. When will they upgrade to the latest stable version that came out more than 2 weeks ago? Are they publishing those releases somewhere? Google tells me nothing useful.
The same applies to Elasticbeanstalk instances. Node v12.17 does not exist in /opt/elasticbeanstalk/node-install/*
I've just checked in our sentry and the current version is newer-v12.18.4 so you can safely use AsyncLocalStorage now on v12 lambdas.
But AWS should really show this in the lambda administration panel. The fact that this is not shown anywhere and we have to use console logs or third party tools to get this info is a very poor DX.
I have a old Node.js application that I need to rebuild it to run it using my current Node installed. I have the node_modules folder. However, I cannot figures it was created using what version of Node. I searched for the term 'engine', but I had not success. Any ideas would be greatly appreciated.
The engines property can be used to define which versions of Node your application can run on, but it is optional. Without it, there is no way of knowing what version on Node the app was developed on. You could have switched Node versions during development and if there were no breaking changes, the application would have no idea.
Something you could try to do is look at the dependencies in your node_modules/ folder - if the dependencies are the same versions that you installed when originally developing, they might have engines properties in their package.json files that you could look at and piece together a picture of what Node version the application was developed for.
If you are trying to update the app to use a modern Node version, an easy way forward is to simply run the app, see what breaks, look up documentation to see what has changed between versions, and update your code until it works as expected.
TL;DR - There is no definitive way of knowing what the Node version was when the app was developed, unless it was documented by the developer.
Despite re-deploying and even disabling/re-enabling the application Google App Engine keeps trying to run the npm start script from an old version of the app. I noticed this because it used to try to run a migration script, then start the server. Now the migration script errors, which is what got my attention.
I've since tried to also update the version number in the package.json since the logs that are failing specified it was trying to run version 1.0.0 of my app. So I figured maybe I need to bump the version.
Despite that, the log that errors still says PROJECT_NAME#1.0.0 start: npm run migrate && node src/server.js which is clearly the old one.
I started a project on Node.js Flexible environment for Google App Engine, then switched to Standard environment (which was released shortly after I started the project). I'm speculating that perhaps it's trying to run flexible environment script too? But, I don't know how to make it stop.
Oh, one more important detail: The app is running and working despite supposedly erroring on startup. So it definitely seems like it's trying to run both versions and only one is succeeding.
It turns out there was an old instance running in the "flexible" environment.
Deploying a new "default" service running in "standard" environment does not seem to stop other deployed versions in the "flexible" environment.
The fix involved opening Google's Cloud Console for App Engine, clicking "versions" and finding/stopping/deleting the old versions from "flexible" environment.
Huge thanks to #Steren for helping me figure out what was going on.
I've been trying to work through an issue that developed while attempting to upgrade our testing environment from 12.04 to 14.04 ubuntu on aws. Prior to this, the Package repository version of solr was 1.4.1 which matched our 1.4.1 solrj client integrated with our application.
Changing the base AMI to the 14.04 latest and running our default deploy caused solr 3.6.2 server to be installed. It appears it was accepting our configs without issue, however when our client tried to connect we received different errors:
The first was an unknown custom field, which we traced back to our deployment scripts not moving our schema.xml and solrconfig.xml to /etc/solr/conf/ but keeping it in the base directory.
We corrected this issue, and then ran into the following:
'exception: Invalid version or the data in not in 'javabin' format'
This was generated by a wrapper ontop of solrj, but I'll be honest and say I know nothing regarding Solr and that this may be on our end. I've asked our dev team to look at 2 options:
1) enabling: 'server.setParser(new XMLResponseParser());'
Which is the recommendation on the backwards compatibility for an older client.
2) updating our client in the application to 3.6.2
-I know less about the requirements on this.
My fall back is to revert to 1.4.1, but it appears it hasn't been touched since 2011, which makes me hesitant.
Any thoughts / suggestions would be appreciated!
Thanks!
I think the best option is to maintain the same version of Solr and Solrj.
I used for a lot of time Solr 1.4.1 and, while as you said, the most part of it works with newer versions without any problem, actually a lot of things have been changed since 1.4.*
I did your same porting last year, (from 1.4.1 to 3.6.1) and I can confirm you that the 2nd way is the right one: all changes you must do in your client code are just "formal" and very very quick.
Any workaround you could do for being able to communicate with a different version (between Solrj and Solr) is just, as the word says, a "workaround" and it could lead to unexpected (hidden) side-effects later.