Spring JMS hibaelhárítási útmutató

Ez a cikk ismerteti, hogyan háríthatja el az ismert problémákat és a Spring JMS használatakor előforduló gyakori hibákat. A cikk a spring-cloud-azure-starter-servicebus-jmskapcsolatos gyakori kérdésekre is választ ad.

Csatlakozási problémák

A MessageProducer egy helyreállíthatatlan hiba miatt bezárult

Probléma leírása

Ha JmsTemplate használ üzenetek küldéséhez, JmsTemplate 10–15 perc közötti tétlenségi időszak alatt válik elérhetetlenné. Az adott intervallumban küldött üzenetek a következő példakimenetben látható kivételeket kapják:

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

Okok elemzése

Az Azure Service Bus kivételei akkor fordulnak elő, ha az AMQP-kapcsolat és a hivatkozás aktív, de nem történik hívás – például hívások küldése vagy fogadása – a hivatkozás használatával 10 percig. Ebben az esetben a hivatkozás bezárul. Ha a kapcsolat összes hivatkozása bezárult, mert nem volt tevékenység (tétlen), és 5 perc alatt nem jött létre új hivatkozás, a kapcsolat lezárul.

A Service Bus JMS starter esetében alapértelmezés szerint a CachingConnectionFactory használatos, amely gyorsítótárazza a munkamenetet, a gyártót és a fogyasztót. Ha a JmsProducer több mint 10, de kevesebb mint 15 percig tétlen, a gyorsítótárazott producer által használt kapcsolat lezárult. Az üzenetek nem küldhetők el ebben az intervallumban. Ezután további 5 perc tétlenség után a teljes kapcsolat bezárul. Így a 15 perces inaktivitási időszak utáni bármely küldési művelet arra készteti a CachingConnectionFactory-t, hogy az elküldéshez új kapcsolatot hozzon létre. A küldési művelet 15 perc után elérhetővé válik.

Kerülőmegoldás

A starter jelenleg kerülőmegoldást biztosít a link-leválasztási problémára a JmsPoolConnectionFactory alkalmazásával, amely poolozza a Connection, Session és MessageProducer elemeket, és kezeli a poolozott példányok életciklusát. Ez a kerülőmegoldás biztosíthatja, hogy az előállítót eltávolítsák, miután elérhetetlenné válik, és így minden küldési művelet aktív előállítókon történik.

A kerülő megoldás használatához adja hozzá a következő konfigurációt:

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

A `spring.jms.servicebus.idle-timeout` használata

A tétlenségi időkorlát tulajdonságai adják meg az AMQP-kapcsolat tétlenségi időkorlátját. Az AMQP specifikáció a következő leírást tartalmazza:

A kapcsolatokra inaktivitási időkorlát érvényes. Az időtúllépést a helyi végpont váltja ki, ha a küszöbérték túllépése után nem érkeznek keretek. Az üresjárati időkorlátot ezredmásodpercben mérik, és az utolsó keret beérkezésének időpontjától kezdődik. Ha a küszöbértéket túllépik, a végpontnak meg kellene kísérelnie a kapcsolat szabályos lezárását egy lezáró keret használatával, amelyben szerepel egy hiba, amely megmagyarázza ennek okát. Ha a távoli társ nem válaszol elegánsan erre a küszöbértéken belül, akkor a társ bezárhatja a TCP-szoftvercsatornát.

JMS-ügyfél esetén a tulajdonság konfigurálásakor a kiszolgálóoldalon szabályozhatja, hogy a kiszolgáló mennyi ideig küldjön üres keretet a kapcsolat életben tartásához, amikor nem érkeznek üzenetek. Ez a tulajdonság vezérli a távoli társ viselkedését, és minden társnak saját, izolált értéke lehet.

JmsTemplate-problémák

Ütemezett üzenetek

Az Azure Service Bus támogatja a késleltetett üzenetfeldolgozást. További információ: Ütemezett üzenetek Üzenetszekvenálás és időbélyegekszakasza. JMS esetén az üzenet ütemezéséhez állítsa be a ScheduledEnqueueTimeUtc tulajdonságot az üzenet széljegyzet fejlécének x-opt-scheduled-enqueue-timehasználatával.

JmsListener-problémák

Túl sok kérést küld a Service Busnak annak ellenére, hogy nincsenek üzenetek a kiszolgálón

Probléma leírása

Az @JmsListener API használatakor bizonyos esetekben az Azure Portalon láthatja, hogy a várólistára vagy témakörökbe küldött bejövő kérések folyamatos értékeket tartalmaznak, még akkor is, ha a kiszolgáló nem fogad üzeneteket.

Okok elemzése

@JmsListener egy lekérdezésfigyelő, amely ismétlődő lekérdezési kísérletekhez készült.

A figyelő egy folyamatban lévő lekérdezési cikluson ül. A ciklus minden egyes lefutásakor meghívja a JMS MessageConsumer.receive() metódust, hogy a helyi fogyasztótól üzeneteket kérjen le feldolgozásra. Alapértelmezés szerint minden egyes lekérdezési műveletnél a helyi fogyasztó lekéréses kéréseket küld az üzenetközvetítőnek, hogy üzeneteket kérjen, majd letiltsa egy bizonyos ideig. A konkrét lekérdezési folyamatot számos tulajdonság határozza meg , beleértve a receiveTimeout, prefetchSize, és receiveLocalOnly vagy receiveNoWaitLocalOnly. A receiveNoWaitLocalOnly metódust csak akkor használja a rendszer, ha negatív értékre állítja receiveTimeout.

Ha ez a probléma az alkalmazásnál jelentkezik, ellenőrizze a következő konfigurációs beállításokat:

Ellenőrizze, hogy a prefetch házirend értéke 0-e, mivel ez az alapértelmezett beállítás is. A 0-prefetch azt a lekéréses fogyasztót jelenti, amely lekéréses kérelmeket küld a Service Busnak minden szavazáshoz.
Ha nem nulla előbeolvasást konfigurált, ellenőrizze, hogy a receiveLocalOnly vagy a receiveNoWaitLocalOnly tulajdonság értéke false-e, amely az alapértelmezett beállítás. Az itt megadott false érték továbbra is lekérési kérések küldését eredményezi a kiszolgálónak, mivel nem csak a helyi fogyasztót kérdezi le.
A receiveTimeout konfiguráció határozza meg, hogy mennyi ideig blokkolja az egyes lekéréses kérelmeket, így hatással lehet a kiszolgálóra küldött lekéréses kérelmek gyakoriságára. Az alapértelmezett érték 1 másodperc.

A teljes elemzést a GitHub-problémacímű témakörben talál.

Megoldások

A következő szakaszok a probléma kezelésére szolgáló két megoldást ismertetik

1. megoldás. Váltás csak push típusú fogyasztóra és csak helyi ellenőrzésre

Ha az üzemmódot push értékre állítja, a fogyasztó Aszinkron értesítési fogyasztóvá válik, amely nem kér le üzeneteket a brokertől, hanem egy megcélzott mennyiségű linkkreditet tart fenn. Az összeget egy előzetes tulajdonság határozza meg. Ahogy a Service Bus (feladó) leküldi az üzeneteket, a feladó hivatkozási kreditje csökken, és amikor a feladó hivatkozási kreditje egy küszöbérték alá csökken, az ügyfél (fogadó) kérést küld a kiszolgálónak, hogy növelje a feladó hivatkozási kreditjét a kívánt célértékre.

A megoldás végrehajtásához adja hozzá a következő konfigurációt:

Először konfigurálja a prefetch számot nem nulla értékként, amely nem lekérésesként konfigurálja a fogyasztót. Az alábbi táblázat számos előbetöltési tulajdonságot mutat be, amelyek mindegyike különböző Service Bus-entitásokat szabályoz. Adja meg az esetre vonatkozó tulajdonságokat.

Ingatlan	Leírás
`spring.jms.servicebus.prefetch.all`	Az előbeolvasási beállítás visszaesési értéke ebben a Service Bus-névtérben
`spring.jms.servicebus.prefetch.queue-prefetch`	Az üzenetsor előbetöltési száma.
`spring.jms.servicebus.prefetch.queue-browser-prefetch`	A várólista-böngésző előbetöltési száma.
`spring.jms.servicebus.prefetch.topic-prefetch`	A témakör előzetes száma.
`spring.jms.servicebus.prefetch.durable-topic-prefetch`	A tartós témakör előlehívási száma.

Másodikként konfigurálja a non-local-check-t egy konfigurációs osztály hozzáadásával a gyári testreszabóhoz, ahogy a következő példa mutatja:

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

Az előzetes érték befolyásolhatja, hogy a rendszer milyen gyorsan küld üzeneteket a fogyasztó helyi pufferének. Az értéket a felhasználási teljesítmény és az üzenetmennyiség alapján érdemes módosítani. A megfelelő érték felgyorsíthatja a fogyasztási folyamatot, míg egy túl nagy érték miatt a helyileg pufferelt üzenetek elavulttá válhatnak, és újra elküldhetők. Alacsony üzenetkötetek esetén, ahol az egyes üzenetek feldolgozása hosszú időt vesz igénybe, állítsa az előfetchet 1-re. Ez az érték biztosítja, hogy a fogyasztó egyszerre csak egy üzenetet dolgoz fel.

2. megoldás. Növelje a fogadási időkorlátot a lekérési gyakoriság csökkentése érdekében.

A fogadási időkorlát beállítás határozza meg, hogy a fogyasztó mennyi ideig blokkolva várjon a pull művelet eredményére. Az időtúllépés meghosszabbításával csökkentheti a lekéréses gyakoriságot, majd csökkentheti a lekéréses kérelmek számát a lekéréses mód kiválasztásakor. Szélsőséges esetekben beállíthatja a végtelen várakozás stratégiáját, amíg egy üzenet meg nem érkezik, ami azt jelenti, hogy a fogyasztó csak egy üzenet elfogyasztása után húz le. Ebben az esetben, ha nincsenek üzenetek a kiszolgálón, az blokkolni fogja a várakozást.

A megoldás végrehajtásához konfigurálja a spring.jms.listener.receive-timeout tulajdonságot. Ez a tulajdonság java.time.Duration típusú, alapértelmezett értéke 1 másodperc. Az alábbi lista a különböző értékek hatását ismerteti:

A fogadási időkorlát 0-ra állítása azt jelenti, hogy a lekérés határozatlan ideig blokkol, amíg egy üzenet kézbesítésre nem kerül.
A fogadási időkorlát pozitív értékre állítása azt jelenti, hogy a lekérés legfeljebb az időkorlátban megadott ideig blokkolódik.
Ha a fogadási időkorlátot negatív értékre állítja, az azt jelenti, hogy a pull művelet nem várakozó fogadás, vagyis azonnal visszaadja az üzenetet, illetve null értéket, ha nincs elérhető üzenet.

Jegyzet

A magas időtúllépési érték mellékhatásokat okozhat. A magas időtúllépési érték például meghosszabbítja azt az időt is, amikor a fő szál blokkállapotban van. Ez az állapot azt jelenti, hogy a tároló kevésbé lesz reagálva stop() hívásokra, és csak receive() hívások között tud leállni.

A tároló emellett csak a receive-timeout intervallum leteltét követően küldhet kéréseket. Ha az időköz 10 percnél hosszabb, a Service Bus lezárja a kapcsolatot, így a figyelő nem tud üzeneteket küldeni vagy fogadni. További információkért lásd a A hivatkozás le van zárva szakaszt az AMQP-hibák az Azure Service Busban című cikkben. Alapértelmezés szerint a figyelő a CachingConnectionFactory elemet használja.

Ha nagy fogadási időkorlátra van szüksége, mindenképpen használja a JmsPoolConnectionFactory.

A kapcsolatzárási problémával és a JmsPoolConnectionFactory használatával kapcsolatos további információkért lásd a A MessageProducer egy helyreállíthatatlan hiba miatt lezárult című szakaszt.

Előtöltési probléma

Probléma leírása

A nem megfelelő előzetes szabályzat a következő problémákat okozhatja:

Ugyanazokat az üzeneteket a rendszer ismételten felhasználja.
Az üzenetek MaxDeliveryCountExceededután is a kézbesítetlen levelek üzenetsorába kerülnek, még akkor is, ha az üzenetek feldolgozása hiba vagy kivétel nélkül történik.

Okok elemzése

Ez a probléma általában akkor fordul elő, ha az prefetch érték nagyobb, mint a tényleges fogyasztókapacitás, azzal az effektussal, hogy túl sok üzenet van előre bevéve a helyi pufferbe, amely a felhasználásra vár. Az előre beszúrt peek-lock üzenetek azonban a Service Bus oldaláról küldött módban jelennek meg. Minden elküldött üzenet rendelkezik max-delivery-count és lock-duration attribútummal. A peek-lock fogadási módban a prefetch pufferbe lekért üzenetek zárolt állapotban kerülnek a pufferbe, miközben a zárolás időtúllépési számlálója fut. Ha az előbetöltési puffer nagy, és a feldolgozás olyan hosszú ideig tart, hogy az üzenetzárolás lejár, miközben az előbetöltési pufferben marad, az üzenet elhagyottként lesz kezelve, és ismét elérhetővé válik az üzenetsorból való lekéréshez.

Ez a probléma azt okozhatja, hogy az üzenet az előbetöltési pufferbe kerülhet, majd a végére helyeződhet. Ha az előzetes beolvasási puffert nem dolgozzák fel az üzenetek lejárata előtt, az üzenetek ismételten előzetesen beolvasásra kerülnek, de használható (érvényesen zárolt) állapotban soha nem kerülnek ténylegesen kézbesítésre. Ezután az elavult másolatok lefejtése után az alkalmazás ismételten ugyanazt az üzenetet használja fel, és nem tudja befejezni őket. Egy másik esetben az ismétlődő üzenetek mind lejártak a pufferben a használat előtt. Ebben az esetben a Service Bus üzenete végül a kézbesítetlen levelek várólistára kerülnek a maximális kézbesítési szám túllépése után.

További információ: Miért nem a Prefetch az alapértelmezett beállítás?Prefetch Azure Service Bus-üzenetekszakasza.

Megoldás

Ügyeljen az előzetes lekérés beállítására, hogy az megfeleljen a feldolgozási kapacitásnak. Az üzenetsoron vagy előfizetésen beállított maximális előbetöltési darabszámot és zárolási időtartamot úgy kell összehangolni, hogy a zárolás időtartama legalább hosszabb legyen az előbetöltési puffer maximális méretéhez tartozó várható összesített üzenetfeldolgozási időnél, plusz még egy üzenet feldolgozási idejénél. Ugyanakkor a zárolási időtúllépésnek nem szabad olyan hosszúnak lennie, hogy az üzenetek túlléphessék a maximális élettartamukat, amikor véletlenül elvetik őket, így a zárolásuknak le kell járnia, mielőtt újból kézbesítenék őket.

A nulla alapértelmezett értékkel rendelkező előfetch attribútum konfigurálásához használja az alábbi tulajdonságok egyikét:

Ingatlan	Leírás
`spring.jms.servicebus.prefetch.all`	Az előzetes beolvasási beállítás tartalékértéke ebben a Service Bus-névtérben.
`spring.jms.servicebus.prefetch.queue-prefetch`	Az üzenetsor előbetöltési száma.
`spring.jms.servicebus.prefetch.queue-browser-prefetch`	A várólista-böngésző előbetöltési száma.
`spring.jms.servicebus.prefetch.topic-prefetch`	A témakör előzetes száma.
`spring.jms.servicebus.prefetch.durable-topic-prefetch`	A tartós témakör előlehívási száma.

Hogyan hajthat végre AMQP-diszpozíciót a Service Busban?

A JMS öt AMQP-diszpozíciótípust támogat az üzenetközvetítőnek küldött üzenetek nyugtázásakor. A támogatott értékek a következők: ACCEPTED, REJECTED, RELEASED, MODIFIED_FAILEDés MODIFIED_FAILED_UNDELIVERABLE. További információkért lásd a Java Message Service 1.1 használata az Azure Service Bus Standarddal és az AMQP 1.0-val című cikk AMQP-disposition és a Service Bus-műveletek leképezése című szakaszát.

Tehát egy üzenet kézi befejezéséhez, elvetéséhez, kézbesíthetetlen üzenetté tételéhez, halasztásához vagy felszabadításához az JmsListener használatával kövesse az alábbi lépéseket:

Tiltsa le a tranzakciókezelt munkamenetet, és használjon CLIENT nyugtázási módot.

A feladat elvégzéséhez vagy deklaráljon egy saját JmsListenerContainerFactory bean-t, majd állítsa be a tulajdonságokat, vagy utófeldolgozza a starter által definiált JmsListenerContainerFactory elemet. Az alábbi példa egy másik bab deklarálásának módszerét használja:

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

Az üzenetkezelőben explicit módon fejezze be vagy hagyja abba az üzeneteket.

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

Konfigurációs problémák

A Service Bus JMS automatikus konfigurációjának letiltása

Probléma leírása

Egyes felhasználók importálnak néhány Spring Cloud Azure Startert a Service Bus JMS-étől eltérő Azure-szolgáltatás automatikus konfigurálása érdekében. Emellett a Spring JMS-keretrendszert is használják a Service Bus JMS nélkül. Ezután, amikor az alkalmazás megpróbál elindulni, a következő kivételek jelennek meg:

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

Okok elemzése

Ez a probléma azért fordul elő, mert az Összes Spring Cloud Azure automatikus konfigurációs osztály ugyanabba a modulba van helyezve, így minden Spring Cloud Azure Starter ténylegesen importálja az összes automatikus konfigurációt, amely a Service Bus JMS-t is magában foglalja. Ezután, amikor az alkalmazás a Spring JMS API-t használja, megfelel Service Bus JMS automatikus konfigurációs feltételének, és aktiválja azt. Ekkor azoknál a felhasználóknál, akik nem kívánják használni a spring-cloud-azure-starter-servicebus-jms elemet, a tulajdonságra vonatkozó feltételek nem teljesülnek, mert nincs okuk a Service Bust JMS-hez konfigurálni. Ez a helyzet miatt a kivételek ki lesznek dobva.

Megoldás

A Spring Cloud Azure for Service Bus JMS egy tulajdonságot biztosít az automatikus konfigurálás bekapcsolásához vagy kikapcsolásához. Ezt a funkciót igény szerint letilthatja a következő tulajdonságbeállítással:

spring.jms.servicebus.enabled=false

Üzenetattribútumok konfigurálása

Hogyan állíthatja be a kimenő üzenetek tartalomtípusát?

A tartalomtípus konfigurálásához testre szabhatja az Üzenetkonvertert a tartalomtípus attribútum módosításához az üzenetek konvertálása során. Az alábbi kód példaként a bájtos üzeneteket veszi fel.

Először szabja testre a JmsTemplatehasználni kívánt üzenetkonvertert az alábbi példában látható módon:

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

Ezután deklarálja az egyéni üzenetkonverter-beant az alábbi példában látható módon:

@Configuration(proxyBeanMethods = false)
public class CustomJmsConfiguration {

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

Hogyan lehet beállítani a típusazonosító tulajdonság nevét a MappingJackson2MessageConverter esetében?

A type-id-property-name attribútum lehetővé teszi, hogy a MappingJackson2MessageConverter megállapítsa, melyik osztályt használja az üzenet hasznos adatainak deszerializálásához. Amikor minden Java-objektumot egy Spring Message hasznos adatra szerializál, a konverter a hasznos adattípust egy üzenettulajdonságba tárolja, amely a type-id-property-nameáltal rögzített tulajdonságnévvel rendelkezik. Ezután az üzenet deszerializálásakor a konverter beolvassa a típusazonosítót az üzenetből, és elvégzi a deszerializálást.

A type-id-property-name beállításához deklaráljon egy saját MappingJackson2MessageConverter beant, és konfigurálja ezt a tulajdonságot az alábbi példában bemutatott módon:

@Configuration(proxyBeanMethods = false)
public class CustomJmsConfiguration {

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

Duplikált észlelés

Az Azure Service Bus támogatja duplikált észlelési, amely a MessageId tulajdonságot alkalmazza az üzenetek egyedi azonosítására és a Service Busnak küldött duplikált példányok elvetésére.

A JMS API esetében azonban nem szabad beállítania a JMS-üzenetazonosítót, amely a JMS-specifikációkban illegális. Ez a funkció jelenleg nem támogatott a Spring Cloud Azure Service Bus JMS Starter esetében.

A funkció további frissítéseit a GitHub problémacímű cikkben találja.

Az AMQP-naplózás engedélyezése

További információ: AMQP-átvitel naplózásának engedélyezése Service Bus-problémák hibaelhárításacímű szakaszában.

További segítség kérése

A támogatás igénybevételének módjairól további információt az adattár gyökerében található Support részben talál.

Erőforrások a Spring Cloud Azure Service Bus JMS starterjéhez

GitHub-problémák bejelentése

A GitHub-problémák bejelentésekor a rendszer a következő adatokat kéri:

Service Bus-konfiguráció / Névtér-környezet
- Melyik réteg a névtér (standard vagy prémium)?
- Milyen típusú üzenetküldési entitást használ (üzenetsor vagy témakör)? és konfigurációja.
- Mi az egyes üzenetek átlagos mérete?
Milyen a forgalmi minta? (vagyis az üzenetek percenkénti száma, valamint az, hogy a kliens folyamatosan terhelt-e, vagy vannak-e lassabb forgalmú időszakai.)
Repro kód és lépések
- Ez azért fontos, mert gyakran nem tudjuk reprodukálni a problémát a környezetünkben.
Naplók

Visszajelzés

Hasznosnak találta ezt az oldalt?

Utolsó frissítés időpontja: 2026-09-21

Spring JMS hibaelhárítási útmutató

Csatlakozási problémák

A MessageProducer egy helyreállíthatatlan hiba miatt bezárult

Probléma leírása

Okok elemzése

Kerülőmegoldás

A spring.jms.servicebus.idle-timeout használata

JmsTemplate-problémák

Ütemezett üzenetek

JmsListener-problémák

Túl sok kérést küld a Service Busnak annak ellenére, hogy nincsenek üzenetek a kiszolgálón

Probléma leírása

Okok elemzése

Megoldások

1. megoldás. Váltás csak push típusú fogyasztóra és csak helyi ellenőrzésre

2. megoldás. Növelje a fogadási időkorlátot a lekérési gyakoriság csökkentése érdekében.

Előtöltési probléma

Probléma leírása

Okok elemzése

Megoldás

Hogyan hajthat végre AMQP-diszpozíciót a Service Busban?

Konfigurációs problémák

A Service Bus JMS automatikus konfigurációjának letiltása

Probléma leírása

Okok elemzése

Megoldás

Üzenetattribútumok konfigurálása

Hogyan állíthatja be a kimenő üzenetek tartalomtípusát?

Hogyan lehet beállítani a típusazonosító tulajdonság nevét a MappingJackson2MessageConverter esetében?

Duplikált észlelés

Az AMQP-naplózás engedélyezése

További segítség kérése

Erőforrások a Spring Cloud Azure Service Bus JMS starterjéhez

GitHub-problémák bejelentése

Visszajelzés

További források

A `spring.jms.servicebus.idle-timeout` használata