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

Cet article vous aide à résoudre les problèmes de Azure Event Hubs processeur d’événements lorsque vous utilisez le EventProcessorClient type. Utilisez-la pour résoudre les problèmes courants de propriété, d’UC, de mémoire et de récepteur. Pour obtenir des solutions à d’autres problèmes courants que vous pouvez rencontrer lors de l’utilisation de Azure Event Hubs, consultez Résoudre les problèmes Azure Event Hubs.

Échecs de condition préalable 412 lors de l’utilisation d’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, voir la section suivante.

La propriété de partition est fréquemment modifiée

Lorsque le nombre d’instances EventProcessorClient change (autrement dit, lorsque vous ajoutez ou supprimez des instances), les instances en cours d’exécution essaient d’équilibrer la charge des partitions entre elles. Pendant quelques minutes après une modification du nombre de processeurs, les partitions changent de propriétaire. Une fois l’équilibrage effectué, l’attribution des partitions est stable et change rarement. Si la propriété de partition change fréquemment lorsque le nombre de processeurs est constant, il indique probablement un problème. Déposez un problème GitHub avec les journaux et une reproduction.

Le CheckpointStore détermine la propriété des partitions à l’aide d’enregistrements de propriété. À chaque intervalle d’équilibrage de charge, le EventProcessorClient effectue les tâches suivantes :

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 partition. Seuls les enregistrements correspondant à ces critères sont pris en compte.
3. S’il existe des partitions non attribuées et que la charge n’est pas équilibrée entre les instances de EventProcessorClient, le client du processeur d’événements tente de prendre possession d’une partition.
4. Mettez à jour l'enregistrement de propriété des partitions qu'il possède et qui ont un lien actif avec cette partition.

Vous pouvez configurer les intervalles d'équilibrage de charge et d'expiration de propriété lorsque vous créez le EventProcessorClient via le EventProcessorClientBuilder, 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 qui doit s’être écoulée depuis la mise à jour de l’enregistrement de propriété avant que le processeur ne considère qu’une partition n’est plus détenue.

Par exemple, si un enregistrement de propriété a été mis à jour à 9 h 30 et que partitionOwnershipExpirationInterval est de 2 minutes. Lorsqu’un cycle d’équilibrage de charge a lieu et qu’il constate que l’enregistrement de propriété n’a pas été mis à jour dans les 2 dernières minutes ou avant 9 h 32, il considère la partition comme étant sans propriétaire.

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

« ...le récepteur actuel “<RECEIVER_NAME>” dont l’époque est '0' se déconnecte »

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 se produit lorsque l’équilibrage de charge se produit après l’ajout ou la suppression EventProcessorClient d’instances. L’équilibrage de charge est un processus continu. Lorsque vous utilisez le consommateur BlobCheckpointStore, toutes les ~30 secondes (par défaut), le consommateur vérifie quels consommateurs ont une revendication sur chaque partition. Ensuite, il 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 de Epoch.

Toutefois, si vous n’ajoutez pas ou supprimez des instances, un problème sous-jacent existe que vous devez résoudre. 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

Une utilisation élevée du processeur se produit généralement parce qu’une instance possède trop de partitions. Ne dépassez pas trois partitions pour chaque cœur de processeur. Commencez par 1,5 partitions pour chaque cœur de processeur, puis testez 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 de mémoire maximal actuel pour la JVM est insuffisant pour exécuter l’application. Il peut être utile de mesurer les besoins en mémoire 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.

Ne spécifiez -Xmx pas 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. Allouez suffisamment de mémoire à l’hôte pour prendre en charge le tas Java.

Les étapes suivantes décrivent une manière classique de mesurer la valeur maximale du tas Java :

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 JVM chargent tous les objets de domaine, types de classes, instances statiques, pools d’objets (TCP, pools de connexions de base de données), et ainsi de suite.

   En régime permanent, la collection du tas présente un modèle stable en dents de scie, comme le montre 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 tels que JConsole. Observez la mémoire occupée après la GC complète. Souhaitez-vous redimensionner le tas de manière à ce que seuls 30 % soient occupés après la GC complète ? Utilisez cette valeur pour définir la taille maximale du tas (à l’aide de -Xmx).

Si vous utilisez un conteneur, dimensionnez-le en prévoyant environ 1 Go de mémoire supplémentaire pour les besoins en mémoire hors tas de l’instance JVM.

Le client processeur cesse de recevoir

Le client du processeur fonctionne souvent en continu dans une application hôte pendant plusieurs jours d'affilée. Parfois, il remarque que EventProcessorClient ne traite pas une ou plusieurs partitions. En règle générale, il n’existe 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é

Les services EventProcessorClient et Event Hubs garantissent 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, envisagez de 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.

Le client consommateur de bas niveau cesse de recevoir

La bibliothèque Event Hubs fournit le EventHubConsumerAsyncClient en tant que client consommateur de bas niveau. Il est conçu pour les utilisateurs avancés qui ont besoin d’un meilleur contrôle et d’une plus grande flexibilité sur leurs applications réactives. Ce client offre une interface de bas niveau, ce qui vous permet de gérer la rétropression, le threading et la récupération au sein de la chaîne Reactor. Contrairement à EventProcessorClient, EventHubConsumerAsyncClient n’inclut pas de mécanismes de récupération automatique pour toutes les causes terminales. Par conséquent, vous devez gérer les événements terminal et sélectionner les opérateurs de réacteur appropriés pour implémenter des stratégies de récupération.

La EventHubConsumerAsyncClient::receiveFromPartition méthode émet une erreur de terminal lorsque la connexion rencontre une erreur non retenable ou lorsqu’une série de tentatives de récupération de connexion échouent consécutivement, ce qui épuise la limite maximale de nouvelles tentatives. Bien que le récepteur de bas niveau tente de récupérer à partir d’erreurs temporaires, les utilisateurs du client consommateur sont censés gérer les événements terminaux. Si l’on souhaite une réception continue des événements, l’application doit adapter la chaîne Reactor pour créer un nouveau client consommateur lors d’un événement terminal.

Migrer de l'ancienne 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 points de contrôle hérités.

Étapes suivantes

Si les conseils de dépannage de cet article ne permettent pas de résoudre les problèmes lorsque vous utilisez le Kit de développement logiciel (SDK) Azure pour Java bibliothèques clientes, créez un problème dans le Kit de développement logiciel (SDK) Azure pour Java GitHub référentiel.