[Koha-bugs] [Bug 11078] rebuild_zebra.pl can lose updates due to race condition during full rebuilds

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Sun Feb 2 21:24:24 CET 2014


http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11078

--- Comment #44 from Doug Kingston <dpk at randomnotes.org> ---
(In reply to Katrin Fischer from comment #43)
> I'd love to see this moving forward, but I am not sure how to fully test.

So, this feature adds locking so that basically there can ever only be one
instance of rebuild_zebra.pl running at any given time.

Incremental updates in deamon try to obtain the lock and skip the current cycle
if they cannot get the the lock.  Other updates try to get the lock and block
waiting for it to get free if its locked.

Testing should check these behaviors.  The flock testing program lets you apply
the lock without having real conflicting updates.  You can test using that to
create conflicts or just use to instances of rebuild_zebra.pl as would happen
for real.  Using verbose mode you will get messages indicating if lock
contention is detected.

Cases to test:
1) 2 non-daemon invocations of a full rebuild; the second invocation should see
the first has taken the lock and it should block until the first finishes.
2) daemon running and user starts a large full rebuild.  Run the daemon mode
incremental updater.  Add or modify a record and make sure it gets updated.
Then request a full rebuild while the daemon version is also running.  Once the
full rebuild has started, modify a record which will add an incremental update
to the zebraqueue.  You should see log messages from the daemon indicating that
it is skipping the current pass as long as the full rebuild is still running.

Does this help?

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the Koha-bugs mailing list