Panduan pemecahan masalah untuk Azure Service Bus

Artikel ini menyediakan tips dan rekomendasi pemecahan masalah untuk beberapa masalah yang Anda lihat saat menggunakan Azure Bus Layanan.

Masalah konektivitas

Waktu habis saat menyambungkan ke layanan

Tergantung pada lingkungan dan jaringan host, masalah konektivitas mungkin muncul untuk aplikasi sebagai TimeoutException, , OperationCanceledExceptionatau ServiceBusException dengan Reason dan ServiceTimeout paling sering terjadi ketika klien tidak dapat menemukan jalur jaringan ke layanan.

Pemecahan masalah:

• Verifikasi bahwa nama domain string koneksi atau sepenuhnya memenuhi syarat yang Anda tentukan saat membuat klien sudah benar. Untuk informasi tentang cara memperoleh string koneksi, lihat Mendapatkan Bus Layanan string koneksi.
• Periksa izin firewall dan port di lingkungan hosting Anda. Periksa apakah port Advanced Message Queuing Protocol (AMQP) 5671 dan 5672 terbuka dan titik akhir diizinkan melalui firewall.
• Coba gunakan opsi transportasi Web Socket, yang terhubung menggunakan port 443. Untuk detailnya, lihat mengonfigurasi transportasi.
• Lihat apakah jaringan Anda memblokir alamat IP tertentu. Untuk detailnya, lihat Alamat IP apa yang perlu saya izinkan?
• Jika berlaku, verifikasi konfigurasi proksi. Untuk detailnya, lihat: Mengonfigurasi transportasi
• Untuk informasi selengkapnya tentang pemecahan masalah konektivitas jaringan, lihat: [Koneksi ivity, sertifikat, atau masalah waktu habis][#connectivity-certificate-or-timeout-issue].

Kegagalan jabat tangan lapisan soket aman (SSL)

Kesalahan ini dapat terjadi ketika proksi penyadapan digunakan. Untuk memverifikasi, Kami sarankan Anda menguji aplikasi di lingkungan host dengan proksi dinonaktifkan.

Kesalahan kelelahan soket

Aplikasi harus lebih suka memperlakukan jenis Bus Layanan sebagai singleton, membuat dan menggunakan satu instans selama masa pakai aplikasi. Setiap ServiceBusClient baru yang dibuat menghasilkan koneksi AMQP baru, yang menggunakan soket. Jenis ServiceBusClient mengelola koneksi untuk semua jenis yang dibuat dari instans tersebut. Setiap ServiceBusReceiver, ServiceBusSessionReceiver, ServiceBusSender, dan ServiceBusProcessor mengelola tautan AMQP sendiri untuk entitas Bus Layanan terkait. Saat Anda menggunakan ServiceBusSessionProcessor, beberapa tautan AMQP dibuat tergantung pada jumlah sesi yang sedang diproses secara bersamaan.

Klien aman untuk di-cache saat diam; mereka memastikan manajemen jaringan, CPU, dan penggunaan memori yang efisien, meminimalkan dampaknya selama periode tidak aktif. Penting juga bahwa baik CloseAsync atau DisposeAsync dipanggil ketika klien tidak lagi diperlukan untuk memastikan bahwa sumber daya jaringan dibersihkan dengan benar.

Menambahkan komponen ke string koneksi tidak berfungsi

Generasi pustaka klien Bus Layanan saat ini hanya mendukung string koneksi dalam formulir yang diterbitkan oleh portal Azure. string koneksi dimaksudkan untuk menyediakan lokasi dasar dan informasi kunci bersama saja. Mengonfigurasi perilaku klien dilakukan melalui opsinya.

Generasi sebelumnya dari klien Bus Layanan memungkinkan beberapa perilaku dikonfigurasi dengan menambahkan komponen kunci/nilai ke string koneksi. Komponen-komponen ini tidak lagi dikenali dan tidak berpengaruh pada perilaku klien.

Alternatif "TransportType=AmqpWebSockets"

Untuk mengonfigurasi Soket Web sebagai jenis transportasi, lihat Mengonfigurasi transportasi.

Alternatif "Authentication=Managed Identity"

Untuk mengautentikasi dengan Identitas Terkelola, lihat: Identitas dan Kredensial Akses Bersama. Untuk informasi selengkapnya tentang Azure.Identity pustaka, lihat Autentikasi dan Azure SDK.

Logging dan diagnostik

Pustaka klien Bus Layanan sepenuhnya diinstrumentasikan untuk informasi pengelogan pada berbagai tingkat detail menggunakan .NET EventSource untuk memancarkan informasi. Pengelogan dilakukan untuk setiap operasi dan mengikuti pola menandai titik awal operasi, penyelesaiannya, dan pengecualian apa pun yang ditemui. Informasi tambahan yang mungkin menawarkan wawasan juga dicatat dalam konteks operasi terkait.

Aktifkan pencatatan log

Log klien Bus Layanan tersedia untuk apa pun EventListener dengan memilih sumber yang dimulai dengan atau dengan Azure-Messaging-ServiceBus memilih ke semua sumber yang memiliki sifat AzureEventSource. Untuk mempermudah pengambilan log dari pustaka klien Azure, pustaka yang Azure.Core digunakan oleh Bus Layanan menawarkan AzureEventSourceListener.

Untuk informasi selengkapnya, lihat: Pengelogan dengan Azure SDK untuk .NET.

Pelacakan terdistribusi

Pustaka klien Bus Layanan mendukung pelacakan terdistribusi melalui integrasi dengan Application Insights SDK. Ini juga memiliki dukungan eksperimental untuk spesifikasi OpenTelemetry melalui jenis .NET ActivitySource yang diperkenalkan di .NET 5. Untuk mengaktifkan ActivitySource dukungan untuk digunakan dengan OpenTelemetry, lihat Dukungan ActivitySource.

Untuk menggunakan dukungan GA DiagnosticActivity, Anda dapat berintegrasi dengan Application Insights SDK. Detail selengkapnya dapat ditemukan di ApplicationInsights dengan Azure Monitor.

Pustaka membuat rentang berikut:

Message
ServiceBusSender.Send
ServiceBusSender.Schedule
ServiceBusSender.Cancel
ServiceBusReceiver.Receive
ServiceBusReceiver.ReceiveDeferred
ServiceBusReceiver.Peek
ServiceBusReceiver.Abandon
ServiceBusReceiver.Complete
ServiceBusReceiver.DeadLetter
ServiceBusReceiver.Defer
ServiceBusReceiver.RenewMessageLock
ServiceBusSessionReceiver.RenewSessionLock
ServiceBusSessionReceiver.GetSessionState
ServiceBusSessionReceiver.SetSessionState
ServiceBusProcessor.ProcessMessage
ServiceBusSessionProcessor.ProcessSessionMessage
ServiceBusRuleManager.CreateRule
ServiceBusRuleManager.DeleteRule
ServiceBusRuleManager.GetRules

Sebagian besar rentangnya cukup jelas dan dimulai dan dihentikan selama operasi yang menyandang namanya. Rentang yang mengikat yang lain bersama-sama adalah Message. Cara pesan dilacak adalah melalui Diagnostic-Id yang diatur dalam properti ServiceBusMessage.ApplicationProperties oleh pustaka selama operasi pengiriman dan jadwal. Dalam Application Insights, Message rentang ditampilkan sebagai penautan ke berbagai rentang lain yang digunakan untuk berinteraksi dengan pesan, misalnya, ServiceBusReceiver.Receive rentang, ServiceBusSender.Send rentang, dan ServiceBusReceiver.Complete rentang semuanya akan ditautkan dari Message rentang. Berikut adalah contoh tampilannya di Application Insights:

Pada cuplikan layar di atas, Anda akan melihat transaksi end-to-end yang dapat dilihat di Application Insights di portal. Dalam skenario ini, aplikasi mengirim pesan dan menggunakan ServiceBusSessionProcessor untuk memprosesnya. Aktivitas Message ditautkan ke ServiceBusSender.Send, , ServiceBusSessionProcessor.ProcessSessionMessageServiceBusReceiver.Receive, dan ServiceBusReceiver.Complete.

Catatan

Untuk informasi selengkapnya, lihat Pelacakan dan korelasi terdistribusi melalui olahpesan Bus Layanan.

Memecahkan masalah pengirim

Tidak dapat mengirim batch dengan beberapa kunci partisi

Saat aplikasi mengirim batch ke entitas berkemampuan partisi, semua pesan yang disertakan dalam satu operasi pengiriman harus memiliki yang sama PartitionKey. Jika entitas Anda diaktifkan sesi, persyaratan yang sama berlaku untuk SessionId properti . Untuk mengirim pesan dengan nilai atau yang berbedaPartitionKey, kelompokkan pesan dalam instans terpisah ServiceBusMessageBatch atau sertakan dalam panggilan terpisah ke overload SendMessagesAsync yang mengambil serangkaian ServiceBusMessage instans.SessionId

Batch gagal dikirim

Batch ServiceBusMessageBatch pesan berisi dua pesan atau lebih, atau panggilan ke SendMessagesAsync tempat dua pesan atau lebih diteruskan. Layanan ini tidak mengizinkan batch pesan melebihi 1 MB. Perilaku ini benar apakah fitur dukungan pesan besar Premium diaktifkan atau tidak. Jika Anda ingin mengirim pesan yang lebih besar dari 1 MB, pesan harus dikirim satu per satu daripada dikelompokkan dengan pesan lain. Sayangnya, jenis ServiceBusMessageBatch saat ini tidak mendukung validasi bahwa batch tidak berisi pesan apa pun yang lebih besar dari 1 MB karena ukurannya dibatasi oleh layanan dan mungkin berubah. Jadi, jika Anda ingin menggunakan fitur dukungan pesan besar premium, pastikan Anda mengirim pesan lebih dari 1 MB satu per satu.

Memecahkan masalah penerima

Jumlah pesan yang dikembalikan tidak cocok dengan nomor yang diminta dalam penerimaan batch

Saat mencoba melakukan operasi penerimaan batch, yaitu, meneruskan maxMessages nilai dua atau lebih besar ke metode ReceiveMessagesAsync , Anda tidak dijamin menerima jumlah pesan yang diminta, bahkan jika antrean atau langganan memiliki banyak pesan yang tersedia pada saat itu, dan bahkan jika seluruh yang dikonfigurasi maxWaitTime belum berlalu. Untuk memaksimalkan throughput dan menghindari kedaluwarsa kunci, setelah pesan pertama datang melalui kawat, penerima menunggu 20 milidetik tambahan untuk pesan tambahan sebelum mengirimkan pesan untuk diproses. Mengontrol maxWaitTime berapa lama penerima menunggu untuk menerima pesan pertama - pesan berikutnya ditunggu selama 20 milidetik. Oleh karena itu, aplikasi Anda tidak boleh berasumsi bahwa semua pesan yang tersedia diterima dalam satu panggilan.

Pesan atau kunci sesi hilang sebelum waktu kedaluwarsa kunci

Layanan Bus Layanan menggunakan protokol AMQP, yang stateful. Karena sifat protokol, jika tautan yang menghubungkan klien dan layanan dilepas setelah pesan diterima, tetapi sebelum pesan diselesaikan, pesan tidak dapat diselesaikan saat menyambungkan kembali tautan. Tautan dapat dilepaskan karena kegagalan jaringan sementara jangka pendek, pemadaman jaringan, atau karena layanan diberlakukan batas waktu menganggur 10 menit. Koneksi ulang tautan terjadi secara otomatis sebagai bagian dari operasi apa pun yang memerlukan tautan, yaitu menyelesaikan atau menerima pesan. Dalam situasi ini, Anda menerima ServiceBusException dengan Reason atau MessageLockLostSessionLockLost bahkan jika waktu kedaluwarsa kunci belum berlalu.

Cara menelusuri pesan terjadwal atau ditangguhkan

Pesan terjadwal dan ditangguhkan disertakan saat mengintip pesan. Mereka dapat diidentifikasi oleh properti ServiceBusReceivedMessage.State . Setelah Anda memiliki SequenceNumber dari pesan yang ditangguhkan, Anda dapat menerimanya dengan kunci melalui metode ReceiveDeferredMessagesAsync.

Saat bekerja dengan topik, Anda tidak dapat mengintip pesan terjadwal pada langganan, karena pesan tetap berada dalam topik hingga waktu antrean terjadwal. Sebagai solusinya, Anda dapat membuat ServiceBusReceiver yang meneruskan nama topik untuk mengintip pesan tersebut. Tidak ada operasi lain dengan pekerjaan penerima saat menggunakan nama topik.

Cara menelusuri pesan sesi di semua sesi

Anda dapat menggunakan ServiceBusReceiver reguler untuk mengintip semua sesi. Untuk mengintip sesi tertentu, Anda dapat menggunakan ServiceBusSessionReceiver, tetapi Anda perlu mendapatkan kunci sesi.

NotSupportedException dilemparkan saat mengakses isi pesan

Masalah ini paling sering terjadi dalam skenario interop saat menerima pesan yang dikirim dari pustaka lain yang menggunakan format isi pesan AMQP yang berbeda. Jika Anda berinteraksi dengan jenis pesan ini, lihat sampel isi pesan AMQP untuk mempelajari cara mengakses isi pesan.

Memecahkan masalah prosesor

Perpanjangan blok otomatis tidak berfungsi

Perpanjangan autolock bergantung pada waktu sistem untuk menentukan kapan harus memperbarui kunci untuk pesan atau sesi. Jika waktu sistem Anda tidak akurat, misalnya, jam Anda lambat, perpanjangan kunci mungkin tidak terjadi sebelum kunci hilang. Pastikan waktu sistem Anda akurat jika perpanjangan autolock tidak berfungsi.

Prosesor tampaknya macet atau memiliki masalah latensi saat menggunakan konkurensi tinggi

Perilaku ini sering disebabkan oleh kelaparan utas, terutama ketika menggunakan prosesor sesi dan menggunakan nilai yang sangat tinggi untuk MaxConcurrentSessions, relatif terhadap jumlah inti pada komputer. Hal pertama yang harus diperiksa adalah memastikan Anda tidak melakukan sinkronisasi berlebihan di salah satu penanganan aktivitas Anda. Sync-over-async adalah cara mudah untuk menyebabkan kebuntuan dan kelaparan utas. Bahkan jika Anda tidak melakukan sinkronisasi melalui asinkron, kode sinkronisasi murni di handler Anda dapat berkontribusi pada kelaparan utas. Jika Anda telah menentukan bahwa itu bukan masalah, misalnya, karena Anda memiliki kode asinkron murni, Anda dapat mencoba meningkatkan [TryTimeout][TryTimeout]. Ini mengurangi tekanan pada kumpulan utas dengan mengurangi jumlah sakelar konteks dan batas waktu yang terjadi saat menggunakan prosesor sesi khususnya. Nilai default untuk [TryTimeout][TryTimeout] adalah 60 detik, tetapi dapat diatur hingga 1 jam. Sebaiknya uji dengan TryTimeout set ke 5 menit sebagai titik awal dan iterasi dari sana. Jika tidak ada saran ini yang berfungsi, Anda hanya perlu menskalakan ke beberapa host, mengurangi konkurensi dalam aplikasi Anda, tetapi menjalankan aplikasi pada beberapa host untuk mencapai konkurensi keseluruhan yang diinginkan.

Bacaan lebih lanjut:

• Debug kumpulan utas kelaparan
• Mendiagnosis kelaparan kumpulan utas .NET Core dengan PerfView (Mengapa layanan saya tidak menjenuhkan semua inti atau tampaknya menunda)
• Mendiagnosis masalah kelelahan kumpulan utas di .NET Core Apps(video)

Prosesor sesi membutuhkan waktu terlalu lama untuk beralih sesi

Ini dapat dikonfigurasi menggunakan [SessionIdleTimeout][SessionIdleTimeout], yang memberi tahu prosesor berapa lama menunggu untuk menerima pesan dari sesi, sebelum menyerah dan pindah ke sesi lain. Ini berguna jika Anda memiliki banyak sesi yang jarang diisi, di mana setiap sesi hanya memiliki beberapa pesan. Jika Anda mengharapkan bahwa setiap sesi akan memiliki banyak pesan yang menetuk, mengaturnya terlalu rendah dapat berlawanan produktif, karena mengakibatkan penutupan sesi yang tidak perlu.

Prosesor segera berhenti

Ini sering diamati untuk skenario demo atau pengujian. StartProcessingAsync kembali segera setelah prosesor dimulai. Memanggil metode ini tidak akan memblokir dan menjaga aplikasi Anda tetap hidup saat prosesor berjalan, jadi Anda memerlukan beberapa mekanisme lain untuk melakukannya. Untuk demo atau pengujian, cukup untuk menambahkan Console.ReadKey() panggilan setelah Anda memulai prosesor. Untuk skenario produksi, Anda mungkin ingin menggunakan semacam integrasi kerangka kerja seperti [BackgroundService][BackgroundService] untuk menyediakan kait siklus hidup aplikasi yang nyaman yang dapat digunakan untuk memulai dan membuang prosesor.

Memecahkan masalah transaksi

Untuk informasi umum tentang transaksi di Bus Layanan, lihat [Gambaran Umum pemrosesan transaksi Bus Layanan][Transaksi].

Operasi yang didukung

Tidak semua operasi didukung saat menggunakan transaksi. Untuk melihat daftar transaksi yang didukung, lihat [Operasi dalam cakupan transaksi][TransactionOperations].

Waktu habis

Waktu transaksi habis setelah [periode waktu][TransactionTimeout], jadi penting bahwa pemrosesan yang terjadi dalam cakupan transaksi mematuhi batas waktu ini.

Operasi dalam transaksi tidak dicoba kembali

Ini memang disengaja. Pertimbangkan skenario berikut - Anda mencoba menyelesaikan pesan dalam transaksi, tetapi ada beberapa kesalahan sementara yang terjadi, misalnya, ServiceBusException dengan Reason .ServiceCommunicationProblem Misalkan permintaan benar-benar membuatnya ke layanan. Jika klien mencoba kembali, layanan akan melihat dua permintaan lengkap. Penyelesaian pertama tidak akan diselesaikan sampai transaksi dilakukan. Penyelesaian kedua bahkan tidak dapat dievaluasi sebelum penyelesaian pertama selesai. Transaksi pada klien sedang menunggu selesainya. Ini membuat kebuntuan di mana layanan menunggu klien menyelesaikan transaksi, tetapi klien menunggu layanan untuk mengakui operasi lengkap kedua. Transaksi pada akhirnya akan habis setelah 2 menit, tetapi ini adalah pengalaman pengguna yang buruk. Untuk alasan ini, kami tidak mencoba kembali operasi dalam transaksi.

Transaksi di seluruh entitas tidak berfungsi

Untuk melakukan transaksi yang melibatkan beberapa entitas, Anda perlu mengatur ServiceBusClientOptions.EnableCrossEntityTransactions properti ke true. Untuk detailnya, lihat sampel [Transaksi di seluruh entitas][CrossEntityTransactions].

Kuota

Informasi tentang kuota Bus Layanan dapat ditemukan [di sini][ServiceBusQuotas].

Masalah konektivitas, sertifikat, atau batas waktu

Langkah-langkah berikut membantu Anda memecahkan masalah konektivitas/sertifikat/batas waktu untuk semua layanan di bawah *.servicebus.windows.net.

• Telusuri ke atau wgethttps://<yournamespace>.servicebus.windows.net/. Alat ini membantu dengan memeriksa apakah Anda memiliki pemfilteran IP atau jaringan virtual atau masalah rantai sertifikat, yang sering terjadi saat menggunakan Java SDK.

  Contoh pesan yang berhasil:

  <feed xmlns="http://www.w3.org/2005/Atom"><title type="text">Publicly Listed Services</title><subtitle type="text">This is the list of publicly-listed services currently available.</subtitle><id>uuid:27fcd1e2-3a99-44b1-8f1e-3e92b52f0171;id=30</id><updated>2019-12-27T13:11:47Z</updated><generator>Service Bus 1.1</generator></feed>
  

  Contoh pesan kesalahan kegagalan:

  <Error>
      <Code>400</Code>
      <Detail>
          Bad Request. To know more visit https://aka.ms/sbResourceMgrExceptions. . TrackingId:b786d4d1-cbaf-47a8-a3d1-be689cda2a98_G22, SystemTracker:NoSystemTracker, Timestamp:2019-12-27T13:12:40
      </Detail>
  </Error>
  

• Jalankan perintah berikut untuk memeriksa apakah ada port yang diblokir pada firewall. Port yang digunakan adalah 443 (HTTPS), 5671 dan 5672 (AMQP) serta 9354 (Net Messaging/SBMP). Bergantung pada pustaka yang Anda gunakan, port lain juga digunakan. Berikut adalah perintah sampel yang memeriksa apakah port 5671 diblokir. C

  tnc <yournamespacename>.servicebus.windows.net -port 5671
  

  Di Linux:

  telnet <yournamespacename>.servicebus.windows.net 5671
  

• Ketika ada masalah konektivitas terputus-putus, jalankan perintah berikut untuk memeriksa apakah ada paket yang dihentikan. Perintah ini mencoba membuat 25 koneksi TCP yang berbeda setiap 1 detik dengan layanan. Kemudian, Anda dapat memeriksa berapa banyak koneksi yang berhasil/gagal dan juga melihat latensi koneksi TCP. Anda dapat mengunduh versi terbaru alat psping dari sini.

  .\psping.exe -n 25 -i 1 -q <yournamespace>.servicebus.windows.net:5671 -nobanner     
  

  Anda dapat menggunakan perintah yang setara jika menggunakan alat lain seperti tnc, ping, dan sebagainya.

• Dapatkan jejak jaringan jika langkah sebelumnya tidak membantu dan lakukan analisis menggunakan alat seperti Wireshark. Hubungi Bagian Dukungan Microsoft jika diperlukan.

• Untuk menemukan alamat IP yang tepat untuk ditambahkan ke daftar yang diperboleh untuk koneksi Anda, lihat Alamat IP yang perlu saya tambahkan ke daftar yang diperbolehkan.

Pada 30 September 2026, kami akan menghentikan dukungan protokol SBMP untuk Azure Bus Layanan, sehingga Anda tidak akan dapat lagi menggunakan protokol ini setelah 30 September 2026. Migrasikan ke pustaka Azure Bus Layanan SDK terbaru menggunakan protokol AMQP, yang menawarkan pembaruan keamanan penting dan kemampuan yang ditingkatkan, sebelum tanggal tersebut.

Untuk informasi selengkapnya, lihat pengumuman penghentian dukungan.

Masalah yang mungkin terjadi pada peningkatan/mulai ulang layanan

Gejala

• Permintaan mungkin dibatasi sesaat.
• Mungkin ada penurunan pesan/permintaan masuk.
• File log mungkin berisi pesan kesalahan.
• Aplikasi mungkin terputus dari layanan selama beberapa detik.

Penyebab

Peningkatan dan hidupkan ulang layanan backend dapat menyebabkan masalah ini di aplikasi Anda.

Resolusi

Jika kode aplikasi menggunakan SDK, kebijakan coba lagi sudah dibangun dan aktif. Aplikasi terhubung kembali tanpa dampak signifikan ke aplikasi/alur kerja.

Akses tidak sah: Perlu kirim klaim

Gejala

Anda mungkin melihat kesalahan ini saat mencoba mengakses topik Bus Layanan dari Visual Studio di komputer lokal menggunakan identitas terkelola yang ditetapkan pengguna dengan izin kirim.

Service Bus Error: Unauthorized access. 'Send' claim\(s\) are required to perform this operation.

Penyebab

Identitas tidak memiliki izin untuk mengakses topik Service Bus.

Resolusi

Untuk mengatasi kesalahan ini, instal pustaka Microsoft.Azure.Services.AppAuthentication. Untuk informasi selengkapnya, lihat Autentikasi pengembangan lokal.

Untuk mempelajari cara menetapkan izin ke peran, lihat Mengautentikasi identitas terkelola dengan ID Microsoft Entra untuk mengakses sumber daya Azure Bus Layanan.

Pengecualian Service Bus: Letakkan token gagal

Gejala

Anda mungkin menerima pesan kesalahan berikut:

Microsoft.Azure.ServiceBus.ServiceBusException: Put token failed. status-code: 403, status-description: The maximum number of '1000' tokens per connection has been reached.

Pada 30 September 2026, kami akan menghentikan pustaka Azure Bus Layanan SDK WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus, dan com.microsoft.azure.servicebus, yang tidak sesuai dengan panduan Azure SDK. Kami juga akan mengakhiri dukungan protokol SBMP, sehingga Anda tidak akan lagi dapat menggunakan protokol ini setelah 30 September 2026. Migrasikan ke pustaka Azure SDK terbaru, yang menawarkan pembaruan keamanan penting dan kemampuan yang ditingkatkan, sebelum tanggal tersebut.

Meskipun pustaka lama masih dapat digunakan melebihi 30 September 2026, pustaka tersebut tidak akan lagi menerima dukungan dan pembaruan resmi dari Microsoft. Untuk informasi selengkapnya, lihat pengumuman penghentian dukungan.

Penyebab

Jumlah token autentikasi untuk link bersamaan dalam satu koneksi ke namespace layanan Bus Layanan telah melampaui batas: 1000.

Resolusi

Lakukan salah satu langkah berikut:

• Mengurangi jumlah link bersamaan dalam satu koneksi atau gunakan koneksi baru
• Gunakan SDK untuk Bus Layanan Azure, yang memastikan bahwa Anda tidak mengalami situasi ini (disarankan)

Kunci sumber daya tidak berfungsi saat menggunakan SDK sarana data

Gejala

Anda telah mengonfigurasi kunci penghapusan pada namespace Bus Layanan, tetapi Anda dapat menghapus sumber daya di namespace (antrean, topik, dll.) dengan menggunakan Bus Layanan Explorer.

Penyebab

Kunci sumber daya dipertahankan di Azure Resource Manager (sarana kontrol) dan tidak mencegah panggilan SDK bidang data menghapus sumber daya langsung dari namespace layanan. Bus Layanan Explorer mandiri menggunakan SDK bidang data, sehingga penghapusan dilalui.

Resolusi

Kami menyarankan agar Anda menggunakan API berbasis Azure Resource Manager melalui templat portal Azure, PowerShell, CLI, atau Resource Manager untuk menghapus entitas sehingga kunci sumber daya mencegah sumber daya dihapus secara tidak sengaja.

Entitas tidak lagi tersedia

Gejala

Anda melihat kesalahan bahwa entitas tidak lagi tersedia.

Penyebab

Sumber daya mungkin telah dihapus. Ikuti langkah-langkah ini untuk mengidentifikasi mengapa entitas dihapus.

• Periksa log aktivitas untuk melihat apakah ada permintaan Azure Resource Manager untuk penghapusan.
• Periksa log operasional untuk melihat apakah ada panggilan API langsung untuk penghapusan. Untuk mempelajari cara mengumpulkan log operasional, lihat Pengumpulan dan perutean. Untuk skema dan contoh log operasi, lihat Log operasi
• Periksa log operasi untuk melihat apakah ada autodeleteonidle penghapusan terkait.

Langkah berikutnya

Lihat artikel berikut:

• Pengecualian Azure Resource Manager. Artikel ini mencantumkan pengecualian yang dibuat saat berinteraksi dengan Azure Service Bus menggunakan Azure Resource Manager (melalui templat atau panggilan langsung).
• Pengecualian olahpesan. Artikel ini menyediakan daftar pengecualian yang dibuat oleh .NET Framework untuk Azure Service Bus.