Promote reads over writes in the msg_store.

This is safe. The cur_file cache contains all msgs in the current file and which haven't been processed by the msg_store. Thus if reading can't find it there, and for some reason we can't actually do the disk read directly from the queue process (eg the file is locked due to a GC, or we first thought the msg was in the cur file, but then it subsequently rolled over), then we know the msg has been written to disk. Thus raising the priority of the read call to the msg_store will never allow it to overtake its own write. Certainly leads to a performance improvement in some tests, and generally helps avoid queues stall.

1 files changed, 3 insertions, 4 deletions

diff --git a/src/rabbit_msg_store.erl b/src/rabbit_msg_store.erl
index 6be4358cf8..10e325e985 100644
--- a/src/rabbit_msg_store.erl
+++ b/src/rabbit_msg_store.erl
@@ -280,10 +280,9 @@ read(MsgId, CState) ->
             %% 2. Check the cur file cache
             case ets:lookup(?CUR_FILE_CACHE_ETS_NAME, MsgId) of
                 [] ->
-                    Defer =
-                        fun() -> {gen_server2:call(
-                                    ?SERVER, {read, MsgId}, infinity), CState}
-                        end,
+                    Defer = fun() -> {gen_server2:pcall(
+                                        ?SERVER, 2, {read, MsgId}, infinity),
+                                      CState} end,
                     case index_lookup(MsgId, CState) of
                         not_found   -> Defer();
                         MsgLocation -> client_read1(MsgLocation, Defer, CState)