2017-09-10 20 views
0

手動創建的azure隊列上出現了不同的行爲,並且以編程方式創建了一個行爲。郵件被延遲到手動創建的天藍色隊列

我有兩個天青隊列。一個是通過Azure門戶(ARM)手動創建的,另一個是使用Azure SDK(2.9)NamespaceManager類從c#程序創建的。

我沒有問題使用QueueClient類(從創建隊列的程序的相同或不同實例)向編程創建的隊列發送消息。但是,如果我使用相同的代碼將消息發送到手動創建的隊列,那麼消息不會通過,至少不是一開始;他們被嚴重拖延了。我還沒有設法確定延遲,但至少幾小時,可能幾天。我還沒有能夠證明這些信息是否總是最終通過,或者是否有人遺失。我看不出可能解釋不同行爲的隊列屬性之間的任何顯着差異。

一旦消息出現在隊列中,就不會觀察到進一步的延遲。

是否有任何原因可能會延遲手動創建的隊列?

編輯: 進一步的調查顯示,在一個完全新的區域中的消息到新的手動創建的隊列中的新服務總線沒有延遲,但消息發送到第二手動創建隊列在該新的總線做。至少隊列2上的消息尚未完成(幾分鐘)。時間會告訴他們是否事後露面。

+1

這兩個隊列在同一個區域?你嘗試過其他隊列嗎?如果您可以輕鬆地重現該行爲,這聽起來不正確。順便說一下,2.9是舊的。有4.x –

+0

所有的隊列都在同一個服務總線和相同的區域。全部在英國西部。也許我應該嘗試不同的地區,看看是否有區別? – andrea

+0

我有的版本是從這裏的Visual Studio 2015 https://azure.microsoft.com/en-gb/downloads/ – andrea

回答

1

命名空間應該允許多個實體。根據documentation,高達10,000。這個特定的命名空間有一些東西。您可以嘗試刪除並重新創建它。或者,您可以跟進Microsoft支持來調查發生的事情。這需要時間,如果您需要命名空間名稱,請阻止您,直到調查結束。

+0

我在發佈時正在編輯問題。這看起來像是一個天藍色的問題。然而,我現在在兩個不同的區域有兩個不同的命名空間,具有相同的行爲。支持案例可能是要走的路。謝謝。 – andrea

0

這似乎是在azure門戶中顯示消息時的問題。這些消息實際上可以從SDK訪問,即使它們沒有出現在Azure門戶中。