Problemen met azure Event Hubs-gebeurtenisprocessor oplossen

Dit artikel bevat oplossingen voor veelvoorkomende problemen die kunnen optreden wanneer u het EventProcessorClient type gebruikt. Als u op zoek bent naar oplossingen voor andere veelvoorkomende problemen die kunnen optreden wanneer u Azure Event Hubs gebruikt, raadpleegt u Problemen met Azure Event Hubs oplossen.

412 voorwaardefouten wanneer u een gebeurtenisprocessor gebruikt

412 voorwaardefouten treden op wanneer de client probeert het eigendom van een partitie te nemen of te vernieuwen, maar de lokale versie van de eigendomsrecord is verouderd. Dit probleem treedt op wanneer een andere processorinstantie het eigendom van partities overneemt. Zie de volgende sectie voor meer informatie.

Het eigendom van partities verandert vaak

Wanneer het aantal EventProcessorClient exemplaren wordt gewijzigd (dat wil zeggen, worden toegevoegd of verwijderd), proberen de draaiende exemplaren partities tussen zichzelf te verdelen. Enkele minuten nadat het aantal processors is gewijzigd, zullen partities naar verwachting eigenaren wijzigen. Nadat de partitie is verdeeld, moet het eigendom van de partitie stabiel zijn en niet vaak worden gewijzigd. Als het eigendom van partities regelmatig wordt gewijzigd wanneer het aantal processors constant is, duidt dit waarschijnlijk op een probleem. We raden u aan om een GitHub-issue met logboeken en een repro in te dienen.

Het eigendom van de partitie wordt bepaald via de eigendomsrecords in de CheckpointStore. Bij elk taakverdelingsinterval worden de volgende taken door EventProcessorClient uitgevoerd:

1. Haal de meest recente eigendomsgegevens op.
2. Controleer de records om te zien welke records hun tijdstempel niet hebben bijgewerkt binnen het verloopinterval van het partitieeigendom. Alleen records die aan deze criteria voldoen, worden overwogen.
3. Als er niet-beheerde partities zijn en de belasting niet wordt verdeeld tussen exemplaren van EventProcessorClient, probeert de gebeurtenisprocessorclient een partitie te claimen.
4. Werk de eigendomsrecord bij voor de partities die eigenaar zijn van een actieve koppeling naar die partitie.

U kunt de verloopintervallen voor taakverdeling en eigendom configureren wanneer u de EventProcessorClient taakverdeling maakt via de EventProcessorClientBuilder, zoals beschreven in de volgende lijst:

• De methode loadBalancingUpdateInterval(Duration) geeft aan hoe vaak de taakverdelingscyclus wordt uitgevoerd.
• De methode partitionOwnershipExpirationInterval(Duration) geeft de minimale tijd aan sinds de eigendomsrecord is bijgewerkt, voordat de processor een partitie beschouwt die niet is opgegeven.

Als een eigendomsrecord bijvoorbeeld om 9:30 uur is bijgewerkt en partitionOwnershipExpirationInterval 2 minuten is. Wanneer een load balance-cyclus plaatsvindt en het merkt dat de eigendomsrecord niet is bijgewerkt in de afgelopen 2 minuten of vóór 9:32 uur, wordt de partitie als niet in eigendom beschouwd.

Als er een fout optreedt in een van de partitiegebruikers, wordt de bijbehorende consument gesloten, maar wordt er pas geprobeerd deze vrij te maken tot de volgende taakverdelingscyclus.

"...de huidige ontvanger '<RECEIVER_NAME>' met epoch '0' wordt momenteel verbroken"

Het volledige foutbericht ziet er ongeveer als volgt uit:

New receiver 'nil' with higher epoch of '0' is created hence current receiver 'nil' with epoch '0'
is getting disconnected. If you are recreating the receiver, make sure a higher epoch is used.
TrackingId:<GUID>, SystemTracker:<NAMESPACE>:eventhub:<EVENT_HUB_NAME>|<CONSUMER_GROUP>,
Timestamp:2022-01-01T12:00:00}"}

Deze fout wordt verwacht wanneer load balancing optreedt nadat EventProcessorClient instances zijn toegevoegd of verwijderd. Taakverdeling is een doorlopend proces. Wanneer u de BlobCheckpointStore met uw consument gebruikt, controleert de consument elke ~30 seconden (standaard) welke consumenten een claim voor elke partitie hebben en voert vervolgens een bepaalde logica uit om te bepalen of er een partitie van een andere consument moet worden gestolen. Het servicemechanisme dat wordt gebruikt om exclusief eigendom van een partitie te bevestigen, wordt het Epoch genoemd.

Als er echter geen exemplaren worden toegevoegd of verwijderd, is er een onderliggend probleem dat moet worden opgelost. Zie voor meer informatie de sectie Partition ownership changes frequently en Filing GitHub issues.

Hoog CPU-gebruik

Hoog CPU-gebruik is meestal omdat een exemplaar eigenaar is van te veel partities. We raden niet meer dan drie partities aan voor elke CPU-kern. Het is beter om te beginnen met 1,5 partities voor elke CPU-kern en vervolgens te testen door het aantal partities in eigendom te verhogen.

Onvoldoende geheugen en kiezen voor de heapgrootte

Het probleem met onvoldoende geheugen (OOM) kan optreden als de huidige maximale heap voor de JVM onvoldoende is om de toepassing uit te voeren. U kunt de heap-vereiste van de toepassing meten. Pas vervolgens op basis van het resultaat de heap aan door het juiste maximale heap-geheugen in te stellen met behulp van de -Xmx JVM-optie.

U moet niet opgeven -Xmx als een waarde die groter is dan het beschikbare geheugen of de limiet die is ingesteld voor de host (de VM of container), bijvoorbeeld het geheugen dat is aangevraagd in de configuratie van de container. U moet voldoende geheugen toewijzen voor de host om de Java-heap te ondersteunen.

In de volgende stappen wordt een typische manier beschreven om de waarde voor maximale Java Heap te meten:

1. Voer de toepassing uit in een omgeving dicht bij de productie, waarbij de toepassing gebeurtenissen verzendt, ontvangt en verwerkt onder de piekbelasting die in productie wordt verwacht.

2. Wacht totdat de toepassing een stabiele status heeft bereikt. In deze fase zouden de toepassing en JVM alle domeinobjecten, klassetypen, statische exemplaren, objectgroepen (TCP, DB-verbindingsgroepen) enzovoort hebben geladen.

   Onder de stabiele toestand ziet u het stabiele zaagtandvormige patroon voor de heapverzameling, zoals wordt weergegeven in de volgende schermopname:

   

3. Nadat de toepassing de stabiele toestand heeft bereikt, kunt u een volledige garbage collection (GC) uitvoeren met behulp van hulpprogramma's zoals JConsole. Observeer de hoeveelheid geheugen bezet na de volledige GC. U wilt de heap zo groot maken dat slechts 30% na de volledige GC bezet is. U kunt deze waarde gebruiken om de maximale heapgrootte (met behulp van -Xmx) in te stellen.

Als u zich in de container bevindt, zou u de grootte van de container moeten aanpassen aan ongeveer 1 GB extra geheugen voor de niet-heap-geheugenvereisten van de JVM-instance.

Processorclient stopt met ontvangen

De processorclient wordt vaak voortdurend uitgevoerd in een hosttoepassing gedurende dagen aan het einde. Soms merkt het op dat EventProcessorClient een of meer partities niet verwerkt. Meestal is er onvoldoende informatie om te bepalen waarom de uitzondering is opgetreden. Het EventProcessorClient stoppen is het symptoom van een onderliggende oorzaak (dat wil gezegd de racevoorwaarde) die is opgetreden tijdens het herstellen van een tijdelijke fout. Zie GitHub-problemen archiveren voor de informatie die we nodig hebben.

Dubbele EventData ontvangen wanneer de processor opnieuw wordt opgestart

De EventProcessorClient Service en Event Hubs garanderen een minstens één keer levering. U kunt metagegevens toevoegen om dubbele gebeurtenissen te onderscheiden. Zie Voor meer informatie biedt Azure Event Hubs een garantie voor ten minste één levering? op Stack Overflow. Als u slechts eenmaal levering nodig hebt, moet u Service Bus overwegen, die wacht op een bevestiging van de client. Zie Kiezen tussen Azure-berichtenservices voor een vergelijking van de berichtenservices.

Consumentenclient op laag niveau ontvangt niet meer

EventHubConsumerAsyncClient is een consumentenclient op laag niveau die wordt geleverd door de Event Hubs-bibliotheek, ontworpen voor geavanceerde gebruikers die meer controle en flexibiliteit nodig hebben voor hun reactieve toepassingen. Deze client biedt een interface op laag niveau, zodat gebruikers backpressie, threading en herstel binnen de Reactor-keten kunnen beheren. In tegenstelling tot EventProcessorClient, EventHubConsumerAsyncClient bevat geen automatische herstelmechanismen voor alle terminaloorzaken. Daarom moeten gebruikers terminale gebeurtenissen afhandelen en geschikte reactoroperators selecteren om herstelstrategieën te implementeren.

De EventHubConsumerAsyncClient::receiveFromPartition methode verzendt een terminalfout wanneer de verbinding een niet-ophaalbare fout tegenkomt of wanneer een reeks verbindingsherstelpogingen opeenvolgend mislukt, waardoor de maximale limiet voor opnieuw proberen wordt uitgeput. Hoewel de ontvanger op laag niveau probeert te herstellen van tijdelijke fouten, zullen gebruikers van de consumentenclient naar verwachting terminalgebeurtenissen verwerken. Als continue ontvangst van events gewenst is, moet de toepassing de Reactor-keten aanpassen om een nieuwe consumentclient te maken bij een terminal event.

Migreren van verouderde naar nieuwe clientbibliotheek

De migratiehandleiding bevat stappen voor het migreren van de verouderde client en het migreren van verouderde controlepunten.

Volgende stappen

Als de richtlijnen voor probleemoplossing in dit artikel niet helpen bij het oplossen van problemen wanneer u de Azure SDK voor Java-clientbibliotheken gebruikt, raden we u aan een probleem te melden in de Azure SDK voor Java GitHub-repository.