進行對 Amazon SQS 佇列的 API 呼叫時,如何對 QueueDoesNotExist 錯誤進行疑難排解?

上次更新日期︰2021 年 8 月 24 日

在對 Amazon Simple Queue Service (Amazon SQS) 佇列進行 API 呼叫時,會收到類似下列內容的 QueueDoesNotExist 錯誤:

「此 wsdl 版本的指定佇列不存在。」

為什麼會出現此錯誤,如何對問題進行疑難排解?

解決方案

QueueDoesNotExist 錯誤可能由各種 Amazon SQS API 呼叫引起,包括 GetQueueAttributes、SendMessage 和 DeleteMessage。若要對此錯誤進行疑難排解,請檢閱下列可能的原因和解決步驟:

錯誤的佇列 URL

確認請求中提供的佇列 URL 是否正確且不含錯字。

重要事項︰如果目的地佇列類型為 FIFO,則必須將尾碼 .fifo 附加至佇列 URL。

區域不正確

在向不正確的 AWS 區域提出請求時,佇列不會傳回 QueueDoesNotExist 例外狀況。軟體開發套件 (SDK) 和 AWS Command Line Interface (AWS CLI) 不會從佇列 URL 選擇目的地區域。而是由用戶端組態來確定區域。

在進行 API 呼叫之前,必須在 Amazon SQS 用戶端上正確設定區域。檢閱 Amazon SQS 用戶端組態,以確認在用戶端上設定正確的區域。如果用戶端未設定區域,則開發套件或 AWS CLI 會從組態檔案或環境變數中選擇區域。如果在組態檔案中找不到區域,則開發套件預設會將該區域設定為 us-east-1。

如果 AWS CloudTrail 支援失敗的 API 呼叫,則驗證客戶帳戶中的所有區域是否有失敗的 Amazon SQS 操作。確認所有區域有助於確定區域是否為問題的原因。

您還可以啟用開發套件或 AWS CLI 上的偵錯日誌,來驗證請求的區域。偵錯日誌會顯示請求的目的地主機。

範例:主機︰sqs.us-east-1.amazonaws.com

最近清除或刪除的佇列

如果佇列最近被清除,可能會暫時收到 QueueDoesNotExist 錯誤。識別失敗 API 呼叫的時間戳記,然後驗證錯誤發生時 CloudTrail 的任何 PurgeQueue 操作。

如果佇列是 AWS CloudFormation 或類似部署堆疊的一部分,則會在刪除佇列時發生此錯誤。更新或刪除堆疊可能會導致佇列遭到刪除並重新建立。如果在刪除期間對佇列進行 API 呼叫,請求可能會失敗,並顯示 QueueDoesNotExist 錯誤。發生錯誤時,驗證 CloudTrail 的任何 DeleteQueue 操作。

交叉帳戶 GetQueueUrl

針對 API 呼叫,開發套件或 AWS CLI 通常會從佇列 URL 取得目的地佇列帳戶號碼。不過,GetQueueUrl API 呼叫不會在請求中提供佇列的 AWS 帳戶。這意味著請求預設會針對呼叫者帳戶發出。如果請求用於跨帳戶佇列,則必須依據 API 呼叫 QueueOwnerAWSAccountId 參數,來指定目的地佇列帳戶號碼。

訊息移至無法寄出的信件佇列

對於標準 SQS 佇列,當設定無法寄出的信件佇列 (DLQ) 時,訊息會在重試後移至 DLQ。如果在將訊息移至 DLQ 後,使用主佇列中的舊 ReceiptHandle 執行 DeleteMessage 操作,則可能會發生 QueueDoesNotExist 錯誤。必須在已設定的 VisibilityTimeout 視窗中刪除訊息。

其他疑難排解

如果您聯絡 AWS Support 以進行其他疑難排解,請務必識別失敗 API 呼叫的 RequestIdtimestamp


此文章是否有幫助?


您是否需要帳單或技術支援?