在ActiveMQ消息的可靠性中，介紹到在消費者接到到消息後，在處理過程中如果發生了異常，那麼ActiveMQ會對其進行重發，默認會重試6次，重發6次失敗後，就會進入死信隊列中。
這裏我們就來看一看死信隊列，死信隊列主要是用於保存處理失敗或者過期的消息，當一個消息被重發超過最大重發次數（缺省爲6次，消費者端可以修改）時，會給broker發送一個"有毒標記“，這個消息被認爲是有問題，這時broker將這個消息發送到死信隊列，以便後續處理。
ActiveMO缺省情況下，所有隊列的死信消息都被髮送到同一個缺省死信隊列ActiveMQ.DLQ中，不便於管理。可以通過individualDeadLetterStrategy或sharedDeadLetterStrategy策略來進行修改。如下：
然後我們在測試代碼中，發送一個Queue模式的消息，並且在消費端使其拋出異常，其目的地爲test.queue，這裏就和我們之前在ActiveMQ消息的可靠性 中，看到的死信隊列有所不同了，如下：
然後按住上述配置文件中所說的，將seQueueForQueueMessages設置爲false，使用Topic來保存消息，然後我們再進測試，如下：
上述都是我們的Queue模式的消息，那麼我們再來看一看Topic模式下的消息怎麼樣呢？不過在缺省情況下，持久消息過期纔會被送到DLQ，而非持久消息不會送到DLQ，所以這裏我們主要來看看持久化訂閱的Topic消息。
然後我們再使用test.topic來發送一個Topic消息測試一下，發現爲持久化訂閱的消息不會進入死信隊列，那麼我們就將其持久化在進行測試，如下：
這裏我們就發現了持久化的Topic消息，在重發6次後，也會進入死信隊列，不過這裏和Queue消息默認設置一樣，進入的也是ActiveMQ缺省的死信隊列ActiveMQ.DLQ
那麼這裏我們就和上述Queue消息類似，進行相關的設置，來指定持久化訂閱的Topic可以進入相關的死信隊列，如下：
其中seQueueForTopicMessages和上述介紹的seQueueForQueueMessages類似，也是可以修改的，用於指定使用Queue還是Topic隊列來保存消息，這裏我們進行修改，然後再進行測試：
上述提到過ActiveMQ重發的次數默認爲6次，這個值時可以進行更改的，那麼該如何更改呢，這裏我們可以在消費端進行修改，需要注意的是重試策略屬於ActiveMQ的部分，所以有部分connection，destination的聲明等等不能使用接口，必須使用ActiveMQ的實現，如下：
然後我們就進行設置重發次數，並將其加入消費端的策略Map，如下：
其餘的操作和我們之前介紹ActiveMQ的一致，然後我們進行測試，結果如下：
