I would like to know if it is possible to differentiate the initiation time of a request in the milliseconds area.
Say I have 2 users that make a request at 40ms interval. Is they a way to know server-side the exact time of the initiation of the requests ?
According to me, using Http would mean there's no way to know exactly which request was initiated first. Maybe using websocket ? (My project is a website project)
Related
My Api to Update Product Details sends 4000 requests at once and waits for a minute and then shows timedout error . please suggest me a good way to handle this issue.
Whatever the target is that you're sending these 4000 requests to at once apparently cannot handle that many requests all in flight at the same time and still respond to each request in a timely fashion. This is not surprising.
The usual solution to something like this would be to limit how many simultaneous requests you send to the target to something smaller like 10 or 20 (usually determined with testing). You send 10 requests, then each time a request finishes, you send the next one in line. This way, you never over tax the target server.
You can hand-code code to distribute requests as described above or you can use a pre-built function to do that like Bluebirds Promise.map() or a function like mapConcurrent() and you can see a discussion of this general issue here.
I have a process in the back-end which will take take on average 30 to 90 seconds to complete.
Is it better to have a font-end react app make ONE API call and wait for back-end to complete and process and return the data. Or is it better to have the front-end make multiple calls, lets say every 2 seconds to check if the process and complete and get back the result?
Both are valid approaches. You could also report status changes with websocket so there's no need for polling.
If you do want to go the polling route, the general recommendation is to:
Return 202 accepted from your long-running process endpoint.
Also return a Link header with a url to where the status of the process can be read.
The client can then follow that client and ping it every x seconds.
I think it's not good to make a single API call and wait for 30-90 seconds to get a response. Instead send a response immediately mentioning that the request is successful and would be processed.
Now you can use web sockets or library like socket.io so that the server can communicate directly to the client once the requested processing is complete.
The multiple API calls to check if server is done or server has any new message is called polling and is not much efficient but it is still required in old browsers which don't support web sockets. Socket.io support s polling automatically in old browsers.
But, yes if you want you can do multiple calls to check if server is done processing, but I would prefer server to communicate back to the client , it is better.
Best way to respond restfully to a time consuming calculation (Node.js with Express)
I'm building a REST API using Node.js with Express.
Now I have to design the response to a time consuming calculation on the server side to a http request witch is ending up in a zip file with a few megabytes.
The calculation is done in a few seconds at the moment. But perhaps, if data grows up, it can take minutes sometime. So I think it's not the best way to wait in Express till data is ready and then res.sendfile() it back to the client. But what is the best solution?
Should I implement a delayed response with long polling? Like http-delayed-response
What I don't like here is that I immediately have to report HTTP 202. If the generation of the ZIP file fails, I have to deal with this in the response and cannot report it via HTTP status code. Also I cannot respond the file directly - as far as I know.
Or something with job ids and states to each job? Like express-delayed-response
In this way my API is not stateless anymore and I have to build a status handler.
Are there better and more established solutions to this problem?
I want to track service calls for security reasons into database and I need to generate reports above them. I don't know what is the best way, using soap handlers, using database loggers or something else but I know that performance is very important for me.
Any Idea?
P.S javaee
Depending on the traffic amount you get on your web services, it might not be a good idea to make a database write per request. Instead what you should do is make some kind of a listener that is triggered each time a ws request comes in, to which you'd pass the request itself, and then that listener will cache back several reports based on those requests, and then write them all to the db at certain intervals (like every 10 minutes, each night at 3 a.m., etc)
I have a java based web application(struts 1.2). I have a requirement to display a status on the frontend (jsp). Now the status might change which my server gets notified by another server. But I want this status change to be notified to the browser.
I don't want to make a refresh at intervals. Rather I have to implement something like done in gmail chat, ie. the browser gets notified by changing events on the server.
Any ideas on how to go about this?
I was thinking on lines of opening a request to server for status, and at the server end I would hold the request and wouldn't respond back until there is a status change. Any pointers, examples on this?
Best possible solution will be to make use of XMPP protocol. It's standardized and a lot of open source solutions will get you started within minutes. You can use combination of Smack, StropheJS and Openfire to get your java based app work as desired.
There's a method called Long Polling (Comet). It basically sends a request to the server. The request thread created on the server simply waits for new data for the user, with a time limit of maybe 1 minute or more. When new data is available it is returned.
The main problem is to tackle the server-side issue, you don't want to have one thread for every user just waiting for new data. Of course you could use some asynchronous methods depending on your back-end.
Ref: http://en.wikipedia.org/wiki/Push_technology
Alternative way would be to use WebSockets. The problem is that it's not supported by all browsers today.