Problèmes connus liés à Apigee Edge

Lorsque la variable de flux cachehit est utilisée après la règle LookupCache, en raison de la façon dont les points de débogage sont distribués pour le comportement asynchrone, LookupPolicy renseigne l'objet DebugInfo avant l'exécution du rappel, ce qui génère une erreur.

Solution:répétez le processus (effectuez un deuxième appel) tout de suite après le premier.

Si vous définissez PurgeChildEntries dans la règle InvalidateCache, seules les valeurs de l'élément KeyFragment seront supprimées définitivement, mais l'intégralité du cache sera effacée.

Solution:utilisez la règle KeyValueMapOperations pour itérer la gestion des versions du cache et contourner le besoin d'invalidation du cache.

• Apigee Edge est compatible avec la spécification OpenAPI 3.0 lorsque vous créez des spécifications à l'aide de l'éditeur de spécifications et publiez des API à l'aide de SmartDocs sur votre portail, bien qu'un sous-ensemble de fonctionnalités ne soit pas encore disponible.

  Par exemple, les fonctionnalités suivantes de la spécification OpenAPI 3.0 ne sont pas encore compatibles :

  • Propriétés allOf pour combiner et étendre des schémas
  • Références distantes

  Si une fonctionnalité non compatible est référencée dans la spécification OpenAPI, il est possible que les outils ignorent la fonctionnalité, mais affichent toujours la documentation de référence de l'API. Dans les autres cas, une fonctionnalité non compatible générera des erreurs qui empêcheront l'affichage réussi de la documentation de référence de l'API. Dans les deux cas, vous devez modifier la spécification OpenAPI afin d'éviter d'utiliser cette fonctionnalité jusqu'à ce qu'elle soit compatible dans une prochaine version.

  Remarque: L'éditeur de spécifications étant moins restrictif que SmartDocs lors de l'affichage de la documentation de référence de l'API, les outils peuvent générer des résultats différents.

• Lorsque vous utilisez cette API dans le portail, l'en-tête Accept est défini sur application/json, quelle que soit la valeur définie pour consumes dans la spécification OpenAPI.

• Pour le moment, les mises à jour simultanées du portail (telles que les modifications de pages, de thèmes, de CSS ou de scripts) par plusieurs utilisateurs ne sont pas acceptées.
• Si vous supprimez une page de documentation de référence de l'API à partir du portail, vous ne pouvez pas la recréer. Vous devrez supprimer et rajouter le produit d'API, puis générer à nouveau la documentation de référence de l'API.
• Lorsque vous configurez la stratégie de sécurité du contenu, l'application complète des modifications peut prendre jusqu'à 15 minutes.
• Lorsque vous personnalisez le thème de votre portail, un délai de cinq minutes peut être nécessaire pour que les modifications soient appliquées.

• La recherche sera intégrée au portail intégré dans une prochaine version.

Apigee-postgresql rencontre des problèmes avec la mise à niveau d'Edge pour Private Cloud version 4.50 ou 4.51 vers la version 4.52. Les problèmes se produisent principalement lorsque le nombre de tables est supérieur à 500.

Vous pouvez vérifier le nombre total de tables dans Postgres en exécutant la requête SQL ci-dessous:

select count(*) from information_schema.tables

Solution:Lorsque vous mettez à jour Apigee Edge 4.50.00 ou 4.51.00 vers la version 4.52.00, veillez à effectuer l' étape préliminaire avant de mettre à niveau Apigee-postgresql.

apigee-mirror ne fonctionne pas sur Red Hat Enterprise Linux (RHEL) 8.0.

Solution:pour contourner ce problème, installez apigee-mirror sur un serveur exécutant une version antérieure de RHEL ou un autre système d'exploitation compatible pour Apigee. Vous pouvez ensuite utiliser le miroir pour ajouter des packages, même si vous avez installé Apigee sur des serveurs RHEL 8.0.

149245401: les paramètres du pool de connexions LDAP pour JNDI configurés via la ressource LDAP ne sont pas reflétés, et les valeurs par défaut de JNDI génèrent des connexions à usage unique à chaque fois. Par conséquent, les connexions s'ouvrent et se ferment à chaque fois pour un usage unique, créant ainsi un grand nombre de connexions au serveur LDAP par heure.

Solution :

Pour modifier les propriétés du pool de connexions LDAP, procédez comme suit afin de définir une modification globale pour l'ensemble des règles LDAP.

1. S'il n'existe pas encore, créez un fichier de propriétés de configuration :

   /opt/apigee/customer/application/message-processor.properties

2. Ajoutez le code suivant au fichier (remplacez les valeurs des propriétés JNDI (Java Name and Directory Interface) en fonction de la configuration requise pour la ressource LDAP).

   bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
   -Dcom.sun.jndi.ldap.connect.pool.prefsize=2
   -Dcom.sun.jndi.ldap.connect.pool.initsize=2
   -Dcom.sun.jndi.ldap.connect.pool.timeout=120000
   -Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"

3. Assurez-vous que le fichier /opt/apigee/customer/application/message-processor.properties appartient au projet apigee:apigee.
4. Redémarrez chaque processeur de message.

Pour vérifier que les propriétés JNDI du pool de connexion prennent effet, vous pouvez effectuer une tcpdump afin d'observer le comportement du pool de connexions LDAP au fil du temps.

139051927: les latences de traitement proxy élevées détectées dans le processeur de messages affectent tous les proxys d'API. Les symptômes sont des délais de traitement de 200 à 300 ms par rapport à la normale de la réponse de l'API et peuvent se produire de manière aléatoire, même avec un TPS faible. Cela peut se produire lorsque plus de 50 serveurs cibles utilisent un processeur de messages pour se connecter.

Cause principale: Les processeurs de messages conservent un cache qui mappe l'URL du serveur cible à un objet HTTPClient pour les connexions sortantes aux serveurs cibles. Par défaut, ce paramètre est défini sur 50, ce qui peut être trop faible pour la plupart des déploiements. Lorsqu'une configuration comporte plusieurs combinaisons organisation/env dans une configuration, et que le nombre de serveurs cibles dépasse la limite de 50 dans leur ensemble, les URL des serveurs cibles sont évincées du cache, ce qui entraîne des latences.

Validation:pour déterminer si l'éviction de l'URL du serveur cible est à l'origine du problème de latence, recherchez "onEvict" ou "Eviction" dans le fichier system.logs du processeur de messages. Leur présence dans les journaux indique que les URL de serveur cible sont supprimées du cache HTTPClient, car la taille du cache est trop petite.

Solution:Pour les versions 19.01 et 19.06 d'Edge pour le cloud privé, vous pouvez modifier et configurer le cache HTTPClient /opt/apigee/customer/application/message-processor.properties:

conf/http.properties+HTTPClient.dynamic.cache.elements.size=500

Redémarrez ensuite le processeur de messages. Effectuez les mêmes modifications pour tous les processeurs de messages.

La valeur 500 est un exemple. La valeur optimale pour votre configuration doit être supérieure au nombre de serveurs cibles auxquels le processeur de messages se connecterait. Définir cette propriété à un niveau supérieur n'a aucun effet secondaire, et le seul impact serait une réduction du temps de traitement des requêtes proxy pour le processeur de messages.

Remarque: Edge pour Private Cloud version 50.00 est défini par défaut sur 500.

157933959: les insertions et les mises à jour simultanées sur la même map de clés-valeurs (KVM) limitées au niveau de l'organisation ou de l'environnement génèrent des données incohérentes et des mises à jour perdues.

Remarque:Cette restriction ne s'applique qu'à Edge pour le cloud privé. Edge for Public Cloud et Hybrid ne sont pas limités.

Pour contourner ce problème dans Edge pour le cloud privé, créez le KVM dans le champ d'application apiproxy.