http concurrent requests to nodejs server giving same response to - node.js

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

Related

Axios and Express: Send a request to Express and get responses in multiple steps

I'm working on a React/Node program. Somewhere in the program, I want to send a request to back-end using Axios, then while the back-end function is processing the request, I want to get step by step responses to update the front-end by showing some notifications.
I could do this by sending multiple requests and waiting for each response. But the problem is that the first process in each step is identically the same in all steps and it will create some performance issues.
My question is:
Is there any way to send a single request to API, then on the back-end side, return the response in multiple steps while it's processing? Meanwhile on the front-end, get the updates from back-end and update the notifications on it?
Thank you very much
Sorry bro, I'm afraid that you can't do this with using HTTP alone since the connection is ended with a single response for a single request. You need to do this with multiple HTTP call with Axios.
Otherwise, you could use WebSocket.
Their are cool Module socket.io with planty examples and documentations.
check this out,
https://www.npmjs.com/package/socket.io

Manage responses of hastily aborted requests

My problem is this:
I have a React Native app that requests data to the backend.
If backend takes longer than x seconds, the app aborts the request (made with fetch()) and tries to make another one.
That abortion was hastily, because the backend was just taking a longer time to process it.
The backend is made idempotent so new requests don't actually matter.
The backend finished processing the initial request, and now it wants to return the value, but that request was aborted by the client.
How should I deal with this?
I can't just abandon the abortion logic because it's not my app, but I can make simple fixes and improve logic on it. Also, I can do whatever it takes in the backend.
I've solved it by saving the express.Response objects alongside it's requests. Whenever a new, duplicate, request arrives I just replace the response object in an array, so that I always have a way to respond the app.

Sending multiple http requests on Openshift, finalized only few

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.

how to tell express.js to queue the requests in a certain order

I am sending requests to a route using express.js
my problem is that i am getting the requests according to the order in which they came to express.
imagine i have a create request which takes very long but i dont care to postpond it, and a get request (to the same route) that takes a very short while.
now imagine i send 3000 create requests (without waiting to responses) and then 1 get request. express is giving me the get request into the server's api only after sending in all the 3000 creations. i want to tell express "hey you, listen, if you got a request which has "get" in its body, place it in the head of the queue and not its tail". this way, express will give me the get request as the next request even that there were 2999 create request comming before it that weren't handled yet.
I tried to do a work queue in the server itself but it didn't solve the issue because the "get" job didn't reach my api at all until I handled many many create requests.
can i do that? if so, how?
Thanks for any help.

In NodeJS, if I don't respond to a request, can anything negative happen to my server?

I have a nodeJS server running. There are some requests that the server will receive that don't need a response (just updating in the server). If the update fails, it isn't something that the client will need to worry about. In order to save bandwidth, I'd like to not respond to said requests. Can not responding to requests somehow affect my server's performance?
Assuming you are using http, You have to at least return an http response code. If you don't you are violating http -- the client is going to wait for a response, and will die trying (i.e. will timeout after a while).
According to the documentation for end, you must call end for every response. That is going to send a response code for you, if you don't specify one. So yes, need to respond.

Resources