@@ -352,18 +352,41 @@ terminate_delete(EmitStats, Reason0, ReplyTo,
352352 fun () -> emit_stats (State ) end );
353353 true -> ok
354354 end ,
355- % % This try-catch block transforms throws to errors since throws are not
356- % % logged. When mnesia is removed this `try` can be removed: Khepri
357- % % returns errors as error tuples instead.
358- Reply = try rabbit_amqqueue :internal_delete (Q , ActingUser , Reason0 ) of
359- ok ->
360- {ok , Len };
361- {error , _ } = Err ->
362- Err
363- catch
364- {error , ReasonE } -> error (ReasonE )
365- end ,
366- send_reply (ReplyTo , Reply ),
355+ case ReplyTo of
356+ none ->
357+ % % No processes are waiting for this queue process to exit. We
358+ % % can handle the deletion of the queue record asynchropously.
359+ % %
360+ % % For instance, this allows an auto-delete queue process to
361+ % % exit, even if there is a network partition preventing any
362+ % % update to the metadata store when Khepri is used.
363+ % %
364+ % % Even if the async delete times out, the "leaked" queue
365+ % % record will be cleaned up when the partition is solved (or
366+ % % this node is removed from the cluster). Indeed, when the
367+ % % partition is solved, all nodes are notified with the
368+ % % `node_up' message from `rabbit_node_monitor'. This calls
369+ % % `rabbit_amqqueue:on_node_up/1' which will delete any
370+ % % transient queues.
371+ _ = spawn (fun () ->
372+ rabbit_amqqueue :internal_delete (
373+ Q , ActingUser , Reason0 )
374+ end );
375+ _ ->
376+ % % This try-catch block transforms throws to errors since
377+ % % throws are not logged. When mnesia is removed this `try`
378+ % % can be removed: Khepri returns errors as error tuples
379+ % % instead.
380+ Reply = try rabbit_amqqueue :internal_delete (Q , ActingUser , Reason0 ) of
381+ ok ->
382+ {ok , Len };
383+ {error , _ } = Err ->
384+ Err
385+ catch
386+ {error , ReasonE } -> error (ReasonE )
387+ end ,
388+ send_reply (ReplyTo , Reply )
389+ end ,
367390 BQS1
368391 end .
369392
0 commit comments