summaryrefslogtreecommitdiffstats
path: root/xlators/features/barrier
diff options
context:
space:
mode:
authorKaushal M <kaushal@redhat.com>2014-05-07 18:17:11 +0530
committerKrishnan Parthasarathi <kparthas@redhat.com>2014-05-12 03:33:27 -0700
commit4f905163211f8d439c6e102d3ffd1bffb34f5c26 (patch)
treee9f4b552177a27eb79e0a39fe4d4a3588d063493 /xlators/features/barrier
parent5adb10b9ac1c634334f29732e062b12d747ae8c5 (diff)
glusterd: On gaining quorum spawn_daemons in new thread
During startup, if a glusterd has peers, it waits till quorum is obtained to spawn bricks and other services. If peers are not present, the daemons are started during glusterd' startup itself. The spawning of daemons as a quorum action was done without using a seperate thread, unlike the spawn on startup. Since, quotad was launched using the blocking runner_run api, this leads to the thread being blocked. The calling thread is almost always the epoll thread and this leads to a deadlock. The runner_run call blocks the epoll thread waiting for quotad to start, as a result glusterd cannot serve any requests. But the startup of quotad is blocked as it cannot fetch the volfile from glusterd. The fix for this is to launch the spawn daemons task in a seperate thread. This will free up the epoll thread and prevents the above deadlock from happening. Change-Id: Ife47b3591223cdfdfb2b4ea8dcd73e63f18e8749 BUG: 1095585 Signed-off-by: Kaushal M <kaushal@redhat.com> Reviewed-on: http://review.gluster.org/7703 Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com> Tested-by: Gluster Build System <jenkins@build.gluster.com> Tested-by: Krishnan Parthasarathi <kparthas@redhat.com>
Diffstat (limited to 'xlators/features/barrier')
0 files changed, 0 insertions, 0 deletions