· Jan 10

Handling multiple API request

Hello Guys,

Our cache application uses REST web services and handles single API request perfectly with response (response status and related data). But sometimes user sends multiple requests to the same API simultaneously ( ie, without waiting for the first to respond ), where one request will succeed (not necessarily the first) and the others will fail. 

So, I need to handle the requests one by one after completing and sending the response for first request in the queue then process the next request and so on.

Is there any appropriate way of handling this problem? 

I found that, cache supports multiple-threading from this discussion but not too sure how to implement it correctly in my case.

I tried using JOB but I need to respond for the first request with response data before processing next request which seems inappropriate and also tried Work Queue Manager, which also seems irrelevant for me.

How do I implement any of these or any other way correctly when multiple requests are made by a user to the same API? 

Any help would be highly appreciated.

Product version: Caché 2018.1
$ZV: Cache for Windows (x86-64) 2018.1.5 (Build 659) Mon Mar 22 2021 07:15:21 EDT
Discussion (4)2
Log in or sign up to continue

While using JOB command, I think it was timeout on the Postman and it was still running in the server filling up my logs rapidly until I restarted the Cache server but that could be because of the code issue.

But the problem for me was, even though user sends multiple requests simultaneously the API endpoint will process them one by one and the first request needs to be responded before processing the second. Since, JOB runs in the background, I was not able to reply the response data for each request. 

Similarly, while implementing Work Queue Manager, I don't have the list of requests and cannot collect them in one place and process one by one with response back to each request.

 Or I may be complicating things here and identifying the request from the same user and waiting until the previous request completes would just be a perfect solution for me?

I had a similar problem where api calls could take up too much time to immediately respond.

So i immediately return as a response just a queryid (incremental number), which the user can use in a separate call to get the status, and in a separate call to get the results when the status is 'finished'.

Each call to the query api is stored in a table with the incremental queryid, the request and status='queued').
I have a job that will look at the next 'queued' request in the table that needs to be processed, set the status to 'in process', process the query, change the status in the table to 'finished' (and also store the results in the table).

So each query is processed one by one, and 'users' have to wait and use the status call to check when their query is processed. I also have a purge function that will delete processed queries after 14 days (so users can get the results within this period).

The api call that returns the next queryid will check if the background job is running to process the queue, if it is not running, it will job it. I also have put this method in the %ZSTART so it is started when Caché/Iris starts.
The background job in a loop process the queries, and will hang for a minute if there is nothing to do. (There are also ways in Caché/Iris to let the job 'sleep' and 'wake up'.)