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 ander processorexemplaren het eigendom van partities steelt. Zie de volgende sectie voor meer informatie.

Wijzigingen in het eigendom van partities worden regelmatig gewijzigd

Wanneer het aantal EventProcessorClient exemplaren wordt gewijzigd (dat wil gezegd, worden toegevoegd of verwijderd), proberen de actieve 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-probleem met logboeken en een repro in te stellen.

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

1. Haal de meest recente eigendomsrecords 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 om 9:32 uur, wordt de partitie als niet-eigenaar 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.

"... huidige ontvanger '<RECEIVER_NAME>' met epoch '0' wordt 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 taakverdeling optreedt nadat EventProcessorClient exemplaren 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 de sectie Partition ownership changes frequently section and Filing GitHub issues(s) voor meer informatie.

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 status heeft bereikt, dwingt u een volledige garbagecollection (GC) af met behulp van hulpprogramma's zoals JConsole. Bekijk het 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 bevinden, moet u de grootte van de container aanpassen aan extra ~1 GB geheugen voor de niet-heap-behoefte aan het JVM-exemplaar.

Processorclient ontvangt niet meer

De processorclient wordt vaak voortdurend uitgevoerd in een hosttoepassing gedurende dagen aan het einde. Soms merkt het dat EventProcessorClient een of meer partities niet worden 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.

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 op te slaan in de Azure SDK voor Java GitHub-opslagplaats.