+++ This bug was initially created as a clone of Bug #1260730 +++ Description of problem: The DB on the brick is been accessed by CTR, for write and tier migrator, for read and write. The write from tier migrator is reseting the heat counters after a cycle. Since we are using sqlite, two connections trying to write would cause a db lock contention. As a result CTR used to fail to update the db. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: --- Additional comment from Vijay Bellur on 2015-09-07 10:27:02 EDT --- REVIEW: http://review.gluster.org/12031 (tier/ctr: Solving DB Lock issue due to write contention from db connections) posted (#5) for review on master by Joseph Fernandes --- Additional comment from Vijay Bellur on 2015-09-08 08:13:06 EDT --- COMMIT: http://review.gluster.org/12031 committed in master by Dan Lambright (dlambrig) ------ commit 96af474045c9ba5ab74ca76daa823d91a0a0c610 Author: Joseph Fernandes <josferna> Date: Thu Aug 27 17:23:07 2015 +0530 tier/ctr: Solving DB Lock issue due to write contention from db connections Problem: The DB on the brick is been accessed by CTR, for write and tier migrator, for read and write. The write from tier migrator is reseting the heat counters after a cycle. Since we are using sqlite, two connections trying to write would cause a db lock contention. As a result CTR used to fail to update the db. Solution: Using the same db connection of CTR for reseting the heat counters. 1) Introducted a new IPC FOP for CTR 2) After the query do a ipc syncop to the underlying client xlator associated to the brick. 3) CTR in brick will catch the IPC FOP and cleat the heat counters. Change-Id: I53306bfc08dcdba479deb4ccc154896521336150 BUG: 1260730 Signed-off-by: Joseph Fernandes <josferna> Reviewed-on: http://review.gluster.org/12031 Tested-by: NetBSD Build System <jenkins.org> Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Dan Lambright <dlambrig> Tested-by: Dan Lambright <dlambrig>
*** This bug has been marked as a duplicate of bug 1261140 ***