Problèmes connus concernant Apigee

Lorsque la variable de flux cachehit est utilisée après la règle LookupCache, en raison de la manière 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 entraîne une erreur.

Solution:répétez la procédure (passez un deuxième appel) juste après le premier appel.

Définir PurgeChildEntries dans la règle InvalidateCache devrait supprimer définitivement les valeurs de l'élément KeyFragment uniquement, mais vide l'intégralité du cache.

Solution de contournement:utilisez la règle KeyValueMapOperations pour itérer la gestion des versions du cache et éviter d'avoir à invalider le cache.

Cela peut se produire, par exemple, en cas d'exécutions simultanées d'un pipeline de déploiement CI/CD qui exploitent des révisions différentes. Pour éviter ce problème, évitez de déployer des proxys d'API ou des flux SharedFlow avant la fin du déploiement actuel.

Solution:Évitez les déploiements simultanés de proxys d'API ou de flux SharedFlow.

L'API Analytics Edge peut parfois contenir des données en double pour les appels d'API. Dans ce cas, les totaux affichés pour les appels d'API dans Edge API Analytics sont supérieurs aux valeurs comparables affichées dans les outils d'analyse tiers.

Solution:Exportez les données d'analyse et utilisez le champ gateway_flow_id pour dédupliquer les données.

• 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, mais un sous-ensemble de fonctionnalités n'est pas encore compatible.

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

  • Propriétés allOf pour la combinaison et l'extension des schémas
  • Références distantes

  Si une fonctionnalité incompatible est référencée dans votre Spécification OpenAPI, il arrive que les outils ignorent la fonctionnalité, mais affichent toujours la documentation de référence de l'API. Dans d'autres cas, une fonctionnalité incompatible peut entraîner des erreurs empêchant l'affichage de la documentation de référence de l'API. Dans les deux cas, vous devez modifier votre Spécification OpenAPI afin d'éviter d'utiliser la fonctionnalité non compatible jusqu'à ce qu'elle soit prise en charge dans une version ultérieure.

  Remarque: Étant donné que l'éditeur de spécifications est moins restrictif que SmartDocs lors de l'affichage de la documentation de référence de l'API, les résultats peuvent varier entre les outils.

• 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.
• 138438484 : Plusieurs serveurs ne sont pas acceptés.

• 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, il peut s'écouler jusqu'à 15 minutes avant que les modifications ne soient appliquées.
• 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 ajoutée au portail intégré dans une prochaine version.

Les accroches Java du client qui tentent de charger le fournisseur de cryptographie Bouncy Castle en utilisant le nom "BC" peuvent échouer, car le fournisseur par défaut a été remplacé par Bouncy Castle FIPS pour prendre en charge FIPS. Le nouveau nom du fournisseur à utiliser est "BCFIPS".

Avec Nginx 1.26 sur les nœuds de routeur, certains champs ne sont pas consignés dans les journaux d'accès et d'erreur. Nginx 1.20.1 est compatible avec la version 4.53.00 et peut être utilisé jusqu'à ce que le problème soit résolu dans un prochain correctif Apigee.

Ce problème ne concerne que les utilisateurs qui utilisent MINT ou qui l'ont activé dans les installations Edge pour le cloud privé.

Composant concerné:edge-message-processor

Problème:si la monétisation est activée et que vous installez la version 4.52.01 en tant que nouvelle installation ou que vous effectuez une mise à niveau à partir de versions précédentes du cloud privé, vous rencontrerez un problème avec les processeurs de messages. Le nombre de threads ouverts augmente progressivement, ce qui entraîne l'épuisement des ressources. L'exception suivante s'affiche dans le fichier system.log du processeur de messages Edge:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread

Une faille par déni de service (DoS) a récemment été détectée dans plusieurs implémentations du protocole HTTP/2 (CVE-2023-44487), y compris dans Apigee Edge pour le cloud privé. La faille pourrait entraîner un déni de service de la fonctionnalité de gestion d'API Apigee. Pour en savoir plus, consultez le bulletin de sécurité Apigee GCP-2023-032.

Les composants du routeur et du serveur de gestion Edge for Private Cloud sont exposés sur Internet et peuvent être vulnérables. Bien que HTTP/2 soit activé sur le port de gestion d'autres composants propres à Edge de Edge pour Private Cloud, aucun de ces composants n'est exposé à Internet. Sur les composants autres que Edge, tels que Cassandra, Zookeeper et d'autres, HTTP/2 n'est pas activé. Nous vous recommandons de suivre la procédure ci-dessous pour corriger la faille Edge pour le cloud privé:

• Étapes à suivre pour Edge pour le cloud privé version 4.51.00.11 ou ultérieure
• Étapes à suivre pour les versions d'Edge pour le cloud privé antérieures à 4.51.00.11

Suivez cette procédure si vous utilisez Edge Private Cloud version 4.51.00.11 ou ultérieure:

1. Mettez à jour le serveur de gestion:

   1. Sur chaque nœud de serveur de gestion, ouvrez /opt/apigee/customer/application/management-server.properties.
   2. Ajoutez la ligne suivante au fichier de propriétés:

      conf_webserver_http2.enabled=false

   3. Redémarrez le composant du serveur de gestion:

      apigee-service edge-management-server restart

2. Mettez à jour le processeur de messages:

   1. Sur chaque nœud de processeur de messages, ouvrez /opt/apigee/customer/application/message-processor.properties.
   2. Ajoutez la ligne suivante au fichier de propriétés:

      conf_webserver_http2.enabled=false

   3. Redémarrez le composant Message Processor:

      apigee-service edge-message-processor restart

3. Mettez à jour le routeur:

   1. Sur chaque nœud de routeur, ouvrez /opt/apigee/customer/application/router.properties.
   2. Ajoutez la ligne suivante au fichier de propriétés:

      conf_webserver_http2.enabled=false

   3. Redémarrez le composant Message Processor:

      apigee-service edge-router restart

4. Mise à jour du QPID:

   1. Sur chaque nœud QPID, ouvrez /opt/apigee/customer/application/qpid-server.properties.
   2. Ajoutez la ligne suivante au fichier de propriétés:

      conf_webserver_http2.enabled=false

   3. Redémarrez le composant Message Processor:

      apigee-service edge-qpid-server restart

5. Mettez à jour Postgres:

   1. Sur chaque nœud Postgres, ouvrez /opt/apigee/customer/application/postgres-server.properties
   2. Ajoutez la ligne suivante au fichier de propriétés:

      conf_webserver_http2.enabled=false

   3. Redémarrez le composant Message Processor:

      apigee-service edge-postgres-server restart

Suivez cette procédure si vous utilisez des versions d'Edge pour le cloud privé antérieures à 4.51.00.11:

1. Mettez à jour le serveur de gestion:

   1. Sur chaque nœud de serveur de gestion, ouvrez /opt/apigee/customer/application/management-server.properties.
   2. Ajoutez les deux lignes suivantes au fichier de propriétés:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Redémarrez le composant du serveur de gestion:

      apigee-service edge-management-server restart

2. Mettez à jour le processeur de messages:

   1. Sur chaque nœud de processeur de messages, ouvrez /opt/apigee/customer/application/message-processor.properties.
   2. Ajoutez les deux lignes suivantes au fichier de propriétés:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Redémarrez le composant Message Processor:

      apigee-service edge-message-processor restart

3. Mettez à jour le routeur:

   1. Sur chaque nœud de routeur, ouvrez /opt/apigee/customer/application/router.properties.
   2. Ajoutez les deux lignes suivantes au fichier de propriétés:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Redémarrez le composant Message Processor:

      apigee-service edge-router restart

4. Mise à jour du QPID:

   1. Sur chaque nœud QPID, ouvrez /opt/apigee/customer/application/qpid-server.properties.
   2. Ajoutez les deux lignes suivantes au fichier de propriétés:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Redémarrez le composant Message Processor:

      apigee-service edge-qpid-server restart

5. Mettez à jour Postgres:

   1. Sur chaque nœud Postgres, ouvrez /opt/apigee/customer/application/postgres-server.properties
   2. Ajoutez les deux lignes suivantes au fichier de propriétés:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Redémarrez le composant Message Processor:

      apigee-service edge-postgres-server restart

Apigee-postgresql rencontre des problèmes lors de la mise à niveau de la version 4.50 ou 4.51 d'Edge pour un cloud privé vers la version 4.52. Les problèmes surviennent 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 de contournement:Lorsque vous mettez à niveau 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.

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 entraînent des connexions à usage unique à chaque fois. Par conséquent, les connexions sont ouvertes et fermées à chaque fois pour une seule utilisation, ce qui crée un grand nombre de connexions par heure au serveur LDAP.

Solution :

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

1. Créez un fichier de propriétés de configuration s'il n'existe pas déjà:

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

2. Ajoutez les éléments suivants au fichier (remplacez les valeurs des propriétés JNDI (Java Naming and Directory Interface) en fonction de vos exigences de configuration des ressources 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 à apigee:apigee.
4. Redémarrez chaque processeur de messages.

Pour vérifier que les propriétés JNDI de votre pool de connexions prennent effet, vous pouvez effectuer un tcpdump pour observer le comportement du pool de connexions LDAP au fil du temps.

139051927: Les latences de traitement des proxys élevées détectées dans le processeur de messages affectent tous les proxys d'API. Les symptômes incluent des délais de traitement de 200 à 300 ms par rapport aux temps de réponse normaux 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 sont connectés à un processeur de messages.

Cause du problème:les processeurs de messages conservent un cache qui met en correspondance l'URL du serveur cible avec l'objet HTTPClient pour les connexions sortantes vers les 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'un déploiement comporte plusieurs combinaisons org/env dans une configuration et un grand nombre de serveurs cibles dépassant 50 au total, les URL des serveurs cibles sont constamment supprimé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 le mot clé "onEvict" ou "Eviction" dans les journaux système 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 faible.

Solution de contournement: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. Apportez les mêmes modifications pour tous les processeurs de messages.

La valeur 500 en 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. Le fait de définir cette propriété sur une valeur plus élevée n'a aucun effet secondaire. Le seul impact est une amélioration des délais de traitement des requêtes de proxy du processeur de messages.

Remarque:La valeur par défaut de la version 50.00 d'Edge pour le cloud privé est 500.

157933959: Les insertions et mises à jour simultanées d'un même mappage clé-valeur (KVM) défini au niveau de l'organisation ou de l'environnement entraînent des données incohérentes et des mises à jour perdues.

Remarque:Cette limite ne s'applique qu'à Edge pour le cloud privé. Edge for Public Cloud et Hybrid ne sont pas soumis à cette limitation.

Pour contourner le problème dans Edge pour le cloud privé, créez le KVM au niveau de l'étendue apiproxy.