proxy error econnrefused grunt - javascript

I have ran into a problem when running through grunt.
I get a proxy error: Econnrefused when running grunt serve.
I ran --verbose too and it looks like the request is getting blocked. I think it could be related to my organisations network setup but don't know this for sure.
The web page loads but has no data etc in.
grunt serve --verbose output
can anyone help please?
thanks,

Figured out what this was....the second server wasn't starting correctly so the proxy had nothing to connect to. Running maven was the cause of the issues.

Related

when self-hosted Sentry, should I run ./install.sh everytime after I restart my computer?

So sorry, my English is so poor,hope you can understand what i mean。
I follow the documentation build self-hosted sentry:https://develop.sentry.dev/self-hosted/
It works before I restart my computer.
now, I sent Error to my service but dashboard not show my error.
I guess, my docker configuration occur some problems。
This time I only run docker-compose up -d
Not run ./install.sh
should i run ./install.sh everytime?
I have been looking for problems for a long time, but they haven't been solved. please help me.
After many experiments, it is found that:
Generally speaking, run it once. However, when the docker status is abnormal. Rerun can solve many unexpected problems

Error pushing React app to Heroku - "remote rejected main-> main (pre-reseive hook declined)"

I'm gettig this very frustrating erro while trying to push my React app to Heroku. I was able to push it up with no problem in the application's earlier development, but for some reason it now gives me the same error message all the time:
! [remote rejected] main -> main (pre-receive hook declined) error: failed to push some refs to 'https://git.heroku.com/sapient-origin-alpha.git'
The only thing I can think of is that there is some issue with the version of react I'm using (I tried react 18 and 17, both gave the same results). But again, I was able to push it up before with no problem so I'm not sure. My other thought was that it's the client-side package.json since it's saying the build is failing.
Another thing worth mentioning is that I re-named the Heroku app, but afterwards I removed my local git remote and created a new git remote with the updated Heroku app name. So maybe this had something to do with it? This is basically what I did:
*rename heroku app*
$ git remote rm heroku
$ heroku git:remote -a sapient-origin-alpha
If anyone is able to help me on this I would very greatly appreciate it.
Nevermind I'm just dumb. It literally told me what was wrong in the error message slightly above the text in the image I provided.
The problem was in the client-side package.json because of some dependency I was using. Make sure to double check your package.json file for things that could be causing a similar error, and delete your package-lock.json then run npm i again to refresh the file.

Meteor server crashes very frequently without any error

I am working with the Meteor application and I deployed the same over EC2 instance. It was working fine till a few days back.
But now the server process kill automatically without any error log or
console
I tried to get the error but unfortunately, as there are not any logs I am unable to find out why the server is crashing again and again.
I have a medium EC2 machine on which the application is running.
I am using nohup for running the application in the background.
Below is the command I used to start the server:-
nohup meteor --settings SETTINGS-PRODUCTION.JSON &
I am wondering to know about server crashes due to nohup or some other reason is there.
Please let me know how we can console uncaught exception in the meteor-like we do in express.
What should I use to auto restart the server if the process is killed
by any error or exception?
Any help would be much appreciated!
Thanks
Using nohup is quite a low-tech solution. Things like Phusion Passenger, PM2, or forever do a better job.
Also your docker container can be configured to automatically restart the process.
Even better is a tool called Meteor Up, which makes it really simple to deploy Meteor apps to EC2.
EASILY DEPLOY YOUR APP Meteor Up is a production quality Meteor app
deployment tool.
Install with one command:
$ npm install --global mup
http://meteor-up.com/

WebStorm keeps crashing my locally ran server because of Git's index.lock

Error: EPERM: operation not permitted, lstat 'C:\ProjectDirectory\.git\index.lock'
at Error (native)
I'm using WebStorm and everytime I run the local server for testing purposes using npm start, it crashes inevitably sometimes after doing nothing, and sometimes after making a change or so.
I'm using this React boilerplate and the actual author responded to a bug issue I brought up about this saying "Based on the error, it looks like either your editor or your source control system is locking files."
I'm a bit tired restarting the server every time I make a couple changes and would love to fix this.
Full error log
Only IDE have reason to watch .git/ folder. So if something else tries then it's a bug in configuration.
npm start is an alias for npm-run-all --parallel test:watch open:src lint:watch.
Make sure that .git/ is exempted in their configuration.

Why is the error happening?

I'm following this tutorial Full-stack Redux Tutorial and everything went well till the moment I had to run a local server (Starting under the title "Setting Up a Socket.io Server"). I copied exactly what the tutorial shows and I'm getting this error when running "npm run start"
As seen in the image, the command I'm trying to run is:
babel-node index.js
But the error says nothing I can catch, just that something is wrong with the command, not even with a file.
I'm lost and Google offers little help.
Something else is listening on port 3333 on your machine. Change the port number to something else, and it should work.
If you told us what OS you were using, we could suggest how to determine what is listening on port 3333.
It seems like there's still a connection open on port 3333. If you open cmd and run netstat -a -b you should be able to get a list of open connections together with the executables that started them.
It might be that your Socket.io server previously crashed and the exception wasn't handled properly, possibly leaving the connection open?

Categories