Sending multiple http requests on Openshift, finalized only few - node.js

I have build a node.js app for establishing connections with keep-alive, event-stream post request with some external server. I send 400 of them and keep acting on received data using data event from request node package. I also listen to the end, response and error events.
When I run the application from localhost everything works perfectly according to plan. However, when I push it to Openshift, only first 5 requests work as intended, the rest just... disappears. I don't get any error, I don't get any response, nor end. I tried sending the requests in with some delay between them, I tried looking for information about maximum requests, I debugged it thoroughly - nothing works. Does anybody have an idea, basing on this description of the problem, how to make all 400 request work (or have an answer why they won't)?

I found the solution for that problem myself. It appeared, that the Request.js library couldn't establish more connections then 5 due to the default agent.maxSockets property of the http server set to that number in 0.10 version of Node.js. Although I had not been requiring http package directly, the Request.js library used it. All I had to do to fix that was to put the following code in the main application module:
var http = require('http');
http.globalAgent.maxSockets = 500; //Or any other number you want
Btw. the default value has been changed to infinity already in the 0.12 version of Node.js.

Related

Error 503 on Cloud Run for a simple messaging application

I have built a simple Python/Flask app for sending automatic messages in Slack and Telegram after receiving a post request in the form of:
response = requests.post(url='https://my-cool-endpoint.a.run.app/my-app/api/v1.0/',
json={'message': msg_body, 'urgency': urgency, 'app_name': app_name},
auth=(username, password))
, or even a similar curl request. It works well in localhost, as well as a containerized application. However, after deploying it to Cloud Run, the requests keep resulting in the following 503 Error:
POST 503 663 B 10.1 s python-requests/2.24.0 The request failed because either the HTTP response was malformed or connection to the instance had an error.
Does it have anything to do with a Flask timeout or something like that? I really don't understand what is happening, because the response doesn't take (and shouldn't) take more than a few seconds (usually less than 5s).
Thank you all.
--EDIT
Problem solved after thinking about AhmetB reply. I've found that I was setting the host as the public ip address of the SQL instance, and that is not the case when you post it to Cloud Run. For that to work out, you must replace host by unix_socket and then set its path.
Thanks you all! This question is closed.

http concurrent requests to nodejs server giving same response to

while I am requesting two requests(with different login details) to nodejs server concurrently.
first request is waiting for callback. the same time the second request overriding the first request object in nodejs. once I got the response from call back its aplicable to both requests.
It's happens for all services in my nodejs server.
Problem at my side. I did silly mistake
I was created the variables globally, that's why it's overwrite the objects.
Now I made the variable are local, then everything works fine.
Thanks

Heroku H12 Timeout Error with Node.js

Currently, I am working on a REST API using the Node hapijs framework. The API is deployed on Heroku.
There is a GET endpoint in the API that makes a get request to retrieve data from a third party and processes the data before sending a reply. This particular endpoint times out from time to time. When the endpoint times out, Heroku returns an H12 error. Once it has timed out, subsequent requests to that endpoint result in the H12 errors. I have to restart the application on Heroku to get that endpoint working again. No other endpoints in the API are affected in any way by this error and continue to work just fine even after the error has ocurred.
In my debugging process and looking through the logs, it seems that there are times when a response is not returned from the third party API, causing the error.
I've tried the following solutions to try and solve the problem:
I am using the request library to make requests. Hence, I've tried setting a timeout to 5000 ms as part of the options passed in to the request. It has worked at times... the timeout is triggered and the endpoint sends the timeout error associated with request. This is the kind of behavior that I would like, since subsequent requests to the endpoint work. However, there are times when the request timeout is not triggered but Heroku still returns an H12 error (always after 30 seconds, the Heroku default). After that, subsequent requests to that endpoint return the H12 error (also after 30 seconds). It seems that some sort of process gets "stuck" on Heroku and is not terminated until I restart the app.
I've tried adding a timeout to the hapi.js route config object. I get the same results as above.
I've continued doing research and suspect that the issues has to do with the description given here and here. It seems like setting a timeout at the app server level that can send a SIGKILL to the Heroku worker might do the trick. It seems fairly straightforward in Ruby but I cannot find much information on how to do this in Node.
Any insight is greatly appreciated. I am aware that a timeout might occur when making a request to a third party. That is not the issue. The issue is that the endpoint seems to get "stuck" on Heroku after a timeout and it becomes unresponsive.
Thanks for the help!
I had a similar issue and after giving up for a day, I came back to it and found my error. I wasn't sending a response to the client when an error occurred on the server side. Make sure you are returning a response no matter what the result of your server side algorithm is. If there is an error, return that. If the request was successful, return that response. I hope that helps.
If that doesn't help, check heroku's guides on handling Request Timeouts, especially the Debugging request timeouts section could be of help:

intermittent responses with node.js/ socket.io after authorization handshake

Ok I have a WAMP installation with cakePHP under windows xp 64 bit. I am using a websocket PHP pluging with the latest node 8.17 and socket io version .9.13. None of my co workers seem to know what the problem is and i have been stuck for two weeks. I was able to narrow down the problem, but I have no clue on how to fix it.
After my cakephp plugin makes the request to a socket io server i can capture the authorization handshake request however according to the socket io protocol the response body should contain the handhshake id, the heartbeat interval, the timeout interval etc... Sometimes I would get the proper response however the majority of the times(like 90 %) of the time I would get a null body response but the headers return 200 ok response which throws an error in my application. Is there a way I can get consistant results. I am more that happy to post debug information so you can see what I am talking about. I read somewhere that it might be gzip compression problem but with the socket io update i believe that has been fixed.
Any help would be much appreciated!!!
Problem was with line 80 of mgcrea/cake_websocket plugin. For some reason although it was issuing the correct request it was receiving at intermittent response. When i overrode it it then solved the problem.

Accessing inbound HTTP headers in meteor?

I'm working on an application that relies on data that the browser sends within the HTTP headers (and there's no way around this). This also happens to be my first time working with something node.js based, so it's very likely I'm completely missing something simple!
Basically what I want to be able to do is call a method on the server from the client, and in that method read the HTTP headers that the client sent.
Meteor doesn't yet provide a supported API for serving HTTP from your app. This is intentional: in the not-too-distant future, your app server is likely to not be just a single process directly serving end users, but an arbitrarily parallelizable service behind a proxy tier. So we'll need to provide a supported API for responded to HTTP requests (REST, eg) that continues to work in such a setting.
Are you sure it needs to be HTTP and that you can't just use a Meteor method?
If you really need to accept direct HTTP requests now, take a peek at how packages/accounts-oauth-helper/oauth_server.js uses __meteor_bootstrap__.app to hook into the Connect middleware framework. This will work for now, but we don't promise that Meteor will always be powered by Connect :)

Resources