Fix potential leak in cur file cache if the msg is both already known and in a different file - eg same msg gets added to 2 queues, one very long, the other very short. Then memory becomes tight. By the time the short file pushes msg to disk, cur file may well have rolled over

1 files changed, 5 insertions, 1 deletions

diff --git a/src/rabbit_msg_store.erl b/src/rabbit_msg_store.erl
index 2a4eadc91f..2db3c34e9b 100644
--- a/src/rabbit_msg_store.erl
+++ b/src/rabbit_msg_store.erl
@@ -531,12 +531,16 @@ handle_cast({write, MsgId, Msg},
                                     { sum_valid_data = SumValid + TotalSize,
                                       sum_file_size = SumFileSize + TotalSize }
                                    )));
-        #msg_location { ref_count = RefCount } ->
+        #msg_location { ref_count = RefCount, file = File } ->
             %% We already know about it, just update counter. Only
             %% update field otherwise bad interaction with concurrent GC
             ok = index_update_fields(MsgId,
                                      {#msg_location.ref_count, RefCount + 1},
                                      State),
+            true = case File == CurFile of
+                       true  -> true;
+                       false -> ets:delete(?CUR_FILE_CACHE_ETS_NAME, MsgId)
+                   end,
             noreply(State)
     end;