You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The lock view page relies on the hash map stored under the session, but the actual locks are stored in separate keys. e.g. lock:web/19950418155600/http://portico.bl.uk/ = _SESSION_ID_.
When the latter timeout, that's all fine, and the lock is released to an item can be viewed by another.
However, the UI shows the web/19950418155600/http://portico.bl.uk/ as an entry in a hash set stored at the key SESSION_ID, and hash set entries can't have their own expiration. So, the _locks UI does not show the true locks state.
It's not terribly performant, but given we don't expect that many users, it would probably be fine to scan all locks and group them by session ID in memory, and show that instead.
The lock view page relies on the hash map stored under the session, but the actual locks are stored in separate keys. e.g.
lock:web/19950418155600/http://portico.bl.uk/ = _SESSION_ID_
.When the latter timeout, that's all fine, and the lock is released to an item can be viewed by another.
However, the UI shows the
web/19950418155600/http://portico.bl.uk/
as an entry in a hash set stored at the key SESSION_ID, and hash set entries can't have their own expiration. So, the_locks
UI does not show the true locks state.It's not terribly performant, but given we don't expect that many users, it would probably be fine to scan all locks and group them by session ID in memory, and show that instead.
Current session scanner is at
ukwa-pywb/ukwa_pywb/ukwa_app.py
Line 342 in 153860d
The text was updated successfully, but these errors were encountered: