Résoudre les problèmes liés au processeur d’événements Azure Event Hubs

Cet article fournit des solutions aux problèmes courants que vous pouvez rencontrer lorsque vous utilisez le EventProcessorClient type. Si vous recherchez des solutions à d’autres problèmes courants que vous pouvez rencontrer lorsque vous utilisez Azure Event Hubs, consultez Résoudre les problèmes liés à Azure Event Hubs.

Échecs de condition préalable 412 lorsque vous utilisez un processeur d’événements

Les erreurs de condition préalable 412 se produisent lorsque le client tente de prendre ou de renouveler la propriété d’une partition, mais que la version locale de l’enregistrement de propriété est obsolète. Ce problème se produit quand une autre instance de processeur vole la propriété de partition. Pour plus d'informations, consultez la section suivante.

Les modifications de propriété de partition changent fréquemment

Lorsque le nombre d’instances EventProcessorClient change (autrement dit, sont ajoutées ou supprimées), les instances en cours d’exécution tentent d’équilibrer la charge des partitions entre elles. Pendant quelques minutes après le nombre de modifications de processeurs, les partitions sont censées changer les propriétaires. Une fois équilibrée, la propriété de partition doit être stable et changer rarement. Si la propriété de partition change fréquemment lorsque le nombre de processeurs est constant, il indique probablement un problème. Nous vous recommandons de déposer un problème GitHub avec les journaux et une reproduction.

La propriété de partition est déterminée via les enregistrements de propriété dans le CheckpointStore. Sur chaque intervalle d’équilibrage de charge, les EventProcessorClient tâches suivantes sont effectuées :

1. Récupérez les derniers enregistrements de propriété.
2. Vérifiez les enregistrements pour voir quels enregistrements n’ont pas mis à jour leur horodatage dans l’intervalle d’expiration de propriété de la partition. Seuls les enregistrements correspondant à ces critères sont pris en compte.
3. S’il existe des partitions non noyées et que la charge n’est pas équilibrée entre les instances de EventProcessorClient, le client du processeur d’événements tente de revendiquer une partition.
4. Mettez à jour l’enregistrement de propriété pour les partitions dont il possède un lien actif vers cette partition.

Vous pouvez configurer les intervalles d’expiration de charge et d’expiration de propriété lorsque vous créez le EventProcessorClient via le EventProcessorClientBuilderfichier , comme décrit dans la liste suivante :

• La méthode loadBalancingUpdateInterval(Duration) indique la fréquence à laquelle le cycle d’équilibrage de charge s’exécute.
• La méthode partitionOwnershipExpirationInterval(Duration) indique la durée minimale depuis la mise à jour de l’enregistrement de propriété, avant que le processeur ne considère qu’une partition non noyée.

Par exemple, si un enregistrement de propriété a été mis à jour à 9 h 30 et partitionOwnershipExpirationInterval est de 2 minutes. Lorsqu’un cycle d’équilibrage de charge se produit et qu’il remarque que l’enregistrement de propriété n’a pas été mis à jour au cours des 2 dernières minutes ou de 9 h 32, il prend en compte la partition non noyée.

Si une erreur se produit dans l’un des consommateurs de partition, elle ferme le consommateur correspondant, mais ne tente pas de la récupérer jusqu’au prochain cycle d’équilibrage de charge.

"... le récepteur actuel '<RECEIVER_NAME>' avec l’époque '0' est déconnecté »

Le message d’erreur entier ressemble à la sortie suivante :

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

Cette erreur est attendue lorsque l’équilibrage de charge se produit une fois EventProcessorClient les instances ajoutées ou supprimées. L’équilibrage de charge est un processus continu. Lorsque vous utilisez le BlobCheckpointStore consommateur, toutes les 30 secondes (par défaut), le consommateur case activée pour voir quels consommateurs ont une revendication pour chaque partition, puis exécute une logique pour déterminer s’il doit « voler » une partition d’un autre consommateur. Le mécanisme de service utilisé pour affirmer la propriété exclusive sur une partition est connu sous le nom d’époque.

Toutefois, si aucune instance n’est ajoutée ou supprimée, il existe un problème sous-jacent qui doit être résolu. Pour plus d’informations, consultez la section Modification fréquente de la propriété de partition et classement des problèmes GitHub.

Utilisation élevée du processeur

L’utilisation élevée du processeur est généralement due au fait qu’une instance possède trop de partitions. Nous vous recommandons de ne pas dépasser trois partitions pour chaque cœur de processeur. Il est préférable de commencer par 1,5 partitions pour chaque cœur de processeur, puis de tester en augmentant le nombre de partitions détenues.

Mémoire insuffisante et choix de la taille du tas

Le problème de mémoire insuffisante (OOM) peut se produire si le tas maximal actuel pour la machine virtuelle JVM est insuffisant pour exécuter l’application. Vous pouvez mesurer l’exigence du tas de l’application. Ensuite, en fonction du résultat, dimensionner le tas en définissant la mémoire maximale maximale appropriée à l’aide de l’option -Xmx JVM.

Vous ne devez pas spécifier -Xmx comme valeur supérieure à la mémoire disponible ou limite définie pour l’hôte (la machine virtuelle ou le conteneur), par exemple la mémoire demandée dans la configuration du conteneur. Vous devez allouer suffisamment de mémoire à l’hôte pour prendre en charge le tas Java.

Les étapes suivantes décrivent un moyen classique de mesurer la valeur du tas Java maximal :

1. Exécutez l’application dans un environnement proche de la production, où l’application envoie, reçoit et traite des événements sous la charge maximale attendue en production.

2. Attendez que l’application atteigne un état stable. À ce stade, l’application et la machine virtuelle JVM auraient chargé tous les objets de domaine, types de classes, instances statiques, pools d’objets (TCP, pools de connexions de base de données), etc.

   Sous l’état stable, vous voyez le modèle stable en forme de sawtooth pour la collection de tas, comme illustré dans la capture d’écran suivante :

   

3. Une fois que l’application a atteint l’état stable, forcez un garbage collection complet (GC) à l’aide d’outils comme JConsole. Observez la mémoire occupée après le GC complet. Vous souhaitez dimensionner le tas de sorte que seulement 30 % sont occupés après le GC complet. Vous pouvez utiliser cette valeur pour définir la taille maximale du tas (à l’aide -Xmxde ).

Si vous êtes sur le conteneur, dimensionner le conteneur pour avoir une mémoire supplémentaire d’environ 1 Go pour le tas non nécessaire pour l’instance JVM.

Le client processeur cesse de recevoir

Le client de processeur s’exécute souvent en permanence dans une application hôte pendant des jours à la fin. Parfois, il remarque qu’il EventProcessorClient ne traite pas une ou plusieurs partitions. En règle générale, il n’y a pas suffisamment d’informations pour déterminer la raison pour laquelle l’exception s’est produite. L’arrêt EventProcessorClient est le symptôme d’une cause sous-jacente (autrement dit, la condition de concurrence) qui s’est produite lors de la tentative de récupération à partir d’une erreur temporaire. Pour plus d’informations, consultez Le dépôt de problèmes GitHub.

Dupliquer EventData reçu lorsque le processeur est redémarré

Le EventProcessorClient service Event Hubs garantit une livraison au moins une fois . Vous pouvez ajouter des métadonnées pour discerner les événements en double. Pour plus d’informations, consultez Azure Event Hubs garantit-il une livraison au moins une fois sur Stack Overflow. Si vous avez besoin d’une livraison une seule fois , vous devez prendre en compte Service Bus, qui attend un accusé de réception du client. Pour une comparaison des services de messagerie, consultez Choisir entre les services de messagerie Azure.

Migrer de l’hérité vers une nouvelle bibliothèque cliente

Le guide de migration comprend des étapes sur la migration à partir du client hérité et la migration de case activée points hérités.

Étapes suivantes

Si les conseils de dépannage de cet article n’aident pas à résoudre les problèmes lorsque vous utilisez le Kit de développement logiciel (SDK) Azure pour les bibliothèques clientes Java, nous vous recommandons de déposer un problème dans le référentiel Azure SDK pour Java GitHub.