On the rewritten Batch Manager Unit Mode for version 15, instead of a single form validated by a full page submission, Piwigo calls pwg.images.setInfo for each modified photo. All calls are made in parallel, which is a bad idea and is the subject of #2329
One problem is that each call to pwg.images.setInfo triggers a user_cache build and ends with a user_cache reset. Considering other simultaneous requests to pwg.images.setInfo, at one point several calls ends in a timeout. Here is how it goes:
[t0] requestA starts to generate user_cache
[t0+1ms] requestB waits for A to finish generating user_cache
[t0+2ms] requestC waits for A to finish generating user_cache
[t0+1ms+1s] requestB checks if the user_cache has been rebuilt, answer is no, so it continues to wait
[t0+2ms+1s] requestC checks if the user_cache has been rebuilt, answer is no, so it continues to wait
[to+1.5s] requestA finishes to rebuild user_cache, perform the image info update, immediately deletes user_cache and sends a response
[t0+1ms+2s] requestB checks if the user_cache has been rebuilt, answer is no, so it continues to wait
[t0+2ms+2s] requestC checks if the user_cache has been rebuilt, answer is no, so it continues to wait
...
[t0+1ms+10s] requestB checks if the user_cache has been rebuilt, answer is no, times out => request has failed
[t0+2ms+10s] requestC checks if the user_cache has been rebuilt, answer is no, times out => request has failed
After [t0+1.5s], for requestB and requestC, instead of only checking if the user_cache has been rebuilt, we should also that the user_cache is still being rebuilt. Because if it isn't, we should restart to try to build it instead of waiting for nothing.
See https://fr.piwigo.org/forum/viewtopic.php?id=30704 or https://piwigo.org/forum/viewtopic.php?id=34180
On the rewritten Batch Manager Unit Mode for version 15, instead of a single form validated by a full page submission, Piwigo calls `pwg.images.setInfo` for each modified photo. All calls are made in parallel, which is a bad idea and is the subject of #2329
One problem is that each call to `pwg.images.setInfo` triggers a user_cache build and ends with a user_cache reset. Considering other simultaneous requests to `pwg.images.setInfo`, at one point several calls ends in a timeout. Here is how it goes:
[t0] requestA starts to generate user_cache
[t0+1ms] requestB waits for A to finish generating user_cache
[t0+2ms] requestC waits for A to finish generating user_cache
[t0+1ms+1s] requestB checks if the user_cache has been rebuilt, answer is no, so it continues to wait
[t0+2ms+1s] requestC checks if the user_cache has been rebuilt, answer is no, so it continues to wait
[to+1.5s] requestA finishes to rebuild user_cache, perform the image info update, immediately deletes user_cache and sends a response
[t0+1ms+2s] requestB checks if the user_cache has been rebuilt, answer is no, so it continues to wait
[t0+2ms+2s] requestC checks if the user_cache has been rebuilt, answer is no, so it continues to wait
...
[t0+1ms+10s] requestB checks if the user_cache has been rebuilt, answer is no, times out => request has failed
[t0+2ms+10s] requestC checks if the user_cache has been rebuilt, answer is no, times out => request has failed
After [t0+1.5s], for requestB and requestC, instead of only checking if the user_cache has been rebuilt, we should also that the user_cache is still being rebuilt. Because if it isn't, we should restart to try to build it instead of waiting for nothing.
<!-- github-sync-id:2888813089 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
See https://fr.piwigo.org/forum/viewtopic.php?id=30704 or https://piwigo.org/forum/viewtopic.php?id=34180
On the rewritten Batch Manager Unit Mode for version 15, instead of a single form validated by a full page submission, Piwigo calls
pwg.images.setInfofor each modified photo. All calls are made in parallel, which is a bad idea and is the subject of #2329One problem is that each call to
pwg.images.setInfotriggers a user_cache build and ends with a user_cache reset. Considering other simultaneous requests topwg.images.setInfo, at one point several calls ends in a timeout. Here is how it goes:[t0] requestA starts to generate user_cache
[t0+1ms] requestB waits for A to finish generating user_cache
[t0+2ms] requestC waits for A to finish generating user_cache
[t0+1ms+1s] requestB checks if the user_cache has been rebuilt, answer is no, so it continues to wait
[t0+2ms+1s] requestC checks if the user_cache has been rebuilt, answer is no, so it continues to wait
[to+1.5s] requestA finishes to rebuild user_cache, perform the image info update, immediately deletes user_cache and sends a response
[t0+1ms+2s] requestB checks if the user_cache has been rebuilt, answer is no, so it continues to wait
[t0+2ms+2s] requestC checks if the user_cache has been rebuilt, answer is no, so it continues to wait
...
[t0+1ms+10s] requestB checks if the user_cache has been rebuilt, answer is no, times out => request has failed
[t0+2ms+10s] requestC checks if the user_cache has been rebuilt, answer is no, times out => request has failed
After [t0+1.5s], for requestB and requestC, instead of only checking if the user_cache has been rebuilt, we should also that the user_cache is still being rebuilt. Because if it isn't, we should restart to try to build it instead of waiting for nothing.