Does anyone know what this problem might be?
{ MongoNetworkError: connection 5 to magicalcreature-shard-00-00-jfi8q.mongodb.net:27017 closed
when I run it on my pc everything's fine, everything's connected. But when I run thru heroku it gives me the error.The code on github is the same except I put process.env.MONGOD instead of the connection string. The connection string looks like this:
mongodb+srv://AlwaysRejected:password#magicalcreature-jfi8q.mongodb.net/test?retryWrites=true
I came into this question while facing the same issue, and while its 4 months old, ill reply with what fixed it for me in case anyone else runs into the same issue.
The problem was that mongodb required a whitelist of ips, and since heroku doesn't use a static ip unless you configure an enterprise private space I had to whitelist all ips using 0.0.0.0/0
Related
I am working on an application that uses an express server to reach out to an API to fetch data. In our organisation outbound traffic requires a proxy which I have supplier to axios like below (not the real one):
let response = await axios.get(endpointUrl, {
proxy: {
host: "123.45.678.90",
port: 0000,
},
})
Passing various URLs into the axios get function returns varied results, with the following URLs returning a result:
https://www.boredapi.com/api/activity
https://api.ipify.org?format=json
https://jsonplaceholder.typicode.com/todos/1
Whereas the following URLs are returning an ECONNRESET error almost instantly:
https://api.publicapis.org/entries
https://randomuser.me/api/
https://reqres.in/api/users
I can't see any pattern between the URLs that are/are not working so wondered if a fresh set of eyes could spot the trait in them? It's important to note that all these URLs return successfully in the browser, just through this axios call being the problem.
To add to the mystery, the URLs that do work work on my machine, do work on a machine outside our organisation - so potentially a clue there?
Any help/guidance of course would be appreciated, thank you.
This error simply means that the other party closed the connection in a way that was probably not normal (or perhaps in a hurry).
For example, a socket connection may be closed by the other party abruptly for various reasons or you may have lost your wifi signal while running your application. You will then see this error/exception on your end.
What could also be the case: at random times, the other side is overloaded and simply kills the connection as a result. If that's the case, depends on what you're connecting to exactly…
Solution - This is happening because you are not listening to/handling the 'error' event. To fix this, you need to implement a listener that can handle such errors.
If the URL that work on your machine also work outside your organization and the other don't, it is most likely a problem with your proxy.
Some proxies might have configurations that makes them remove headers or change the request in a way that the target does not receive it as intended.
I also encountered a problem with axios and proxies once. I had to switch libs to make it work. To be sure, I would recommand using a lib like "request" (deprecated) juste to make sure it is not a problem with axios. There are multiple open issues on the axios repository for proxy issues.
ECONNRESET is likely occurring either because the proxy runs into some sort of error and drops the connection or the target host finds something wrong with the incoming connection and decides to immediately drop it.
That target host may either be finding a problem because of the proxy or it may be expecting something in the request that it finds is missing.
Since you have evidence that all the requests work fine when running from a different location (not through your proxy) and I can confirm that your code works fine from my location (also not running through your proxy), it definitely seems like the evidence points at your proxy as causing some problem in some requests.
One way to debug proxy issues like this is to run a request through the proxy that ends up going to some server you can debug on and see exactly what the proxy has done to the incoming request, compared to a request to that same host that doesn't go through the proxy. That will hopefully highlight some difference that you can then test to see if that's causing the problem and then eventually work on the configuration of the proxy to correct.
Six years ago, (used ws version 0.4.32 now we use 7.2.1 ), I had a great little websocket that ran on http://repl.it and connected a Particle Photon to a webpage with very fast interaction < 10 ms per command. I need to now update my code for Arduinos new github here. The problem is that I don't know what the Arduino should reply to the node websocket to complete the connection. Any suggestions?
This used to work. (Note: I would randomly generate the Sec-WebSocket-Key)
client.println("GET / HTTP/1.1");
client.println("Host: myURL");
client.println("Upgrade: websocket");
client.println("Connection: Upgrade");
client.println("Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==");
client.println("Sec-WebSocket-Version: 13");
client.println();
I am now running my up-to-date index.js on Gitpod.io Everything works, but I am confused with what the Arduino should send to the websocket to start the connection. Does anyone have any ideas?
My webapp uses JSP / JavaScript/ google visualization, and runs on Tomcat 7 on a 64bit windows server with enough resources dedicated to this app.It is still under testing, so, I have control over the load.
The problem is when I work from device at same network of the server, everything works fine. But when I work from device from different network with a request took a long time (more than 6 minutes) I get Service Unavailable [503] message after 6 minutes of waiting while processing in the server is going on and completed successfully. I checked the Tomcat logs but i couldn't find any thing every thing seems to be work fine. I tried different solutions but non of them worked with me:
Increase Tomcat's connector timeout.
Increase the Tomcat RAM.
Disable the server firewall
Try different browsers
Adjust the request timeout from the browser.
I experimented by setting Tomcat's Connector properties in conf/server.xml. I played around with all combinations and ranges of connectionTimeout and keepAliveTimeout.
The final configuration is:
<Connector port="80" protocol="HTTP/1.1"
address="0.0.0.0"
connectionTimeout="3600000"
redirectPort="8443" />
I'm wondering if anybody else has run into such a problem, and how they solved it.
I think you server.xml is having wrong data . Change connector port from 80 to 8080 it always allow four digit and start from 8080 not sure . please update as below
<Connector port="8080" protocol="HTTP/1.1"
address="0.0.0.0"
connectionTimeout="3600000"
redirectPort="8443" />
503 Service Unavailable
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.
Note: The existence of the 503 status code does not imply that a
server must use it when becoming overloaded. Some servers may wish
to simply refuse the connection.click here for more information
let me know if you face any issue
some webdev basic questions for a noob.
background: I have a javascript client that uses the websocket protocol, and a good old java server, which I'm perfectly able to interact with via telnet. I want them to be able to communicate to each other locally (passing strings would suffice).
For that, I definitely don't want to make deep changes in the client. I tried to adapt the server to websocket following this guide before that, and even passed the handshake but it got pretty messy.
So at this point I believe that the best way to deal with this would be to serve through a TCP->WebSocket proxy like websockify. If I got the explanation right, it would "wrap" the server's process, opening the "upgraded" connection in a new port. And the websocket client should be able to directly speak to the server through that port. But I've been trying to implement this with different approaches without success, therefore my questions:
Is there a better way to deal with this problem? (that would explain google's sparseness, I can imagine this happens very often!)
If "wrapping" is the best way and I got it right, how to implement it?
Implementation - edited: For the sake of testing, I've tried to build a simple echo server:
I'm running the very simple command line echo server suggested in this post: ncat -l 2000 -k -c xargs -n1 echo. Talking to it via telnet localhost 2000 returns the desired echo. So far so good.
I installed websockify using apt-get,and run it as follows: websockify 2023: 2000, this should open the same server via a websocket connection on port 2023.
At this point I'm still able to comunicate via telnet localhost 2000, but I'm not having that much luck with port 2023. This is what I tried so far:
Downloaded the telsocket binary, and called ./telsocket -url ws://127.0.0.1:2023. Response: errrr dial tcp 127.0.0.1:2023: connection refused
Cloned wssh (a command line shell for websocket), which seems very promising. I was able to install it, but running wssh -l localhost:2023 returns NameError: name 'PROTOCOL_SSLv3' is not defined. Apparently some problems with gevent (didn't look much further into that).
Tested the several examples in websockify's repo, like wstelnet, or the ones in tests. All of them got me a code 400, message Invalid protocol selected.
Follow-up - edited: Diving deeper into the websock.js and wstelnet.js files, I was able to get more specific results by issuing the following into the JS console:
ws = new Websock()
ws.open("ws://127.0.0.1:2023", "binary") // connects, proxy says: connecting to: :2000, Plain non-SSL (ws://) WebSocket connection, Version hybi-13, base64: 'False'
ws.send_string("hello server") // send and wait for echo
ws.get_rQ() // empty??
So, as you can see, I'm able to establish the connection, but still don't get an echo. The mistake might be as well in the server's side since every tool I tried is failing. Help! D:
Remarks: Since it is intended to work locally, I wouldn't care having either ws or wss. I also don't have a preferred way to do this as long as it is viable and works. In case it is relevant, I'm on Ubuntu15.10 + Firefox47.0
finally, I got the TCP echo server communicating with websockify's websocket telnet emulator through websockify's proxy. This is how:
run the echo server ncat -l 2000 -k -c 'xargs -n1 echo echoServer received'
in a separate process, run the proxy: websockify 2023 :2000
clone the repo: git clone https://github.com/novnc/websockify.git, and make the following changes to wstelnet.js:
3.1 changing the line ws.open(uri) to ws.open(uri, "binary") allowed to overcome the code 400 problem.
3.2 in the definition of do_recv (this is a permalink), add the following line after the initial var statement: arr = Array.from(arr); this is a conversion to Array since Uint8Array didn't apparently support the shift method.
open wstelnet.html with firefox, select Host: localhost, Port: 2023, no encryption, press Connect and type into the black field.
The screen should reply with echoServer received: <YOUR_MESSAGE>. hurray!
Why does my WebSocket connection always closes with 1006 error code, even when I use .close(1000) or .close(3000).
Interestingly, when using the WebSockets connection with Express.js and Express-ws, this does not happen, only when using our real API. Could it be something the server does? Isn't 1006 local only though?
Any help would be appreciated.
Thanks
This answer says:
Close Code 1006 is a special code that means the connection was closed abnormally (locally) by the browser implementation.
If your browser client reports close code 1006, then you should be looking at the websocket.onerror(evt) event for details.
...