[Batch Manager Unit Mode] deadlocks because of user_cache rebuild #2027

Closed
opened 2026-10-05 01:04:14 +02:00 by adam · 0 comments
Owner

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.

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 -->
adam closed this issue 2026-10-05 01:04:14 +02:00
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/Piwigo#2027