Spring JMS sorun giderme kılavuzu

Bu makalede, Spring JMS kullanırken bilinen sorunları ve yaygın hataları giderme adımları açıklanmaktadır. Makale, spring-cloud-azure-starter-servicebus-jmshakkında sık sorulan bazı soruları da yanıtlar.

Bağlantı sorunları

MessageProducer kurtarılamaz bir hata nedeniyle kapatıldı

Sorun açıklaması

İleti göndermek için JmsTemplate kullanırken, JmsTemplate 10 ile 15 dakika arasında boşta kalma süresi boyunca kullanılamaz duruma gelir. Bu aralıkta ileti göndermek, aşağıdaki örnek çıktıda gösterilen özel durumları alabilir:

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]
  ...

Neden analizi

Azure Service Bus için, AMQP bağlantısı ve bağlantı etkin olduğu halde bağlantı üzerinden 10 dakika boyunca hiçbir çağrı yapılmadığında (örneğin, gönderme veya alma çağrıları), istisnalar oluşur. Bu durumda bağlantı kapatılır. Etkinlik olmadığı (boşta) ve 5 dakika içinde yeni bir bağlantı oluşturulmadığı için bağlantıdaki tüm bağlantılar kapatıldığında bağlantı kapatılır.

Service Bus JMS başlatıcısı için, oturumu, üreticiyi ve tüketiciyi önbelleğe alan CachingConnectionFactory varsayılan olarak kullanılır. JmsProducer, 10 dakikadan uzun ancak 15 dakikadan kısa bir süre boyunca boşta kaldığında, önbelleğe alınmış üreticinin kullanmakta olduğu bağlantı kapatılmış olur. İletiler bu aralıkta gönderilemiyor. Ardından, 5 dakika daha boşta kaldıktan sonra tüm bağlantı kapatılır. Bu nedenle, 15 dakikalık boşta kalma aralığından sonraki herhangi bir gönderme işlemi, CachingConnectionFactory gönderilecek yeni bir bağlantı oluşturmasına neden olur. Gönderme işlemi 15 dakika sonra kullanılabilir hale gelir.

Geçici çözüm

Starter şu anda, Connection, Session ve MessageProducer öğelerini havuzlayan ve havuzlanan örneklerin yaşam döngüsünü yöneten JmsPoolConnectionFactory uygulayarak bağlantı ayırma sorununa geçici bir çözüm sunar. Bu geçici çözüm, bir üreticinin kullanılamaz duruma geldikten sonra çıkarılmasını ve böylece tüm gönderme işlemlerinin aktif üreticiler tarafından gerçekleştirilmesini sağlayabilir.

Bu geçici çözümü kullanmak için aşağıdaki yapılandırmayı ekleyin:

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

spring.jms.servicebus.idle-timeout kullanımı

Boşta kalma zaman aşımı özellikleri, bir AMQP bağlantısının boşta kalma zaman aşımını yapılandırır. AMQP belirtimi aşağıdaki açıklamayı sağlar:

Bağlantılar boşta kalma zaman aşımı eşiğine tabidir. Zaman aşımı, eşik değer aşıldıktan sonra hiçbir çerçeve alınmazsa yerel bir uç tarafından tetiklenir. Boşta kalma zaman aşımı milisaniye cinsinden ölçülür ve son çerçevenin alındığı zamandan itibaren başlar. Eşik aşılırsa, bir eş nedenini açıklayan bir hata kodu içeren bir kapatma çerçevesi kullanarak bağlantıyı düzgün bir şekilde kapatmayı denemelidir. Uzak eş buna belirli bir eşik süre içinde uygun biçimde yanıt vermezse, eş TCP soketini kapatabilir.

Bir JMS istemcisi için, bu özelliği yapılandırdığınızda, sunucu tarafında hiçbir ileti teslim edildiğinde bağlantının canlı kalmasını sağlamak için sunucunun boş bir çerçeve göndermesini ne kadar bekleyeceğinizi denetlersiniz. Bu özellik uzak eş davranışını denetler ve her eş kendi yalıtılmış değerine sahip olabilir.

JmsTemplate sorunları

Zamanlanmış iletiler

Azure Service Bus gecikmeli ileti işlemeyi destekler. Daha fazla bilgi için İleti sıralama ve zaman damgalarıZamanlanmış iletiler bölümüne bakın. JMS için, bir iletiyi zamanlamak üzere x-opt-scheduled-enqueue-time ileti ek açıklaması üst bilgisini kullanarak ScheduledEnqueueTimeUtc özelliğini ayarlayın.

JmsListener sorunları

Sunucuda ileti olmamasına rağmen Service Bus'a çok fazla istek gönderiliyor

Sorun açıklaması

@JmsListener API'sini kullanırken, bazı durumlarda Azure portalında, sunucuda alacak ileti olmasa bile kuyruğuna veya konu başlıklarına gönderilen gelen istekler için sürekli değerler olduğunu görebilirsiniz.

Neden analizi

@JmsListener, yinelenen yoklama girişimleri için oluşturulmuş bir yoklama dinleyicisidir.

Dinleyici, devam eden bir yoklama döngüsünde yer alır. Her döngü, yerel tüketiciyi tüketeceği iletiler için yoklamak üzere JMS MessageConsumer.receive() yöntemini çağırır. Varsayılan olarak, her yoklama işleminde yerel tüketici, iletileri istemek için ileti aracısına çekme istekleri gönderir ve ardından belirli bir süre boyunca beklemede kalır. Beton yoklama işlemi, receiveTimeout, prefetchSizeve receiveLocalOnly veya receiveNoWaitLocalOnlygibi çeşitli özelliklerle belirlenir. receiveNoWaitLocalOnly yöntemi yalnızca receiveTimeout negatif bir değere ayarladığınızda kullanılır.

Bu sorun uygulamanıza oluştuğunda aşağıdaki yapılandırma ayarlarını denetleyin:

  • Önceden getirme ilkenizin aynı zamanda varsayılan seçenek olan 0 olup olmadığını belirleyin. 0-prefetch, her anket için Service Bus'a çekme istekleri gönderen bir çekme tüketicisi anlamına gelir.

  • Sıfır olmayan bir prefetch yapılandırdıysanız, receiveLocalOnly veya receiveNoWaitLocalOnly özelliğinizin varsayılan seçenek olan false olarak ayarlı olup olmadığını belirleyin. Buradaki false değeri yine de sunucuya çekme istekleri gönderilmesine neden olur, çünkü yalnızca yerel tüketiciyi yoklamakla kalmaz.

  • receiveTimeout yapılandırması, her çekme isteğinin ne kadar süreyle engelleneceğini belirler, bu nedenle sunucuya gönderilen çekme isteklerinin sıklığını etkileyebilir. Varsayılan değer 1 saniyedir.

Tam bir analiz içinGitHub sorunundaki tartışmaya bakın.

Çözümleri

Aşağıdaki bölümlerde bu sorunla başa çıkmak için iki çözüm açıklanmaktadır

Çözüm 1. Tüketiciyi göndermek ve yalnızca yerel denetim yapmak için değiştirin

Modu push olarak değiştirildiğinde tüketici, broker’dan mesaj çekmeyen ancak hedeflenen miktarda bağlantı kredisi koruyan bir Asenkron Bildirim tüketicisi hâline gelir. Tutar, bir prefetch özelliği tarafından belirlenir. Service Bus (gönderen) iletileri gönderirken, gönderenin bağlantı kredisi azalır ve gönderenin bağlantı kredisi eşiğin altına düştüğünde, istemci (alıcı) gönderenin bağlantı kredisini istenen hedef tutara geri döndürmek için sunucuya bir istek gönderir.

Bu çözümü gerçekleştirmek için aşağıdaki yapılandırmayı ekleyin:

İlk olarak, prefetch sayısını sıfırdan farklı olacak şekilde ayarlayın; bu, tüketiciyi pull olmayan olarak yapılandırır. Aşağıdaki tabloda, her biri farklı Service Bus varlıklarını denetleyen çeşitli prefetch özellikleri gösterilmektedir. Talebinize uygulanacak özellikleri ayarlayın.

Mülk Açıklama
spring.jms.servicebus.prefetch.all Bu Service Bus ad alanında prefetch seçeneğinin geri dönüş değeri
spring.jms.servicebus.prefetch.queue-prefetch Kuyruğun ön koşul numarası.
spring.jms.servicebus.prefetch.queue-browser-prefetch Kuyruk tarayıcısının ön koşul numarası.
spring.jms.servicebus.prefetch.topic-prefetch Konu için ön koşul numarası.
spring.jms.servicebus.prefetch.durable-topic-prefetch Dayanıklı konu için ön koşul numarası.

İkinci olarak, aşağıdaki örnekte gösterildiği gibi fabrika özelleştiricisi için bir yapılandırma sınıfı ekleyerek non-local-check yapılandırın:

@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);
        };
    }
}

Önceden getirme değeri, iletilerin tüketicinin yerel arabelleğine ne kadar hızlı gönderileceğini etkileyebilir. Değeri, tüketim performansınıza ve ileti hacminize göre ayarlamanız gerekir. Uygun bir değer tüketim sürecini hızlandırabilirken, çok büyük bir değer yerel olarak arabelleğe alınan iletilerin güncelliğini yitirip yeniden iletilmesine neden olabilir. Düşük ileti hacimlerinde, her iletinin işlenmesi uzun sürüyorsa önceden getirme değerini 1 olarak ayarlayın. Bu değer, tüketicinin bir kerede yalnızca bir iletiyi işlemesini sağlar.

Çözüm 2. Çekme sıklığını azaltmak için alma zaman aşımı süresini artırın

Alma zaman aşımı özelliği, tüketicinin çekme sonucunu ne kadar süreyle bekleyeceğine ilişkin stratejiyi belirler. Bu nedenle, zaman aşımını genişleterek çekme sıklığını azaltabilir ve ardından çekme modunu seçtiğinizde çekme isteklerinin sayısını azaltabilirsiniz. Aşırı durumlarda, bir ileti gelene kadar süresiz bekleme stratejisini ayarlayabilirsiniz; bu da tüketicinin yalnızca bir iletiyi kullandıktan sonra çekmesi anlamına gelir. Bu durumda, sunucuda ileti olmadığında beklemeyi engeller.

Bu çözümü gerçekleştirmek için spring.jms.listener.receive-timeout özelliğini yapılandırın. Bu özellik java.time.Duration türündedir ve varsayılan değeri 1 saniyedir. Aşağıdaki listede çeşitli değerlerin etkisi açıklanmaktadır:

  • Alma zaman aşımı süresinin 0 olarak ayarlanması, bir mesaj gönderilene kadar pull işleminin süresiz olarak beklemede kalacağı anlamına gelir.
  • Alma zaman aşımını pozitif bir değere ayarlamak, çekme işleminin zaman aşımı süresi dolana kadar bloklanacağı anlamına gelir.
  • Alma zaman aşımını negatif bir değere ayarlamak, çekme işleminin beklemeyen bir alma olduğu anlamına gelir; bu da hemen bir ileti döndürdüğü veya kullanılabilir ileti yoksa null anlamına gelir.

Not

Yüksek bir zaman aşımı değeri bazı yan etkiler getirebilir. Örneğin, yüksek bir zaman aşımı değeri de ana iş parçacığının blok durumundaki süresini uzatır. Bu durum, kapsayıcının stop() çağrılara daha az yanıt verebileceği ve yalnızca receive() çağrıları arasında durabileceği anlamına gelir.

Ayrıca kapsayıcı yalnızca receive-timeout aralığı geçtikten sonra istek gönderebilir. Aralık 10 dakikadan uzunsa, Service Bus bağlantıyı kapatır ve dinleyicinin göndermesini veya almasını engeller. Daha fazla bilgi için, Azure Service Bus'ta AMQP hataları konusundaki Bağlantı kapalı bölümüne bakın. Dinleyici varsayılan olarak CachingConnectionFactorykullanır.

Uzun bir alma zaman aşımı süresine ihtiyacınız varsa, JmsPoolConnectionFactory kullandığınızdan emin olun.

Bağlantı kapatma sorunu ve JmsPoolConnectionFactory öğesinin nasıl kullanılacağı hakkında daha fazla bilgi için MessageProducer kurtarılamaz bir hata nedeniyle kapatıldı bölümüne bakın.

Önceden yükleme sorunu

Sorun açıklaması

Uygun olmayan bir ön koşul ilkesi aşağıdaki sorunlara neden olabilir:

  • Aynı iletiler tekrar tekrar tüketilir.
  • İletiler, hata veya özel durum oluşmadan işlendiğinde bile, MaxDeliveryCountExceeded sonrasında teslim edilemeyen ileti kuyruğuna alınır.

Neden analizi

Bu sorun genellikle, prefetch değeri gerçek tüketim kapasitesinden yüksek olduğunda ortaya çıkar; bunun sonucunda, tüketilmeyi bekleyen çok fazla mesaj yerel arabelleğe önceden getirilir. Ancak, önceden getirilen iletiler Service Bus tarafında peek-lock modunda gönderilmiş olarak değerlendirilir. Dağıtılan her iletinin bir max-delivery-count ve lock-duration öznitelikleri vardır. peek-lock alma modunda, önceden getirme arabelleğine alınan iletiler arabelleğe kilitli durumda alınır ve kilidin zaman aşımı süresi işlemeye devam eder. Önceden getirme arabelleği büyükse ve işleme süresi, iletiler önceden getirme arabelleğinde beklerken ileti kilitlerinin süresi dolacak kadar uzunsa, ileti terk edilmiş olarak değerlendirilir ve kuyruktan yeniden alınmak üzere kullanılabilir duruma getirilir.

Bu sorun, iletinin önceden getirme arabelleğine çekilmesine ve en sona yerleştirilmesine neden olabilir. Önceden getirme arabelleği, iletinin süresi dolmadan önce işlenmezse iletiler tekrar tekrar önceden getirilir, ancak kullanılabilir (geçerli biçimde kilitlenmiş) bir durumda hiçbir zaman etkili şekilde teslim edilmez. Ardından, bu eski kopyalar kuyruktan çıkarıldığında uygulama aynı mesajı tekrar tekrar işler ve bunları tamamlayamaz. Başka bir durumda, yinelenen iletilerin tümünün, tüketilmeden önce arabellekte süreleri dolar. Bu durumda, Service Bus'taki ileti, en yüksek teslim sayısı aşıldıktan sonra nihayetinde teslim edilemeyen iletiler kuyruğuna taşınacaktır.

Daha fazla bilgi için Azure Service Bus iletilerini önceden getirme konusundaki Prefetch neden varsayılan seçenek değildir? bölümüne bakın.

Çözüm

Prefetch yapılandırmasının tüketim kapasitesine uygun olduğundan emin olun. Maksimum önceden getirme sayısı ile kuyruk veya abonelik için yapılandırılan kilit süresini, kilit zaman aşımı süresi maksimum önceden getirme arabelleği boyutu artı bir ileti için beklenen kümülatif ileti işleme süresinden en az daha uzun olacak şekilde dengelemeniz gerekir. Aynı zamanda, kilit zaman aşımı, iletilerin yanlışlıkla bırakıldığında yaşam süresi üst sınırını aşması ve böylece yeniden teslim edilmeden önce kilitlerinin süresinin dolmasını gerektirmesi gibi uzun olmamalıdır.

Varsayılan değeri sıfır olan prefetch özniteliğini yapılandırmak için aşağıdaki özelliklerden birini kullanın:

Mülk Açıklama
spring.jms.servicebus.prefetch.all Bu Service Bus ad alanındaki prefetch seçeneğinin yedek değeri.
spring.jms.servicebus.prefetch.queue-prefetch Kuyruk için önceden getirme numarası.
spring.jms.servicebus.prefetch.queue-browser-prefetch Kuyruk tarayıcısının ön koşul numarası.
spring.jms.servicebus.prefetch.topic-prefetch Konu için ön koşul numarası.
spring.jms.servicebus.prefetch.durable-topic-prefetch Dayanıklı konu için ön koşul numarası.

Service Bus'a AMQP dağıtımı nasıl yapılır?

JMS, mesajlaşma aracısına ileti onaylarken beş AMQP değerlendirme türünü destekler. Desteklenen değerler ACCEPTED, REJECTED, RELEASED, MODIFIED_FAILEDve MODIFIED_FAILED_UNDELIVERABLE'dır. Daha fazla bilgi için Azure Service Bus Standard ve AMQP 1.0 ile Java Message Service 1.1 kullanma belgesinin AMQP disposition ve Service Bus işlemi eşlemesi bölümüne bakın.

Bu durumda, JmsListener kullanarak bir mesajı el ile tamamlamak, vazgeçmek, ölü mektup kuyruğuna taşımak, ertelemek veya serbest bırakmak için aşağıdaki adımları izleyin:

  1. Oturum işlemeyi devre dışı bırakın ve client ack modunu kullanın.

    Bu görevi gerçekleştirmek için ya kendi JmsListenerContainerFactory bean'inizi tanımlayıp ardından özellikleri ayarlayın ya da starter içinde tanımlanan JmsListenerContainerFactory öğesini sonradan işleyin. Aşağıdaki örnek, başka bir bean tanımlama yaklaşımını kullanır:

    @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. İleti işleyicinizde iletileri açıkça tamamlayın veya bırakın.

    @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;
    }
}

Yapılandırma sorunları

Service Bus JMS otomatik yapılandırmayı devre dışı bırakma

Sorun açıklaması

Bazı kullanıcılar, Service Bus JMS dışında bir Azure hizmetinin otomatik yapılandırması için spring cloud Azure Starter'ı içeri aktarır. Ayrıca Service Bus JMS'ye gerek kalmadan Spring JMS çerçevesini de kullanırlar. Ardından, uygulama başlatılmaya çalışıldığında aşağıdaki özel durumlar fırlatılır:

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

Neden analizi

Bu sorun, tüm Spring Cloud Azure otomatik yapılandırma sınıflarının aynı modüle yerleştirilmesinden kaynaklandığından, tüm Spring Cloud Azure Starter aslında Service Bus JMS'yi de içeren tüm otomatik yapılandırmayı içeri aktarır. Ardından uygulama Spring JMS API'sini kullandığında Service Bus JMS otomatik yapılandırma koşulunu karşılar ve tetikler. Ardından, spring-cloud-azure-starter-servicebus-jmskullanmayı amaçlamayan kullanıcılar için özellik koşulları karşılanmaz çünkü JMS için Service Bus'ı yapılandırmaları için bir neden yoktur. Bu durum, istisnaların atılmasına neden olur.

Çözüm

Service Bus için Spring Cloud Azure JMS, otomatik yapılandırmayı açmak veya kapatmak için bir özellik sağlar. Aşağıdaki özellik ayarını kullanarak bu işlevi gerektiği gibi devre dışı bırakabilirsiniz:

spring.jms.servicebus.enabled=false

İleti özniteliklerini yapılandırma

Giden iletilerin içerik türü nasıl ayarlanır?

İçerik türünü yapılandırmak için İleti Dönüştürücüsü'nü özelleştirerek iletileri dönüştürürken içerik türü özniteliğini değiştirin. Aşağıdaki kod, bayt iletilerini örnek olarak alır.

İlk olarak, aşağıdaki örnekte gösterildiği gibi JmsTemplateiçinde kullanılacak ileti dönüştürücüsİnİ özelleştirin:

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;
    }
}

Ardından, bu örnekte gösterildiği gibi özelleştirilmiş ileti dönüştürücü çekirdeğinizi bildirin:

@Configuration(proxyBeanMethods = false)
public class CustomJmsConfiguration {

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

MappingJackson2MessageConverter için tür kimliği özellik adı nasıl ayarlanır?

type-id-property-name özniteliği, MappingJackson2MessageConverter ileti yükünü seri durumdan çıkarmak için hangi sınıfın kullanılacağını belirlemesini sağlar. Her Java nesnesini bir Spring Message yüküne serileştirirken, dönüştürücü yük türünü, adı type-id-property-name tarafından kaydedilen bir ileti özelliğine depolar. Ardından, iletiyi seri durumdan çıkarırken, dönüştürücü iletiden tür kimliğini okur ve seri durumdan çıkarma gerçekleştirir.

type-id-property-nameayarlamak için, aşağıdaki örnekte gösterildiği gibi kendi MappingJackson2MessageConverter fasulyenizi bildirin ve bu özelliği yapılandırın:

@Configuration(proxyBeanMethods = false)
public class CustomJmsConfiguration {

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

Yinelenenleri algılama

Azure Service Bus, iletileri benzersiz olarak tanımlamak ve Service Bus'a gönderilen yinelenen iletileri atmak için özelliğini uygulayan yinelenen algılamayı destekler.

Ancak JMS API'si için JMS belirtimlerinde geçersiz olarak kabul edilen JMS ileti kimliğini ayarlamamalısınız. Bu nedenle bu özellik şu anda Spring Cloud Azure Service Bus JMS Starter için desteklenmemektedir.

Bu özellikle ilgili sonraki güncellemeler için GitHub bildirimine bakın.

AMQP taşıma günlüğünü etkinleştir

Daha fazla bilgi için Service Bus sorunlarını giderme konusundaki AMQP aktarım günlüğünü etkinleştirme bölümüne bakın.

Ek yardım alın

Destek almak için iletişime geçme yolları hakkında daha fazla bilgi için deponun kök dizinindeki Support bölümüne bakın.

Spring Cloud Azure Service Bus JMS starter kaynakları

  • JMS ile Azure Service Bus kullanma
  • Azure Service Bus erişmek için Spring'de JMS kullanma
  • Spring Cloud Azure 4.0 için Geçiş kılavuzu
  • Örnek

GitHub sorunlarını dosyalama

GitHub sorunlarını bildirirken aşağıdaki ayrıntılar istenir:

  • Service Bus yapılandırması / Ad alanı ortamı
    • Ad alanı (standart veya premium) hangi katmandır?
    • Hangi tür mesajlaşma varlığı kullanılıyor (kuyruk veya konu)? ve yapılandırması.
    • Her iletinin ortalama boyutu nedir?
  • Trafik düzeni nasıldır? (diğer bir ifadeyle dakika başına ileti sayısı ve İstemcinin her zaman meşgul olup olmadığı veya trafik dönemlerinin yavaş olup olmadığı.)
  • Yeniden oluşturma kodu ve adımları
    • Bu, sorunu genellikle ortamımızda yeniden oluşturamadığımız için önemlidir.
  • Günlükler
  • Son güncelleştirme: