In my application I have 2 ajax requests that are fired almost simultaneously. The first one need a long time to execute and it block the second request from executing (the 1st request lock the session).
I found a way to solve the problem in PHP using session_write_close(), but Laravel file sessions seem to work differently and session_write_close() not works. Is there another way to solve this problem?
The first one need a long time to execute and it block the second request from executing.
@insurdev Put long-running processes on a queue and handle them using a queue worker. Clients shouldn’t be waiting for a HTTP response while your server’s churning through whatever process.
I found a way to solve the problem in PHP using session_write_close(), but Laravel file sessions seem to work differently and session_write_close() not works. Is there another way to solve this problem?
AJAX requests are typically made to API endpoints, which are usually stateless, so you’d identify the authenticated user using an access token of some sort and not the session.
@martinbean I can't put all ajax requests in queues, not always every request take time to response because it depends on external API services that we use. Our API ajax requests makes curl requests to another API services, so simetime happens that curl request take time to response and freeze all subsequent ajax requests). I've read about the session_write_close() but in laravel not works. Have you any other idea?
I can't put all ajax requests in queues, not always every request take time to response because it depends on external API services that we use. Our API ajax requests makes curl requests to another API services, so simetime happens that curl request take time to response and freeze all subsequent ajax requests). I've read about the session_write_close() but in laravel not works. Have you any other idea?
@insurdev What you have described are all reasons to use a queue.
If the code the AJAX endpoint relies on an external API service, then you want that interaction queue in case the external service is down so you can retry.
If the external service is under heavy load and takes a long time to return responses, then your endpoint is also going to take a long time to return a response. If the work is pushed to a queue, your endpoint can return a response quickly and let the work be done in the background.
You’re right: cURL (and all network requests) do take time. So to stop “freezing” the rest of your application, put work you can on a queue and let your AJAX endpoints return as quickly as possible.
These requests you’re making to AJAX endpoints are obviously doing some sort of process. It’s those processes I suggested making queued jobs from; not the actual sending of AJAX requests themselves.
The controller that is being hit by AJAX should dispatch a job to a queue and then return a response going, “Yeah, I’ve queued that.” You can then use broadcasting to notify your front-end when that task has completed.
The above approach will make your application a lot more responsive as well as resilient to adverse network conditions (external service down, external service slow, etc).
@martinbean forgive me, I've used the following code:
dispatch(new \App\Jobs\TestJob()) and putting in the handle() function the curl request to other API service.
I've tried to execute the artisan queue:work, the job was processed, but I don't know how turn back the data to the ajax request.
Can you give me some example please?
@martinbean is this the only solution? it seems to be really complicated method. I supposed in your previous answer that queue could solve my problem with ajax calls without using broadcasting too. Isn't it?
is this the only solution? it seems to be really complicated method. I supposed in your previous answer that queue could solve my problem with ajax calls without using broadcasting too. Isn't it?
@insurdev If you push something to a queue then you need some way to indicate the queue job has finished. As the AJAX endpoint will protentially be returning a response (“That’s been queued”) before the queue job has been processed.
So if you’re returned a response before the job’s finished, how is the user on the front-end going to know when it’s done if you don’t tell them?
It might seem “complicated”, but it’s the solution to your problem. You can’t just have AJAX endpoints hanging around for an indeterminate length of time, waiting on an upstream service. When I request to download a 10 GB file from my Google Drive account, the browser doesn’t lock up for however long it takes to stream that file. It sends the request off, and I then get an alert a few moments later when the file’s ready to download.
