Przewodnik rozwiązywania problemów z programem Spring JMS

W tym artykule opisano sposób rozwiązywania znanych problemów i typowych błędów podczas korzystania z programu Spring JMS. Artykuł zawiera również odpowiedzi na kilka często zadawanych pytań dotyczących spring-cloud-azure-starter-servicebus-jms.

Problemy z łącznością

Element MessageProducer został zamknięty z powodu nieodwracalnego błędu

Opis problemu

W przypadku używania JmsTemplate do wysyłania komunikatów JmsTemplate staje się niedostępna w okresie bezczynności od 10 do 15 minut. Wysyłanie komunikatów w tym interwale może uzyskać wyjątki wyświetlane w następujących przykładowych danych wyjściowych:

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

Analiza przyczyny

Wyjątki występują w przypadku usługi Azure Service Bus, gdy połączenie i link protokołu AMQP są aktywne, ale żadne wywołania — na przykład wysyłanie lub odbieranie połączeń — są wykonywane przy użyciu linku przez 10 minut. W takim przypadku link jest zamknięty. A gdy wszystkie linki w połączeniu zostały zamknięte, ponieważ nie było aktywności (bezczynności), a nowe łącze nie zostało utworzone w ciągu 5 minut, połączenie jest zamknięte.

W przypadku szablonu startowego JMS usługi Service Bus domyślnie jest używana CachingConnectionFactory, która buforuje sesję, producenta i konsumenta. Gdy JmsProducer jest bezczynna przez ponad 10 minut, ale mniej niż 15, link, który zajmuje producent w pamięci podręcznej, został zamknięty. W tym interwale nie można wysyłać komunikatów. Następnie po upływie kolejnych 5 minut bezczynności całe połączenie zostanie zamknięte. W związku z tym każda operacja wysyłania po 15-minutowym interwale bezczynności powoduje, że CachingConnectionFactory utworzyć nowe połączenie do wysłania. Operacja wysyłania staje się dostępna po 15 minutach.

Obejście

Obecnie starter zapewnia obejście problemu z odłączaniem łącza przez zastosowanie JmsPoolConnectionFactory, które pule Connection, Sessioni MessageProduceroraz zarządza cyklem życia wystąpień w puli. To obejście może zapewnić, że producent jest eksmitowany po niedostępności, dlatego wszystkie operacje wysyłania są wykonywane na aktywnych producentów.

Aby użyć tego obejścia, dodaj następującą konfigurację:

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

Użycie `spring.jms.servicebus.idle-timeout`

Właściwości limitu czasu bezczynności konfigurują limit czasu bezczynności połączenia usługi AMQP. Specyfikacja protokołu AMQP zawiera następujący opis:

Połączenia podlegają progowi limitu czasu bezczynności. Limit czasu jest wyzwalany przez lokalny element równorzędny, gdy nie zostaną odebrane żadne ramki po przekroczeniu wartości progowej. Limit czasu bezczynności jest mierzony w milisekundach i rozpoczyna się od momentu odebrania ostatniej ramki. Jeśli próg zostanie przekroczony, element równorzędny POWINIEN spróbować bezpiecznie zamknąć połączenie przy użyciu ścisłej ramki z błędem wyjaśniającym, dlaczego. Jeśli zdalny element równorzędny nie odpowiada bezpiecznie w ramach progu, element równorzędny MOŻE zamknąć gniazdo TCP.

W przypadku klienta JMS podczas konfigurowania tej właściwości można kontrolować po stronie serwera, jak długo oczekujesz, że serwer będzie wysyłać pustą ramkę, aby zachować połączenie aktywne, gdy nie są dostarczane żadne komunikaty. Ta właściwość steruje zachowaniem zdalnej komunikacji równorzędnej, a każdy element równorzędny może mieć własną, izolowana wartość.

Problemy z platformą JmsTemplate

Zaplanowane komunikaty

Usługa Azure Service Bus obsługuje opóźnione przetwarzanie komunikatów. Aby uzyskać więcej informacji, zobacz sekcję Zaplanowane komunikaty sekwencjonowanie komunikatów i znaczniki czasu. W przypadku programu JMS, aby zaplanować komunikat, ustaw właściwość ScheduledEnqueueTimeUtc przy użyciu nagłówka adnotacji komunikatu x-opt-scheduled-enqueue-time.

Problemy z programem JmsListener

Zbyt wiele żądań jest wysyłanych do usługi Service Bus, mimo że na serwerze nie ma żadnych komunikatów

Opis problemu

W przypadku korzystania z interfejsu API @JmsListener w niektórych przypadkach można zobaczyć w witrynie Azure Portal, że istnieją bieżące wartości żądań przychodzących wysyłanych do kolejki lub tematów, nawet jeśli na serwerze nie ma komunikatów do odbierania.

Analiza przyczyny

@JmsListener to odbiornik sondowania, który jest zbudowany na potrzeby powtarzających się prób sondowania.

Odbiornik znajduje się w trwającej pętli sondowania. Każda pętla wywołuje metodę MessageConsumer.receive() JMS w celu sondowania odbiorcy lokalnego pod kątem korzystania z komunikatów. Domyślnie dla każdej operacji sondowania odbiorca lokalny wysyła żądania ściągnięcia do brokera komunikatów, aby poprosić o komunikaty, a następnie blokuje go przez określony czas. Konkretny proces sondowania jest rozstrzygany przez kilka właściwości, w tym receiveTimeout, prefetchSizei receiveLocalOnly lub receiveNoWaitLocalOnly. Metoda receiveNoWaitLocalOnly jest używana tylko wtedy, gdy ustawisz receiveTimeout na wartość ujemną.

Jeśli ten problem występuje w aplikacji, sprawdź następujące ustawienia konfiguracji:

Określ, czy zasady pobierania wstępnego mają wartość 0, która jest również opcją domyślną. 0-prefetch oznacza odbiorcę ściągania, który wysyła żądania ściągnięcia do usługi Service Bus dla każdej ankiety.
Jeśli skonfigurowano pobieranie wstępne inne niż zero, określ, czy właściwość receiveLocalOnly czy receiveNoWaitLocalOnly jest ustawiona na wartość false, która jest opcją domyślną. Wartość false w tym miejscu nadal powoduje wysyłanie żądań ściągnięcia do serwera, ponieważ nie tylko sonduje lokalnego konsumenta.
Konfiguracja receiveTimeout określa, jak długo blokuje każde żądanie ściągnięcia, dzięki czemu może mieć wpływ na częstotliwość wysyłania żądań ściągnięcia do serwera. Wartość domyślna to 1 sekunda.

Aby uzyskać pełną analizę, zobacz dyskusję w problem z usługą GitHub.

Rozwiązania

W poniższych sekcjach opisano dwa rozwiązania dotyczące tego problemu

Rozwiązanie 1. Zmiana w celu wypychania tylko odbiorcy i sprawdzania lokalnego

Zmieniając tryb na push, użytkownik staje się klientem asynchronicznym powiadomieniem konsumentem, który nie ściąga komunikatów z brokera, ale utrzymuje docelową kwotę środków na łącze. Kwota jest ustalana przez właściwość pobierania z góry. Gdy usługa Service Bus (nadawca) wypycha komunikaty, środki związane z łączem nadawcy maleją, a gdy środki na połączenie nadawcy spadną poniżej progu, klient (odbiorca) wysyła żądanie do serwera w celu zwiększenia środków na połączenie nadawcy z powrotem do żądanej kwoty docelowej.

Aby wykonać to rozwiązanie, dodaj następującą konfigurację:

Najpierw skonfiguruj numer prefetch jako niezerowy, który konfiguruje użytkownika jako nieciągnięty. W poniższej tabeli przedstawiono kilka właściwości pobierania wstępnego, z których każda kontroluje różne jednostki usługi Service Bus. Ustaw właściwości, które mają zastosowanie do twojego przypadku.

Własność	Opis
`spring.jms.servicebus.prefetch.all`	Wartość rezerwowa opcji pobierania wstępnego w tej przestrzeni nazw usługi Service Bus
`spring.jms.servicebus.prefetch.queue-prefetch`	Numer pobierania wstępnego dla kolejki.
`spring.jms.servicebus.prefetch.queue-browser-prefetch`	Numer pobierania wstępnego przeglądarki kolejki.
`spring.jms.servicebus.prefetch.topic-prefetch`	Numer pobierania wstępnego tematu.
`spring.jms.servicebus.prefetch.durable-topic-prefetch`	Numer pobierania wstępnego dla tematu trwałego.

Po drugie skonfiguruj non-local-check, dodając klasę konfiguracji dla konfiguratora fabryki, jak pokazano w poniższym przykładzie:

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

Wartość pobierania wstępnego może mieć wpływ na szybkość wysyłania komunikatów do lokalnego buforu odbiorcy. Należy dostosować wartość zgodnie z zużywaną wydajnością i woluminami komunikatów. Odpowiednia wartość może przyspieszyć proces zużywania, a wartość, która jest zbyt duża, może spowodować, że komunikaty buforowane lokalnie staną się nieaktualne i ponownie wysłane. W przypadku małych woluminów komunikatów, w przypadku których przetwarzanie każdego komunikatu zajmuje dużo czasu, ustaw wartość prefetch na 1. Ta wartość gwarantuje, że użytkownik przetwarza tylko jeden komunikat naraz.

Rozwiązanie 2. Zwiększ limit czasu odbierania, aby zmniejszyć częstotliwość ściągania

Właściwość limitu czasu odbierania określa strategię czasu oczekiwania na wynik ściągnięcia przez bloki odbiorcy. Dlatego przez wydłużenie limitu czasu można zmniejszyć częstotliwość ściągania, a następnie zmniejszyć liczbę żądań ściągnięcia po wybraniu trybu ściągnięcia. W skrajnych przypadkach można ustawić strategię oczekiwania na czas nieokreślony do odebrania komunikatu, co oznacza, że odbiorca pobiera tylko po użyciu komunikatu. W takim przypadku, gdy na serwerze nie ma żadnych komunikatów, będzie blokować oczekiwanie.

Aby wykonać to rozwiązanie, skonfiguruj właściwość spring.jms.listener.receive-timeout. Ta właściwość jest typu java.time.Duration i ma domyślną wartość 1 sekundy. Poniższa lista wyjaśnia efekt różnych wartości:

Ustawienie limitu czasu odbierania na 0 oznacza, że bloki ściągnięcia na czas nieokreślony do momentu wysłania komunikatu.
Ustawienie limitu czasu odbierania na wartość dodatnią oznacza, że ściąganie blokuje limit czasu do limitu czasu.
Ustawienie limitu czasu odbierania na wartość ujemną oznacza, że ściągnięcie jest odbieraniem bez oczekiwania, co oznacza, że zwraca komunikat natychmiast lub null, jeśli żadne komunikaty nie są dostępne.

Nuta

Wysoka wartość limitu czasu może przynieść pewne skutki uboczne. Na przykład wartość wysokiego limitu czasu wydłuży również czas, przez który główny wątek znajduje się w stanie bloku. Ten stan oznacza, że kontener będzie mniej reagował na wywołania stop() i może zatrzymać się tylko między receive() wywołaniami.

Ponadto kontener może wysyłać żądania tylko po upływie interwału receive-timeout. Jeśli interwał jest dłuższy niż 10 minut, usługa Service Bus zamknie łącze i uniemożliwi odbiornikowi wysyłanie lub odbieranie. Aby uzyskać więcej informacji, zobacz sekcję Link jest zamknięta sekcji błędów protokołu AMQP w usłudze Azure Service Bus. Domyślnie odbiornik używa CachingConnectionFactory.

Jeśli potrzebujesz wysokiego limitu czasu odbierania, pamiętaj, aby użyć JmsPoolConnectionFactory.

Aby uzyskać więcej informacji na temat problemu z zamknięciem łącza i sposobu używania JmsPoolConnectionFactory, zobacz KomunikatProducer został zamknięty z powodu nieodwracalnego błędu sekcji.

Problem z pobieraniem wstępnym

Opis problemu

Nieodpowiednie zasady pobierania wstępnego mogą powodować następujące problemy:

Te same komunikaty są wielokrotnie używane.
Komunikaty są umieszczane w kolejce utraconych wiadomości po MaxDeliveryCountExceeded, nawet gdy komunikaty są przetwarzane bez błędu lub wyjątku.

Analiza przyczyny

Ten problem zwykle występuje, gdy prefetch wartość jest wyższa niż rzeczywista pojemność zużywana, z efektem, że zbyt wiele komunikatów jest wstępnie pobieranych do buforu lokalnego oczekującego na użycie. Jednak pobrane wstępnie komunikaty są wyświetlane jako wysyłane w peek-lock trybie po stronie usługi Service Bus. Każdy wysłany komunikat ma max-delivery-count atrybuty i .lock-duration peek-lock W trybie odbierania komunikaty pobierane do buforu pobierania wstępnego są pobierane do buforu w stanie zablokowanym z zegarem limitu czasu dla tykania blokady. Jeśli bufor pobierania wstępnego jest duży, a przetwarzanie trwa tak długo, że blokady komunikatów wygasają podczas pozostawania w buforze pobierania wstępnego, komunikat jest traktowany jako porzucony i ponownie udostępniany do pobierania z kolejki.

Ten problem może spowodować pobranie komunikatu do buforu pobierania wstępnego i umieszczenie go na końcu. Jeśli bufor pobierania wstępnego nie jest przetwarzany przed wygaśnięciem komunikatu, komunikaty są wielokrotnie pobierane wstępnie, ale nigdy nie są skutecznie dostarczane w stanie użytecznym (prawidłowym zablokowaniu). Następnie po usunięciu tych nieaktualnych kopii aplikacja wielokrotnie używa tego samego komunikatu i nie jest w stanie ich ukończyć. W innym przypadku powtarzające się komunikaty wygasły w buforze przed zużyciem. W takim przypadku komunikat w usłudze Service Bus zostanie ostatecznie przeniesiony do kolejki utraconych komunikatów po przekroczeniu maksymalnej liczby dostaw.

Aby uzyskać więcej informacji, zobacz Dlaczego pobieranie wstępne nie jest opcją domyślną? sekcji komunikatów usługi Azure Service Bus przed pobraniem.

Rozwiązanie

Należy zachować ostrożność podczas konfigurowania pobierania wstępnego, aby upewnić się, że pasuje do możliwości zużywania. Musisz zrównoważyć maksymalną liczbę pobrań wstępnych i czas trwania blokady skonfigurowany w kolejce lub subskrypcji, tak aby limit czasu blokady co najmniej przekracza skumulowany oczekiwany czas przetwarzania komunikatów dla maksymalnego rozmiaru buforu pobierania przed pobraniem oraz jeden komunikat. Jednocześnie limit czasu blokady nie powinien być tak długi, że komunikaty mogą przekraczać maksymalny czas wygaśnięcia, gdy zostaną przypadkowo usunięte, co wymaga wygaśnięcia blokady przed ponownym wysłaniem.

Aby skonfigurować atrybut pobierania wstępnego, który ma wartość domyślną zero, użyj jednej z następujących właściwości:

Własność	Opis
`spring.jms.servicebus.prefetch.all`	Wartość rezerwowa opcji pobierania wstępnego w tej przestrzeni nazw usługi Service Bus.
`spring.jms.servicebus.prefetch.queue-prefetch`	Numer pobierania wstępnego dla kolejki.
`spring.jms.servicebus.prefetch.queue-browser-prefetch`	Numer pobierania wstępnego przeglądarki kolejki.
`spring.jms.servicebus.prefetch.topic-prefetch`	Numer pobierania wstępnego tematu.
`spring.jms.servicebus.prefetch.durable-topic-prefetch`	Numer pobierania wstępnego dla tematu trwałego.

Jak wykonać dyspozycję protokołu AMQP w usłudze Service Bus?

Program JMS obsługuje pięć typów dyspozycji protokołu AMQP podczas potwierdzania komunikatów brokerowi obsługi komunikatów. Obsługiwane wartości to ACCEPTED, REJECTED, RELEASED, MODIFIED_FAILEDi MODIFIED_FAILED_UNDELIVERABLE. Aby uzyskać więcej informacji, zobacz sekcję mapowania operacji amQP i service Bus używanie usługi Java Message Service 1.1 ze standardem usługi Azure Service Bus iamQP 1.0.

Dlatego w celu ręcznego ukończenia, porzucenia, utraconych komunikatów, odroczenia lub wydania wiadomości przy użyciu JmsListenerwykonaj następujące czynności:

Wyłącz transakcje sesji i użyj trybu ACK KLIENTA.

Aby wykonać to zadanie, zadeklaruj własne JmsListenerContainerFactory fasoli, a następnie ustaw właściwości lub po przetworzeniu JmsListenerContainerFactory zdefiniowane w starter. W poniższym przykładzie użyto metody deklarowania innego fasoli:

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

W procedurze obsługi komunikatów jawnie ukończ lub porzucaj komunikaty.

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

Problemy z konfiguracją

Wyłączanie automatycznej konfiguracji usługi Service Bus JMS

Opis problemu

Niektórzy użytkownicy importuje niektóre szablony startowe Spring Cloud Azure na potrzeby automatycznej konfiguracji usługi platformy Azure innej niż Service Bus JMS. Korzystają one również z platformy Spring JMS bez konieczności korzystania z usługi Service Bus JMS. Następnie podczas próby uruchomienia aplikacji są zgłaszane następujące wyjątki:

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

Analiza przyczyny

Ten problem występuje, ponieważ wszystkie klasy autokonfiguracji platformy Azure Spring Cloud są umieszczane w tym samym module, więc każdy szablon startowy Spring Cloud Azure faktycznie importuje całą tę automatyczną konfigurację, która obejmuje również usługę Service Bus JMS. Następnie, gdy aplikacja używa interfejsu API spring JMS, spełnia warunek autokonfiguracji JMS usługi Service Bus i wyzwala ją. Następnie dla użytkowników, którzy nie zamierzają używać spring-cloud-azure-starter-servicebus-jms, warunki właściwości nie są spełnione, ponieważ nie ma powodu, aby skonfigurować usługę Service Bus dla programu JMS. Taka sytuacja powoduje zgłaszanie wyjątków.

Rozwiązanie

Rozwiązanie Spring Cloud Azure for Service Bus JMS udostępnia właściwość włączania lub wyłączania jej automatycznej konfiguracji. Możesz wyłączyć tę funkcję zgodnie z potrzebami, używając następującego ustawienia właściwości:

spring.jms.servicebus.enabled=false

Konfigurowanie atrybutów komunikatów

Jak ustawić typ zawartości komunikatów wychodzących?

Aby skonfigurować typ zawartości, dostosuj konwerter komunikatów, aby zmodyfikować atrybut typu zawartości podczas konwertowania komunikatów. Poniższy kod przyjmuje komunikaty bajtowe jako przykład.

Najpierw dostosuj konwerter komunikatów do użycia w JmsTemplate, jak pokazano w poniższym przykładzie:

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

Następnie zadeklaruj niestandardową fasolę konwertera komunikatów, jak pokazano w tym przykładzie:

@Configuration(proxyBeanMethods = false)
public class CustomJmsConfiguration {

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

Jak ustawić nazwę właściwości identyfikatora typu dla MapJackson2MessageConverter?

Atrybut type-id-property-name umożliwia MappingJackson2MessageConverter określenie klasy używanej do deserializacji ładunku komunikatu. Podczas serializacji każdego obiektu Java do ładunku Spring Message konwerter przechowuje typ ładunku do właściwości komunikatu o nazwie właściwości zarejestrowanej przez type-id-property-name. Następnie podczas deserializacji komunikatu konwerter odczytuje identyfikator typu z komunikatu i wykonuje deserializacji.

Aby ustawić type-id-property-name, zadeklaruj własną MappingJackson2MessageConverter fasolę i skonfiguruj właściwość, jak pokazano w poniższym przykładzie:

@Configuration(proxyBeanMethods = false)
public class CustomJmsConfiguration {

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

Wykrywanie duplikatów

Usługa Azure Service Bus obsługuje wykrywania duplikatów, która stosuje właściwość MessageId w celu unikatowego identyfikowania komunikatów i odrzucania duplikatów wysyłanych do usługi Service Bus.

Jednak w przypadku interfejsu API JMS nie należy ustawiać identyfikatora komunikatu JMS, który jest uważany za niedozwolone w specyfikacji JMS. Dlatego ta funkcja nie jest obecnie obsługiwana w rozwiązaniu Spring Cloud Azure Service Bus JMS Starter.

Aby uzyskać więcej aktualizacji tej funkcji, zobacz problem z usługą GitHub .

Włączanie rejestrowania transportu protokołu AMQP

Aby uzyskać więcej informacji, zobacz sekcję włączanie rejestrowania transportu protokołu AMQP Rozwiązywanie problemów z usługą Service Bus.

Uzyskaj dodatkową pomoc

Aby uzyskać więcej informacji na temat sposobów dotarcia do pomocy technicznej, zobacz Support w katalogu głównym repozytorium.

Zasoby dla szablonu startowego JMS usługi Azure Service Bus platformy Spring Cloud

używanie usługi Azure Service Bus z JMS
uzyskiwanie dostępu do usługi Azure Service Bus za pomocą programu JMS na platformie Spring
przewodnik migracji dla platformy Spring Cloud Azure 4.0
Przykładowa

Zgłaszanie problemów z usługą GitHub

Podczas zgłaszania problemów z usługą GitHub wymagane są następujące szczegóły:

Konfiguracja usługi Service Bus / środowisko przestrzeni nazw
- Jaka warstwa to przestrzeń nazw (Standardowa lub Premium)?
- Jakiego typu jednostka obsługi komunikatów jest używana (kolejka lub temat)? i jego konfiguracja.
- Jaki jest średni rozmiar każdego komunikatu?
Jak wygląda wzorzec ruchu? (czyli liczba komunikatów na minutę i to, czy klient jest zawsze zajęty, czy ma wolne okresy ruchu).
Wykonaj ponownie kod i kroki
- Jest to ważne, ponieważ często nie możemy odtworzyć problemu w naszym środowisku.
Dzienniki

Opinia

Czy ta strona była pomocna?

Last updated on 2025-08-19

Udostępnij za pośrednictwem

Przewodnik rozwiązywania problemów z programem Spring JMS

Problemy z łącznością

Element MessageProducer został zamknięty z powodu nieodwracalnego błędu

Opis problemu

Analiza przyczyny

Obejście

Użycie spring.jms.servicebus.idle-timeout

Problemy z platformą JmsTemplate

Zaplanowane komunikaty

Problemy z programem JmsListener

Zbyt wiele żądań jest wysyłanych do usługi Service Bus, mimo że na serwerze nie ma żadnych komunikatów

Opis problemu

Analiza przyczyny

Rozwiązania

Rozwiązanie 1. Zmiana w celu wypychania tylko odbiorcy i sprawdzania lokalnego

Rozwiązanie 2. Zwiększ limit czasu odbierania, aby zmniejszyć częstotliwość ściągania

Problem z pobieraniem wstępnym

Opis problemu

Analiza przyczyny

Rozwiązanie

Jak wykonać dyspozycję protokołu AMQP w usłudze Service Bus?

Problemy z konfiguracją

Wyłączanie automatycznej konfiguracji usługi Service Bus JMS

Opis problemu

Analiza przyczyny

Rozwiązanie

Konfigurowanie atrybutów komunikatów

Jak ustawić typ zawartości komunikatów wychodzących?

Jak ustawić nazwę właściwości identyfikatora typu dla MapJackson2MessageConverter?

Wykrywanie duplikatów

Włączanie rejestrowania transportu protokołu AMQP

Uzyskaj dodatkową pomoc

Zasoby dla szablonu startowego JMS usługi Azure Service Bus platformy Spring Cloud

Zgłaszanie problemów z usługą GitHub

Opinia

Dodatkowe zasoby

Użycie `spring.jms.servicebus.idle-timeout`