Panduan pemecahan masalah Spring JMS

Artikel ini menjelaskan cara memecahkan masalah umum dan kesalahan umum saat menggunakan Spring JMS. Artikel ini juga menjawab beberapa pertanyaan yang sering diajukan untuk spring-cloud-azure-starter-servicebus-jms.

Masalah konektivitas

MessageProducer ditutup karena kesalahan yang tidak dapat dipulihkan

Deskripsi masalah

Saat menggunakan JmsTemplate untuk mengirim pesan, JmsTemplate menjadi tidak tersedia selama interval diam antara 10 hingga 15 menit. Mengirim pesan dalam interval tersebut bisa mendapatkan pengecualian yang diperlihatkan dalam contoh output berikut:

2022-11-06 11:12:05.762  INFO 25944 --- [   scheduling-1] c.e.demo.ServiceBusJMSMessageProducer    : Sending message: 2022-11-06T11:12:05.762072 message 1
2022-11-06 11:12:05.772 ERROR 25944 --- [   scheduling-1] o.s.s.s.TaskUtils$LoggingErrorHandler    : Unexpected error occurred in scheduled task

org.springframework.jms.IllegalStateException: The MessageProducer was closed due to an unrecoverable error.; nested exception is javax.jms.IllegalStateException: The MessageProducer was closed due to an unrecoverable error.
    at org.springframework.jms.support.JmsUtils.convertJmsAccessException(JmsUtils.java:274) ~[spring-jms-5.3.23.jar:5.3.23]
  ...
Caused by: org.apache.qpid.jms.provider.ProviderException: The link 'G0:36906660:qpid-jms:sender:azure:5caf3ef4-9602-413c-964d-cf1292d6e1f5:1:1:1:t4' is force detached. Code: publisher(link376). Details: AmqpMessagePublisher.IdleTimerExpired: Idle timeout: 00:10:00. [condition = amqp:link:detach-forced]
    at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToNonFatalException(AmqpSupport.java:181) ~[qpid-jms-client-0.53.0.jar:na]
  ...

Analisis penyebab

Pengecualian terjadi untuk Azure Service Bus ketika koneksi dan tautan AMQP aktif tetapi tidak ada panggilan - misalnya, mengirim atau menerima panggilan - dilakukan menggunakan tautan selama 10 menit. Dalam hal ini, tautan ditutup. Dan ketika semua tautan dalam koneksi telah ditutup karena tidak ada aktivitas (menganggur) dan tautan baru belum dibuat dalam 5 menit, koneksi ditutup.

Untuk starter Bus Layanan JMS, CachingConnectionFactory digunakan secara bawaan, yang menyimpan sesi, produsen, dan konsumen dalam cache. Ketika JmsProducer tidak aktif selama lebih dari 10 menit tetapi kurang dari 15 menit, tautan yang digunakan oleh produsen yang di-cache telah ditutup. Pesan tidak dapat dikirim selama interval ini. Kemudian, setelah 5 menit menganggur, seluruh koneksi ditutup. Dengan demikian, setiap operasi pengiriman setelah interval diam 15 menit menyebabkan CachingConnectionFactory membuat koneksi baru untuk dikirim. Proses pengiriman akan tersedia setelah 15 menit.

Penanganan masalah

Saat ini, starter menyediakan solusi sementara untuk masalah pelepasan tautan dengan menerapkan JmsPoolConnectionFactory, yang mem-pool Connection, Session, dan MessageProducer, serta mengelola siklus hidup instance yang dipoolkan. Solusi ini dapat memastikan bahwa produsen dikeluarkan setelah tidak tersedia dan karenanya semua operasi pengiriman dilakukan pada produsen aktif.

Untuk menggunakan solusi ini, tambahkan konfigurasi berikut:

spring:
  jms:
    servicebus:
      pool:
        enabled: true
        max-connections: ${your-expected-max-connection-value}

Penggunaan spring.jms.servicebus.idle-timeout

Properti waktu tunggu idle mengonfigurasi waktu tunggu idle pada koneksi AMQP. Spesifikasi AMQP memberikan deskripsi berikut:

Koneksi tunduk pada ambang batas waktu diam. Timeout dipicu oleh peer lokal ketika tidak ada frame yang diterima setelah melebihi nilai ambang batas. Waktu habis idle diukur dalam milidetik, dan dihitung sejak frame terakhir diterima. Jika ambang batas terlampaui, maka peer sebaiknya mencoba menutup koneksi secara wajar menggunakan frame penutup dengan pesan galat yang menjelaskan alasannya. Jika peer jarak jauh tidak merespons sebagaimana mestinya dalam batas waktu yang ditentukan untuk hal ini, peer DAPAT menutup soket TCP.

Untuk klien JMS, ketika Anda mengonfigurasi properti ini, Anda mengontrol di sisi server berapa lama Anda mengharapkan server mengirim bingkai kosong untuk menjaga koneksi tetap hidup ketika tidak ada pesan yang dikirim. Properti ini mengontrol perilaku peer jarak jauh, dan setiap peer dapat memiliki nilai tersendiri yang terisolasi.

Masalah JmsTemplate

Pesan terjadwal

Azure Service Bus mendukung pemrosesan pesan yang tertunda. Untuk informasi selengkapnya, lihat bagian Pesan terjadwal di Pengurutan pesan dan stempel waktu. Untuk JMS, untuk menjadwalkan pesan, atur properti ScheduledEnqueueTimeUtc dengan menggunakan header anotasi pesan x-opt-scheduled-enqueue-time.

Masalah JmsListener

Terlalu banyak permintaan yang dikirim ke Bus Layanan meskipun tidak ada pesan di server

Deskripsi masalah

Saat menggunakan API @JmsListener, dalam beberapa kasus Anda dapat melihat di portal Azure bahwa nilai untuk permintaan masuk yang dikirim ke antrean atau topik tersebut terus tercatat, meskipun tidak ada pesan di server yang dapat diterima.

Analisis penyebab

@JmsListener adalah listener polling, yang dirancang untuk upaya polling yang berulang.

Pendengar duduk di perulangan polling yang sedang berlangsung. Setiap perulangan memanggil metode JMS MessageConsumer.receive() untuk melakukan polling kepada konsumen lokal agar pesan dapat digunakan. Secara default, untuk setiap operasi polling, konsumen lokal mengirim permintaan pull ke broker pesan untuk meminta pesan dan kemudian memblokir untuk jangka waktu tertentu. Proses polling konkret diputuskan oleh beberapa properti, termasuk receiveTimeout, prefetchSize, dan receiveLocalOnly atau receiveNoWaitLocalOnly. Metode receiveNoWaitLocalOnly hanya digunakan saat Anda mengatur receiveTimeout ke nilai negatif.

Ketika masalah ini terjadi pada aplikasi Anda, periksa pengaturan konfigurasi berikut:

• Tentukan apakah kebijakan prefetch Anda adalah 0, yang juga merupakan opsi default. 0-prefetch berarti konsumen pull yang mengirim permintaan pull ke Bus Layanan pada setiap polling.

• Jika Anda telah mengonfigurasi prefetch dengan nilai bukan nol, periksa apakah properti receiveLocalOnly atau receiveNoWaitLocalOnly diatur ke false, yang merupakan opsi bawaan. Nilai false di sini tetap menyebabkan permintaan pull dikirim ke server karena mekanisme ini tidak hanya mem-poll konsumen lokal.

• Konfigurasi receiveTimeout menentukan berapa lama blokir untuk setiap permintaan pull, sehingga dapat memengaruhi frekuensi permintaan pull yang dikirim ke server. Nilai defaultnya adalah 1 detik.

Untuk analisis lengkap, lihat diskusi dalam masalah GitHub .

Solusi

Bagian berikut menjelaskan dua solusi untuk menangani masalah ini

Solusi 1. Ubah untuk mendorong konsumen dan pemeriksaan lokal saja

Dengan mengubah mode menjadi push, konsumen menjadi konsumen Notifikasi Asinkron yang tidak mengambil pesan dari broker, tetapi mempertahankan jumlah target kredit tautan. Jumlahnya ditentukan oleh properti prefetch. Saat Bus Layanan (pengirim) mendorong pesan, kredit tautan pengirim berkurang, dan ketika kredit tautan pengirim berada di bawah ambang batas, klien (penerima) mengirim permintaan ke server untuk meningkatkan kredit tautan pengirim kembali ke jumlah target yang diinginkan.

Untuk mencapai solusi ini, tambahkan konfigurasi berikut:

Pertama, konfigurasikan nilai prefetch agar bukan nol, sehingga konsumen dikonfigurasi sebagai bukan pull. Tabel berikut ini memperlihatkan beberapa properti prefetch, yang masing-masing mengontrol entitas Azure Bus Layanan yang berbeda. Atur properti yang berlaku untuk kasus Anda.

Harta benda	Deskripsi
spring.jms.servicebus.prefetch.all	Nilai cadangan untuk opsi prefetch di namespace Bus Layanan ini
spring.jms.servicebus.prefetch.queue-prefetch	Nomor prefetch untuk antrean.
spring.jms.servicebus.prefetch.queue-browser-prefetch	Nomor pramuat untuk penjelajah antrean.
spring.jms.servicebus.prefetch.topic-prefetch	Nomor prefetch untuk topik tersebut.
spring.jms.servicebus.prefetch.durable-topic-prefetch	Nomor prefetch untuk topik persisten.

Kedua, konfigurasikan non-local-check dengan menambahkan kelas konfigurasi untuk penyesuai pabrik, seperti yang ditunjukkan dalam contoh berikut:

@Configuration(proxyBeanMethods = false)
public class CustomJmsConfiguration {

    @Bean
    ServiceBusJmsConnectionFactoryCustomizer customizer() {
        return factory -> {
            factory.setReceiveLocalOnly(true);
            // Configure the below ReceiveNoWaitLocalOnly instead if you have specified the property 
            // spring.jms.listener.receive-timeout with negative value. Otherwise, configure the above `ReceiveLocalOnly`.
            //factory.setReceiveNoWaitLocalOnly(true);
        };
    }
}

Nilai prefetch dapat memengaruhi seberapa cepat pesan dikirim ke buffer lokal konsumen. Anda harus menyesuaikan nilai sesuai dengan performa penggunaan dan volume pesan Anda. Nilai yang sesuai dapat mempercepat proses penggunaan, sementara nilai yang terlalu besar dapat menyebabkan pesan yang di-buffer secara lokal menjadi kedaluarsa dan dikirim lagi. Untuk volume pesan rendah, di mana setiap pesan membutuhkan waktu lama untuk diproses, atur prefetch ke 1. Nilai ini memastikan bahwa konsumen hanya memproses satu pesan pada satu waktu.

Solusi 2. Meningkatkan batas waktu terima untuk mengurangi frekuensi penarikan

Properti batas waktu penerimaan menentukan strategi berapa lama konsumen memblokir untuk menunggu hasil penarikan. Jadi, dengan memperpanjang batas waktu tunggu, Anda dapat mengurangi frekuensi penarikan data, sehingga menurunkan jumlah permintaan penarikan ketika Anda memilih mode pull. Dalam kasus ekstrem, Anda dapat mengatur strategi untuk menunggu tanpa batas waktu sampai pesan tiba, yang berarti konsumen hanya menarik setelah mengkonsumsi pesan. Dalam hal ini, ketika tidak ada pesan di server, itu akan memblokir untuk menunggu.

Untuk mencapai solusi ini, konfigurasikan properti spring.jms.listener.receive-timeout. Properti ini bertipe java.time.Duration dan memiliki nilai bawaan 1 detik. Daftar berikut menjelaskan efek berbagai nilai:

• Mengatur batas waktu terima ke 0 berarti bahwa blok penarikan tidak terbatas hingga pesan dikirim.
• Mengatur waktu tunggu penerimaan ke nilai positif berarti bahwa operasi pull akan terblokir hingga selama durasi batas waktu tersebut.
• Mengatur batas waktu penerimaan ke nilai negatif berarti bahwa operasi pull menjadi penerimaan tanpa menunggu, yang berarti operasi tersebut segera mengembalikan pesan, atau null jika tidak ada pesan yang tersedia.

Nota

Nilai batas waktu yang tinggi dapat membawa beberapa efek samping. Misalnya, nilai waktu tunggu yang tinggi juga akan memperpanjang waktu utas utama berada dalam status terblokir. Status ini berarti kontainer akan kurang responsif terhadap panggilan stop(), dan hanya dapat berhenti di antara panggilan receive().

Selain itu, kontainer hanya dapat mengirim permintaan setelah interval receive-timeout berlalu. Jika interval tersebut lebih dari 10 menit, Bus Layanan akan menutup koneksi dan mencegah listener untuk mengirim atau menerima. Untuk informasi selengkapnya, lihat bagian Link is closed dari AMQP errors in Azure Service Bus. Secara default, pendengar menggunakan CachingConnectionFactory.

Jika Anda memerlukan waktu tunggu penerimaan yang tinggi, pastikan untuk menggunakan JmsPoolConnectionFactory.

Untuk informasi selengkapnya tentang masalah penutupan tautan dan cara menggunakan JmsPoolConnectionFactory, lihat bagian MessageProducer ditutup karena kesalahan yang tidak dapat dipulihkan.

Masalah prefetch

Deskripsi masalah

Kebijakan prefetch yang tidak cocok dapat menyebabkan masalah berikut:

• Pesan yang sama berulang kali dikonsumsi.
• Pesan dimasukkan ke dalam antrean surat mati setelah MaxDeliveryCountExceeded, bahkan ketika pesan diproses tanpa kesalahan atau pengecualian.

Analisis penyebab

Masalah ini biasanya terjadi ketika nilai prefetch lebih tinggi daripada kapasitas konsumsi sebenarnya, sehingga terlalu banyak pesan diambil terlebih dahulu ke buffer lokal dan menunggu untuk dikonsumsi. Namun, pesan yang diambil terlebih dahulu dianggap telah dikirim dalam mode peek-lock dari sisi Bus Layanan. Setiap pesan yang dikirim memiliki max-delivery-count atribut dan lock-duration . Dalam mode terima peek-lock, pesan yang diambil ke dalam prefetch buffer diakuisisi ke dalam buffer dalam status terkunci, sementara pengatur waktu kedaluwarsa untuk kunci mulai berjalan. Jika buffer prefetch terlalu besar, dan pemrosesan memakan waktu sangat lama hingga penguncian pesan kedaluwarsa selama masih berada di buffer prefetch, pesan tersebut dianggap telah ditinggalkan dan tersedia kembali untuk diambil dari antrean.

Masalah ini dapat menyebabkan pesan diambil ke buffer prefetch dan ditempatkan di bagian akhir. Jika buffer prefetch tidak diproses sebelum masa berlaku pesan berakhir, pesan akan terus-menerus diprefetch tetapi tidak pernah benar-benar dikirim dalam keadaan yang dapat digunakan (masih memiliki kunci yang valid). Kemudian, ketika salinan yang kedaluwarsa tersebut dikeluarkan dari antrean, aplikasi berulang kali memproses pesan yang sama dan tidak dapat menyelesaikan pemrosesannya. Dalam kasus lain, pesan berulang semuanya kedaluwarsa di buffer sebelum digunakan. Dalam hal ini, pesan di Bus Layanan pada akhirnya akan dipindahkan ke antrean dead-letter setelah jumlah maksimum pengiriman terlampaui.

Untuk informasi selengkapnya, lihat bagian Mengapa Prefetch bukan opsi default? dari Prefetch pesan Azure Service Bus.

Solusi

Berhati-hatilah dalam mengonfigurasi prefetch agar sesuai dengan kapasitas konsumsi. Anda harus menyeimbangkan jumlah prefetch maksimum dan durasi kunci yang dikonfigurasi pada antrean atau langganan sedemikian rupa sehingga waktu habis penguncian setidaknya melebihi total perkiraan waktu pemrosesan pesan untuk buffer prefetch berukuran maksimum, ditambah satu pesan. Pada saat yang sama, batas waktu penguncian tidak boleh terlalu lama hingga pesan dapat melampaui masa aktif maksimumnya saat terbuang secara tidak sengaja, sehingga kunci pesan tersebut harus kedaluwarsa terlebih dahulu sebelum dikirim ulang.

Untuk mengonfigurasi atribut prefetch, yang memiliki nilai default nol, gunakan salah satu properti berikut:

Harta benda	Deskripsi
spring.jms.servicebus.prefetch.all	Nilai fallback untuk opsi prefetch di namespace Bus Layanan ini.
spring.jms.servicebus.prefetch.queue-prefetch	Nomor prefetch untuk antrean.
spring.jms.servicebus.prefetch.queue-browser-prefetch	Nomor pramuat untuk penjelajah antrean.
spring.jms.servicebus.prefetch.topic-prefetch	Nomor prefetch untuk topik tersebut.
spring.jms.servicebus.prefetch.durable-topic-prefetch	Nomor prefetch untuk topik persisten.

Bagaimana cara melakukan disposisi AMQP ke Bus Layanan?

JMS mendukung lima jenis disposisi AMQP saat mengirim konfirmasi penerimaan pesan ke broker pesan. Nilai yang didukung adalah ACCEPTED, REJECTED, RELEASED, MODIFIED_FAILED, dan MODIFIED_FAILED_UNDELIVERABLE. Untuk informasi selengkapnya, lihat bagian disposisi AMQP dan pemetaan operasi Bus Layanan bagian Menggunakan Java Message Service 1.1 dengan standar Azure Service Bus dan AMQP 1.0.

Jadi, untuk menyelesaikan, mengabaikan, mematikan, menugur, atau merilis pesan secara manual menggunakan JmsListener, gunakan langkah-langkah berikut:

1. Nonaktifkan transaksi sesi dan gunakan mode ack klien.

   Untuk menyelesaikan tugas ini, deklarasikan bean JmsListenerContainerFactory Anda sendiri lalu atur propertinya, atau lakukan post-processing pada JmsListenerContainerFactory yang didefinisikan dalam starter. Contoh berikut menggunakan pendekatan mendeklarasikan kacang lain:

   @Configuration(proxyBeanMethods = false)
   public class CustomJmsConfiguration {
   
       @Bean
       public JmsListenerContainerFactory<?> customQueueJmsListenerContainerFactory(
               DefaultJmsListenerContainerFactoryConfigurer configurer, ConnectionFactory connectionFactory) {
           DefaultJmsListenerContainerFactory jmsListenerContainerFactory = new DefaultJmsListenerContainerFactory();
           configurer.configure(jmsListenerContainerFactory, connectionFactory);
           jmsListenerContainerFactory.setPubSubDomain(Boolean.FALSE);
           jmsListenerContainerFactory.setSessionTransacted(Boolean.FALSE);
           jmsListenerContainerFactory.setSessionAcknowledgeMode(Session.CLIENT_ACKNOWLEDGE);
           return jmsListenerContainerFactory;
       }
   }
   

2. Di handler pesan Anda, selesaikan atau tinggalkan pesan secara eksplisit.

   @JmsListener(destination = "QUEUE_NAME", containerFactory = "customQueueJmsListenerContainerFactory")
   public void receiveMessage(JmsTextMessage message) throws Exception {
       String event = message.getBody(String.class);
       try {
           logger.info("Received event: {}", event);
           logger.info("Received message: {}", message);
           // by default complete the message
           message.acknowledge();
       } catch (Exception e) {
           logger.error("Exception while processing re-source event: " + event, e);
           JmsAcknowledgeCallback acknowledgeCallback = message.getAcknowledgeCallback();
           // explicitly abandon the message
           acknowledgeCallback.setAckType(MODIFIED_FAILED);
           message.setAcknowledgeCallback(acknowledgeCallback);
           message.acknowledge();
           throw e;
       }
   }
   

Masalah konfigurasi

Nonaktifkan konfigurasi otomatis JMS Bus Layanan

Deskripsi masalah

Beberapa pengguna mengimpor beberapa Spring Cloud Azure Starter untuk konfigurasi otomatis layanan Azure selain Bus Layanan JMS. Mereka juga menggunakan kerangka kerja Spring JMS tanpa perlu Bus Layanan JMS. Kemudian, ketika aplikasi mencoba memulai, pengecualian berikut dilemparkan:

Caused by: java.lang.IllegalArgumentException: 'spring.jms.servicebus.connection-string' should be provided
    at com.azure.spring.cloud.autoconfigure.jms.properties.AzureServiceBusJmsProperties.afterPropertiesSet(AzureServiceBusJmsProperties.java:210)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1863)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1800)
    ... 98 more

Analisis penyebab

Masalah ini terjadi karena semua kelas konfigurasi otomatis Spring Cloud Azure ditempatkan ke dalam modul yang sama, sehingga Setiap Spring Cloud Azure Starter benar-benar mengimpor semua konfigurasi otomatis tersebut, yang juga mencakup Azure Bus Layanan JMS. Kemudian, ketika aplikasi menggunakan Spring JMS API, aplikasi memenuhi syarat konfigurasi otomatis Azure Bus Layanan JMS dan mengaktifkannya. Kemudian, bagi pengguna yang tidak ingin menggunakan spring-cloud-azure-starter-servicebus-jms, kondisi properti tidak terpenuhi karena tidak ada alasan bagi mereka untuk mengonfigurasi Bus Layanan untuk JMS. Situasi ini menyebabkan pengecualian dilemparkan.

Solusi

Spring Cloud Azure for Bus Layanan JMS menyediakan properti untuk mengaktifkan atau menonaktifkan konfigurasi otomatisnya. Anda dapat memilih untuk menonaktifkan fungsionalitas ini sesuai kebutuhan dengan menggunakan pengaturan properti berikut:

spring.jms.servicebus.enabled=false

Konfigurasikan atribut pesan

Bagaimana cara mengatur tipe konten pesan keluar?

Untuk mengonfigurasi tipe konten, kustomisasi Pengonversi Pesan untuk mengubah atribut jenis konten saat mengonversi pesan. Kode berikut mengambil pesan byte sebagai contoh.

Pertama, kustomisasi pengonversi pesan yang akan digunakan dalam JmsTemplate, seperti yang ditunjukkan dalam contoh berikut:

public class CustomMappingJackson2MessageConverter extends MappingJackson2MessageConverter {

    public static final String CONTENT_TYPE = "application/json";

    public CustomMappingJackson2MessageConverter() {
        this.setTargetType(MessageType.BYTES);
    }

    @Override
    protected BytesMessage mapToBytesMessage(Object object, Session session, ObjectWriter objectWriter)
            throws JMSException, IOException {
        final BytesMessage message = super.mapToBytesMessage(object, session, objectWriter);
        JmsBytesMessage msg = (JmsBytesMessage) message;
        AmqpJmsMessageFacade facade = (AmqpJmsMessageFacade) msg.getFacade();
        facade.setContentType(Symbol.valueOf(CONTENT_TYPE));
        return msg;
    }
}

Kemudian, deklarasikan bean pengonversi pesan kustom Anda, seperti yang ditunjukkan dalam contoh ini:

@Configuration(proxyBeanMethods = false)
public class CustomJmsConfiguration {

    @Bean
    public MessageConverter messageConverter() {
        return new CustomMappingJackson2MessageConverter();
    }
}

Bagaimana cara mengatur nama properti ID tipe untuk MappingJackson2MessageConverter?

Atribut type-id-property-name memungkinkan MappingJackson2MessageConverter menentukan kelas mana yang akan digunakan untuk mendeserialisasi payload pesan. Saat menserialisasikan setiap objek Java ke payload Spring Message, pengonversi menyimpan jenis payload ke properti pesan dengan nama properti yang direkam oleh type-id-property-name. Kemudian, saat mendeserialisasi pesan, pengonversi membaca ID jenis dari pesan dan melakukan deserialisasi.

Untuk mengatur type-id-property-name, tentukan bean MappingJackson2MessageConverter Anda sendiri dan konfigurasikan properti tersebut, seperti yang ditunjukkan pada contoh berikut:

@Configuration(proxyBeanMethods = false)
public class CustomJmsConfiguration {

    @Bean
    public MessageConverter jacksonJmsMessageConverter()
    {
        MappingJackson2MessageConverter converter = new MappingJackson2MessageConverter();
        converter.setTypeIdPropertyName("your-custom-type-id-property-name");
        return converter;
    }
}

Deteksi duplikat

Azure Service Bus mendukung deteksi duplikat, yang menerapkan properti MessageId untuk mengidentifikasi pesan secara unik dan membuang duplikat yang dikirim ke Azure Service Bus.

Namun, untuk JMS API, Anda tidak boleh mengatur ID pesan JMS, yang dianggap sebagai ilegal dalam spesifikasi JMS. Jadi, fitur ini saat ini tidak didukung untuk Spring Cloud Azure Service Bus JMS Starter.

Untuk pembaruan lebih lanjut untuk fitur ini, lihat masalah GitHub .

Aktifkan pencatatan transpor AMQP

Untuk informasi selengkapnya, lihat bagian mengaktifkan pengelogan transportasi AMQPPemecahan Masalah Bus Layanan.

Dapatkan bantuan tambahan

Untuk informasi selengkapnya tentang cara menjangkau dukungan, lihat Dukungan di root repositori.

Sumber daya untuk starter JMS Azure Service Bus Spring Cloud

• Menggunakan Azure Service Bus dengan JMS
• Menggunakan JMS di Spring untuk mengakses Azure Service Bus
• panduan Migrasi untuk Spring Cloud Azure 4.0
• Sampel

Mengajukan masalah GitHub

Saat mengajukan masalah GitHub, detail berikut diminta:

• Konfigurasi Azure Bus Layanan/ Lingkungan Namespace
  • Namespace ini termasuk tingkat standar atau premium?
  • Jenis entitas pesan apa yang digunakan (antrean atau topik)? dan konfigurasinya.
  • Berapa ukuran rata-rata setiap Pesan?
• Seperti apa pola lalu lintasnya? (artinya, jumlah pesan per menit dan apakah Klien selalu sibuk atau memiliki periode lalu lintas yang lambat.)
• Kode dan langkah-langkah repro
  • Hal ini penting karena kita sering tidak dapat mereprodusi masalah di lingkungan kita.
• Log