https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664
Bug ID: 42664
Summary: Changes to SIP2 accounts may not applied immediately
Initiative type: ---
Sponsorship ---
status:
Product: Koha
Version: Main
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P5 - low
Component: SIP2
Assignee: [email protected]
Reporter: [email protected]
QA Contact: [email protected]
SIP2 accounts/institutions are stored in the database and the SIP server is
supposed to reload its configuration when they change.
In practice, after adding or editing a SIP2 account, most SIP worker processes
keep serving the old configuration (e.g. new accounts get "SIP access not
authorized") until the SIP server is restarted ( I tested multiple times over
30 minutes ).
There seem to be two issues:
* L1 cache flushed too late. process_request() calls _config_up_to_date()
before Koha::Caches->flush_L1_caches(). The SIP parent reads
sip2_resource_last_modified into its own L1 cache at startup and never flushes
it. Every worker inherits that stale L1, so a worker's first connection
compares against the startup-era value instead of the current shared value.
* sip2_config_read_timestamp is stored in the shared (memcached) cache, but the
configuration it tracks is per-process. When one worker reloads the config from
the database, it bumps the shared timestamp, so every other worker then
evaluates as "up to date" and never reloads its own stale in-memory config.
Also, Koha::SIP2::Object::store bumps the timestamp before SUPER::store,
opening a race condition where a worker reloading during db update transaction
caches a config that is missing the new row.
--
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.
_______________________________________________
Koha-bugs mailing list
[email protected]
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
