Environment and Prerequisites
There is simply an action to sleep.
routing:demo_home_index
indexAction()
{
sleep(60);
return//...
}
There is an action to load a file.
routing:demo_home_read
public function readAction()
{
$file="/path/to/file/read.txt";
$contents=false;
if(file_exists($file)){
$fp = fopen($file, 'r');
$contents=fgets($fp);
fclose($fp);
}
return new Response(json_encode(array(
'contents' = > $contents,
)));
}
First, access indexAction asynchronously from the UI.
At the same time as the , the process of loading files runs through the interval.
$.ajax({
url —Routing.generate("demo_home_index"),
type: "GET",
dataType: 'json'
})
.done(function(response){
// I don't get 60 seconds back because I sleep.
console.log(response);
});
vartimer = setInterval(function(){
$.ajax({
url —Routing.generate("demo_home_read"),
type: "GET",
dataType: 'json'
})
.done(function(response){
console.log(response);
});
}, 3000);
At this time, the firewall is stuck in the interval every three seconds, or the process of sleeping, or the access at the interval is not completed until the first access indexAction is completed.
Therefore, the interval is accessed periodically, but the entire interval is loaded for 60 seconds, and when the first access and processing (sleep 60 seconds) is completed, all the intervals are accessed sequentially.
Regardless of async, even if you access the page on a separate tab (such as otherAction) while you sleep for 60 seconds, you will be in a loading state and access will be interrupted.
By changing the firewall settings for Symphony 2 itself, etc.,
Is it possible for the firewall to process simultaneously without interruption?
Or are you limiting simultaneous access during processing due to a bundle issue?
At the moment, the cause is unknown.
Thank you for your cooperation.
As you can see, it seems that the file lock in the session is the cause.
If you look at the session_write_close()
page, if you use PHP default file-based session management, the session file will be locked until the end of the script.Therefore, the next request will wait for the lock release for the session file to be written open.
To avoid this, call session_write_close()
when the controller completes the session-related update process.
For Symphony, the equivalent of session_write_close()
is the following code on the controller:
$this->get('session')->save();
Therefore, the verification code for the question is like putting the above code in indexAction()
before sleep()
.
Another solution is to eliminate session blocking by changing to use PDOs, etc., rather than file-based session management.How to Use PdoSessionHandler to Store Sessions in the Database contains a description.
© 2024 OneMinuteCode. All rights reserved.