Handleiding voor het oplossen van problemen met Spring JMS

In dit artikel wordt beschreven hoe u bekende problemen en veelvoorkomende fouten kunt oplossen bij het gebruik van Spring JMS. Het artikel beantwoordt ook enkele veelgestelde vragen voor spring-cloud-azure-starter-servicebus-jms.

Connectiviteitsproblemen

MessageProducer is gesloten vanwege een onherstelbare fout

Beschrijving van probleem

Wanneer u JmsTemplate gebruikt om berichten te verzenden, is JmsTemplate tijdens een niet-actief interval tussen 10 en 15 minuten niet meer beschikbaar. Als u berichten in dat interval verzendt, kunnen de uitzonderingen worden weergegeven in de volgende voorbeelduitvoer:

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

Oorzaakanalyse

De uitzonderingen treden op voor Azure Service Bus- wanneer de AMQP-verbinding en -koppeling actief zijn, maar er worden geen oproepen gedaan, bijvoorbeeld voor het verzenden of ontvangen van oproepen, met behulp van de koppeling gedurende tien minuten. In dit geval wordt de koppeling gesloten. En wanneer alle koppelingen in de verbinding zijn gesloten omdat er geen activiteit (niet-actief) is en er in vijf minuten geen nieuwe koppeling is gemaakt, wordt de verbinding gesloten.

Voor de Service Bus JMS-starter wordt de CachingConnectionFactory- standaard gebruikt, waarmee de sessie, producent en consument in de cache wordt opgeslagen. Als JmsProducer langer dan 10 minuten maar minder dan 15 minuten inactief is, is de verbinding die door de in de cache opgeslagen producent wordt gebruikt, gesloten. Berichten kunnen tijdens dit interval niet worden verzonden. Na nog eens 5 minuten inactief is de hele verbinding gesloten. Elke verzendbewerking na het inactiviteitsinterval van 15 minuten zorgt er dus voor dat de CachingConnectionFactory een nieuwe verbinding maakt om te verzenden. De verzendbewerking wordt na 15 minuten beschikbaar.

Tijdelijke oplossing

Op dit moment biedt de starter een tijdelijke oplossing voor het loskoppelingsprobleem van links door JmsPoolConnectionFactory toe te passen, waarmee Connection, Session en MessageProducer worden gepoold en de levenscyclus van de gepoolde instanties wordt beheerd. Deze tijdelijke oplossing kan ervoor zorgen dat een producent wordt verwijderd nadat deze niet beschikbaar is en daarom alle verzendbewerkingen worden uitgevoerd op actieve producenten.

Als u deze tijdelijke oplossing wilt gebruiken, voegt u de volgende configuratie toe:

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

Gebruik van `spring.jms.servicebus.idle-timeout`

Met de eigenschappen voor de idle-time-out stelt u de idle-time-out van een AMQP-verbinding in. De AMQP-specificatie bevat de volgende beschrijving:

Verbindingen zijn onderhevig aan een time-outdrempel voor inactiviteit. De time-out wordt geactiveerd door een lokale peer wanneer er geen frames worden ontvangen nadat een drempelwaarde is overschreden. De time-out voor inactiviteit wordt gemeten in milliseconden en begint vanaf het moment dat het laatste frame wordt ontvangen. Als de drempelwaarde wordt overschreden, zou een peer moeten proberen de verbinding op een gecontroleerde manier te sluiten met behulp van een close-frame met een foutmelding waarin wordt uitgelegd waarom. Als de externe peer hierop niet ordelijk reageert binnen een bepaalde drempel, mag de peer de TCP-socket sluiten.

Wanneer u deze eigenschap configureert voor een JMS-client, bepaalt u aan de serverzijde hoe lang u verwacht dat de server een leeg frame verzendt om een verbinding actief te houden wanneer er geen berichten worden bezorgd. Deze eigenschap bepaalt het gedrag van de externe peer en elke peer kan een eigen, geïsoleerde waarde hebben.

Problemen met JmsTemplate

Geplande berichten

Azure Service Bus ondersteunt vertraagde berichtverwerking. Zie de sectie Geplande berichten sectie van berichtvolgorde en tijdstempelsvoor meer informatie. Voor JMS stelt u, om een bericht te plannen, de eigenschap ScheduledEnqueueTimeUtc in met behulp van de header voor berichtannotaties x-opt-scheduled-enqueue-time.

Problemen met JmsListener

Er worden te veel aanvragen verzonden naar Service Bus, ook al zijn er geen berichten op de server

Beschrijving van probleem

Wanneer u de @JmsListener-API gebruikt, kunt u in sommige gevallen in Azure Portal zien dat er doorlopende waarden zijn voor binnenkomende aanvragen die naar hun wachtrij of onderwerpen worden verzonden, zelfs als er geen berichten op de server zijn die moeten worden ontvangen.

Oorzaakanalyse

@JmsListener is een pollinglistener, ontworpen voor herhaaldelijke pollingpogingen.

De listener zit op een lopende pollinglus. Elke lus roept de JMS-MessageConsumer.receive() methode aan om de lokale consument te peilen voor berichten die moeten worden gebruikt. Standaard verzendt de lokale consument voor elke poll-bewerking pull-aanvragen naar de berichtenbroker om berichten te vragen en vervolgens voor een bepaalde periode te blokkeren. Het concrete pollingproces wordt bepaald door verschillende eigenschappen, waaronder receiveTimeout, prefetchSizeen receiveLocalOnly of receiveNoWaitLocalOnly. De methode receiveNoWaitLocalOnly wordt alleen gebruikt wanneer u receiveTimeout instelt op een negatieve waarde.

Wanneer dit probleem zich voordoet met uw toepassing, controleert u de volgende configuratie-instellingen:

Bepaal of uw prefetch-beleid 0 is, wat ook de standaardoptie is. 0-prefetch betekent een pull-consument die pull-aanvragen naar de Service Bus verzendt voor elke poll.
Als u een niet-nulwaarde voor prefetch hebt geconfigureerd, controleer dan of de eigenschap receiveLocalOnly of receiveNoWaitLocalOnly is ingesteld op false, de standaardoptie. Een false waarde hier resulteert nog steeds in het verzenden van pull-aanvragen naar de server, omdat deze niet alleen de lokale consument pollt.
De receiveTimeout-configuratie bepaalt hoe lang deze wordt geblokkeerd voor elke pull-aanvraag, zodat deze van invloed kan zijn op de frequentie van pull-aanvragen die naar de server worden verzonden. De standaardwaarde is 1 seconde.

Zie voor een volledige analyse de discussie in de GitHub-issue.

Oplossingen

In de volgende secties worden twee oplossingen beschreven voor het oplossen van dit probleem

Oplossing 1. Wijzigen om alleen consumenten en lokale controles te pushen

Door de modus te wijzigen in push, wordt de consument een Asynchrone melding consument die geen berichten van de broker ophaalt, maar een doelbedrag aan koppelingstegoed onderhoudt. Het bedrag wordt bepaald door een prefetch eigenschap. Wanneer de Service Bus (afzender) berichten pusht, neemt het koppelingskrediet van de afzender af en wanneer het koppelingskrediet van de afzender onder een drempelwaarde valt, verzendt de client (ontvanger) een aanvraag naar de server om het koppelingskrediet van de afzender terug te verhogen naar het gewenste doelbedrag.

Voeg de volgende configuratie toe om deze oplossing te bereiken:

Stel eerst het getal prefetch in op een waarde ongelijk aan nul, zodat de consumer als non-pull wordt geconfigureerd. In de volgende tabel ziet u verschillende prefetch-eigenschappen, die elk verschillende Service Bus-entiteiten beheren. Stel de eigenschappen in die van toepassing zijn op uw case.

Eigenschap	Beschrijving
`spring.jms.servicebus.prefetch.all`	De terugvalwaarde voor de prefetch-optie in deze Service Bus-naamruimte
`spring.jms.servicebus.prefetch.queue-prefetch`	Het prefetchaantal voor de wachtrij.
`spring.jms.servicebus.prefetch.queue-browser-prefetch`	Het prefetchaantal voor de wachtrijbrowser.
`spring.jms.servicebus.prefetch.topic-prefetch`	Het prefetchnummer voor het onderwerp.
`spring.jms.servicebus.prefetch.durable-topic-prefetch`	Het prefetchnummer voor het duurzame onderwerp.

Ten tweede configureert u de non-local-check door een configuratieklasse toe te voegen voor de fabrieksaanpassingsfunctie, zoals wordt weergegeven in het volgende voorbeeld:

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

De waarde van de prefetch kan van invloed zijn op de snelle verzending van berichten naar de lokale buffer van de consument. U moet de waarde aanpassen op basis van de verbruikende prestaties en berichtvolumes. Een geschikte waarde kan het verbruiksproces versnellen, terwijl een waarde die te groot is, ertoe kan leiden dat de lokaal gebufferde berichten verouderd raken en opnieuw worden verzonden. Voor lage berichtvolumes, waarbij het verwerken van elk bericht lang duurt, stelt u de prefetch in op 1. Deze waarde zorgt ervoor dat een consument slechts één bericht tegelijk verwerkt.

Oplossing 2. De time-out voor ontvangst verhogen om de pull-frequentie te verlagen

De time-outeigenschap voor ontvangst bepaalt de strategie voor hoe lang de consument blokkeert om te wachten op een pull-resultaat. Door de time-out uit te breiden, kunt u de pull-frequentie verminderen en vervolgens het aantal pull-aanvragen verminderen wanneer u de pull-modus kiest. In uitzonderlijke gevallen kunt u de strategie zo instellen dat er onbeperkt wordt gewacht tot er een bericht binnenkomt, wat betekent dat de consumer pas een nieuw bericht ophaalt nadat een bericht is verwerkt. In dit geval wordt het wachten geblokkeerd wanneer er geen berichten op de server staan.

Als u deze oplossing wilt uitvoeren, configureert u de eigenschap spring.jms.listener.receive-timeout. Deze eigenschap is van het type java.time.Duration en heeft een standaardwaarde van 1 seconde. In de volgende lijst wordt het effect van verschillende waarden uitgelegd:

Als u de ontvangsttime-out instelt op 0, betekent dit dat de pull onbepaalde tijd blokkeert totdat een bericht wordt afgeleverd.
Als u de ontvangsttime-out instelt op een positieve waarde, betekent dit dat de pull gedurende maximaal de time-outperiode blokkeert.
Als u de time-out voor ontvangst instelt op een negatieve waarde, betekent dit dat de pull een ontvangst zonder wachttijd is, wat betekent dat er onmiddellijk een bericht wordt geretourneerd of null als er geen berichten beschikbaar zijn.

Notitie

Een hoge time-outwaarde kan bijwerkingen opleveren. Een hoge time-outwaarde verlengt bijvoorbeeld ook de tijd dat de hoofdthread zich in een geblokkeerde status bevindt. Deze status betekent dat de container minder reageert op stop() aanroepen en dat de container alleen kan stoppen tussen receive() aanroepen.

De container kan ook alleen aanvragen verzenden nadat het receive-timeout-interval is verstreken. Als het interval langer is dan 10 minuten, sluit Service Bus de verbinding en voorkomt het dat de listener berichten verzendt of ontvangt. Zie de sectie Koppeling is gesloten sectie van AMQP-fouten in Azure Service Busvoor meer informatie. De listener maakt standaard gebruik van een CachingConnectionFactory-.

Als u een hoge ontvangsttime-out nodig hebt, moet u de JmsPoolConnectionFactorygebruiken.

Zie de sectie The MessageProducer was closed due to an unrecoverable error voor meer informatie over het probleem met het sluiten van de koppeling en over het gebruik van JmsPoolConnectionFactory.

Probleem met vooraf ophalen

Beschrijving van probleem

Een ongeschikt prefetch-beleid kan de volgende problemen veroorzaken:

Dezelfde berichten worden herhaaldelijk verwerkt.
Berichten worden na MaxDeliveryCountExceededin de wachtrij met dode letters geplaatst, zelfs wanneer berichten zonder fout of uitzondering worden verwerkt.

Oorzaakanalyse

Dit probleem treedt meestal op wanneer de prefetch waarde hoger is dan de werkelijke verbruikscapaciteit, met het effect dat te veel berichten vooraf worden toegepast op de lokale buffer die wacht om te worden verbruikt. De vooraf opgehaalde berichten worden echter aan de kant van Service Bus beschouwd als verzonden in de modus peek-lock. Elk verzonden bericht heeft een max-delivery-count en lock-duration kenmerken. In de peek-lock-ontvangstmodus worden berichten die in de prefetchbuffer zijn opgehaald, in vergrendelde toestand in de buffer geplaatst, terwijl de time-out voor de vergrendeling doorloopt. Als de prefetchbuffer groot is en de verwerking zo lang duurt dat berichtvergrendelingen verlopen terwijl ze in de prefetchbuffer blijven, wordt het bericht behandeld als verlaten en wordt het opnieuw beschikbaar gesteld voor het ophalen uit de wachtrij.

Dit probleem kan ertoe leiden dat het bericht wordt opgehaald in de prefetchbuffer en aan het einde wordt geplaatst. Als de prefetchbuffer niet wordt verwerkt voordat de berichten verlopen, worden berichten herhaaldelijk opgehaald, maar nooit daadwerkelijk in een bruikbare, geldig vergrendelde toestand afgeleverd. Wanneer die verouderde kopieën vervolgens uit de wachtrij worden gehaald, verwerkt de toepassing steeds opnieuw hetzelfde bericht en kan ze de verwerking ervan niet voltooien. In een ander geval zijn herhaalde berichten al in de buffer verlopen voordat ze worden verwerkt. In dit geval wordt het bericht in de Service Bus uiteindelijk verplaatst naar de wachtrij met onbestelbare berichten nadat het maximale aantal bezorgingen is overschreden.

Zie voor meer informatie de sectie Waarom is Prefetch niet de standaardoptie? in Azure Service Bus-berichten vooraf ophalen.

Oplossing

Configureer de prefetch-instelling zorgvuldig, zodat deze aansluit bij de verwerkingscapaciteit. U moet het maximale aantal vooraf opgehaalde berichten en de vergrendelingsduur die voor de wachtrij of het abonnement is geconfigureerd zodanig op elkaar afstemmen dat de time-out van de vergrendeling ten minste langer is dan de cumulatieve verwachte verwerkingstijd voor de maximale grootte van de prefetchbuffer, plus één bericht. Tegelijkertijd mag de time-out voor de vergrendeling niet zo lang zijn dat berichten hun maximale levensduur kunnen overschrijden wanneer ze per ongeluk worden verwijderd, waardoor hun vergrendeling moet verlopen voordat ze opnieuw worden verzonden.

Gebruik een van de volgende eigenschappen om het prefetch-kenmerk, dat een standaardwaarde van nul heeft, te configureren:

Eigenschap	Beschrijving
`spring.jms.servicebus.prefetch.all`	De terugvalwaarde voor de prefetch-optie in deze Service Bus-naamruimte.
`spring.jms.servicebus.prefetch.queue-prefetch`	Het prefetchaantal voor de wachtrij.
`spring.jms.servicebus.prefetch.queue-browser-prefetch`	Het prefetchaantal voor de wachtrijbrowser.
`spring.jms.servicebus.prefetch.topic-prefetch`	Het prefetchnummer voor het onderwerp.
`spring.jms.servicebus.prefetch.durable-topic-prefetch`	Het prefetchnummer voor het duurzame onderwerp.

Hoe kan ik AMQP-verwijdering uitvoeren naar Service Bus?

JMS ondersteunt vijf AMQP-afhandelingstypen bij het bevestigen van berichten bij de berichtenbroker. De ondersteunde waarden zijn ACCEPTED, REJECTED, RELEASED, MODIFIED_FAILEDen MODIFIED_FAILED_UNDELIVERABLE. Voor meer informatie raadpleegt u de sectie AMQP-dispositie en toewijzing van Service Bus-bewerkingen van Java Message Service 1.1 gebruiken met Azure Service Bus standard en AMQP 1.0.

Gebruik de volgende stappen om een bericht handmatig te voltooien, af te geven, af te schaffen, uit te stellen of los te laten met behulp van JmsListener:

Schakel sessie-transacties uit en gebruik CLIENT ack-modus.

Om deze taak uit te voeren, kunt u ofwel uw eigen JmsListenerContainerFactory-bean definiëren en vervolgens de eigenschappen instellen, of de JmsListenerContainerFactory die in de starter is gedefinieerd nabewerken. In het volgende voorbeeld wordt gebruikgemaakt van de aanpak waarbij een andere bean wordt gedeclareerd:

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

In de berichtenhandler kunt u berichten expliciet voltooien of afbreken.

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

Configuratieproblemen

Automatische configuratie van Service Bus JMS uitschakelen

Beschrijving van probleem

Sommige gebruikers importeren een Spring Cloud Azure Starter voor de automatische configuratie van een andere Azure-service dan Service Bus JMS. Ze gebruiken ook het Spring JMS-framework zonder dat Service Bus JMS nodig is. Wanneer de toepassing vervolgens probeert te starten, worden de volgende uitzonderingen gegenereerd:

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

Oorzaakanalyse

Dit probleem treedt op omdat alle automatische configuratieklassen van Spring Cloud Azure in dezelfde module worden geplaatst, dus importeert elke Spring Cloud Azure Starter alle automatische configuratie, die ook Service Bus JMS bevat. Wanneer de toepassing vervolgens gebruikmaakt van de Spring JMS-API, voldoet deze aan de voorwaarde van Service Bus JMS autoconfiguration en wordt deze geactiveerd. Vervolgens wordt voor gebruikers die niet van plan zijn spring-cloud-azure-starter-servicebus-jms te gebruiken, niet aan de eigenschapsvoorwaarden voldaan, omdat er geen reden is om Service Bus voor JMS te configureren. Deze situatie zorgt ervoor dat de exceptions worden opgeworpen.

Oplossing

Spring Cloud Azure for Service Bus JMS biedt een eigenschap voor het in- of uitschakelen van de automatische configuratie. U kunt deze functionaliteit indien nodig uitschakelen met behulp van de volgende eigenschapsinstelling:

spring.jms.servicebus.enabled=false

Berichtkenmerken configureren

Het inhoudstype van uitgaande berichten instellen

Als u het inhoudstype wilt configureren, past u het berichtconversieprogramma aan om het kenmerk inhoudstype te wijzigen bij het converteren van berichten. De volgende code neemt byteberichten als voorbeeld.

Pas eerst het berichtconversieprogramma aan dat moet worden gebruikt in de JmsTemplate, zoals wordt weergegeven in het volgende voorbeeld:

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

Definieer vervolgens je aangepaste berichtconverter-bean, zoals in dit voorbeeld:

@Configuration(proxyBeanMethods = false)
public class CustomJmsConfiguration {

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

Hoe stel je de naam van de type-ID-eigenschap in voor MappingJackson2MessageConverter?

Met het attribuut type-id-property-name kan de MappingJackson2MessageConverter bepalen welke klasse moet worden gebruikt om de berichtpayload te deserialiseren. Wanneer u elk Java-object serialiseert naar een Spring Message-nettolading, slaat het conversieprogramma het nettoladingstype op in een berichteigenschap met de eigenschapsnaam die is vastgelegd door type-id-property-name. Wanneer het bericht vervolgens wordt gedeserialiseerd, leest het conversieprogramma de type-id van het bericht en voert deserialisatie uit.

Als u de type-id-property-namewilt instellen, declareert u uw eigen MappingJackson2MessageConverter bean en configureert u die eigenschap, zoals wordt weergegeven in het volgende voorbeeld:

@Configuration(proxyBeanMethods = false)
public class CustomJmsConfiguration {

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

Duplicaatdetectie

Azure Service Bus ondersteunt dubbele detectie, waarmee de eigenschap MessageId wordt toegepast om berichten uniek te identificeren en de duplicaten te verwijderen die naar Service Bus worden verzonden.

Voor de JMS-API moet u echter niet de JMS-bericht-id instellen, die wordt beschouwd als ongeldige in JMS-specificaties. Deze functie wordt momenteel niet ondersteund voor Spring Cloud Azure Service Bus JMS Starter.

Zie de GitHub-issue voor verdere updates over deze functie.

AMQP-transportlogboekregistratie inschakelen

Zie het gedeelte AMQP-transportlogboekregistratie inschakelen sectie van Service Bus-problemen oplossenvoor meer informatie.

Aanvullende hulp krijgen

Zie Support in de hoofdmap van de repo voor meer informatie over manieren om ondersteuning te krijgen.

Hulpmiddelen voor Spring Cloud Azure Service Bus JMS starter

GitHub-issues indienen

Bij het indienen van GitHub-problemen worden de volgende gegevens aangevraagd:

Service Bus-configuratie / naamruimteomgeving
- Welke laag is de naamruimte (Standard of Premium)?
- Welk type berichtenentiteit wordt gebruikt (wachtrij of onderwerp)? en de configuratie ervan.
- Wat is de gemiddelde grootte van elk bericht?
Wat is het verkeerspatroon? (dat wil gezegd, het aantal berichten per minuut en of de client altijd bezet is of trage verkeersperioden heeft.)
Reproductiecode en stappen
- Dit is belangrijk omdat we het probleem vaak niet in onze omgeving kunnen reproduceren.
Logboeken

Feedback

Is deze pagina nuttig?

Laatst bijgewerkt om 2025-08-19

Handleiding voor het oplossen van problemen met Spring JMS

Connectiviteitsproblemen

MessageProducer is gesloten vanwege een onherstelbare fout

Beschrijving van probleem

Oorzaakanalyse

Tijdelijke oplossing

Gebruik van spring.jms.servicebus.idle-timeout

Problemen met JmsTemplate

Geplande berichten

Problemen met JmsListener

Er worden te veel aanvragen verzonden naar Service Bus, ook al zijn er geen berichten op de server

Beschrijving van probleem

Oorzaakanalyse

Oplossingen

Oplossing 1. Wijzigen om alleen consumenten en lokale controles te pushen

Oplossing 2. De time-out voor ontvangst verhogen om de pull-frequentie te verlagen

Probleem met vooraf ophalen

Beschrijving van probleem

Oorzaakanalyse

Oplossing

Hoe kan ik AMQP-verwijdering uitvoeren naar Service Bus?

Configuratieproblemen

Automatische configuratie van Service Bus JMS uitschakelen

Beschrijving van probleem

Oorzaakanalyse

Oplossing

Berichtkenmerken configureren

Het inhoudstype van uitgaande berichten instellen

Hoe stel je de naam van de type-ID-eigenschap in voor MappingJackson2MessageConverter?

Duplicaatdetectie

AMQP-transportlogboekregistratie inschakelen

Aanvullende hulp krijgen

Hulpmiddelen voor Spring Cloud Azure Service Bus JMS starter

GitHub-issues indienen

Feedback

Aanvullende resources

Gebruik van `spring.jms.servicebus.idle-timeout`