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 de l'appel, ce qui génère une erreur.

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

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'ensemble du cache sera effacé.

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 que vous publiez des API à l'aide de SmartDocs sur votre portail, bien qu'un sous-ensemble de fonctionnalités ne soit pas encore pris en charge.

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

  • Propriétés allOf permettant de combiner et d'étendre des schémas
  • Références distantes

  Si une fonctionnalité non compatible est référencée dans la spécification OpenAPI, dans certains cas, les outils ignorent la fonctionnalité, mais affichent toujours la documentation de référence de l'API. Dans d'autres cas, une fonctionnalité non compatible entraînera des erreurs qui empêchent l'affichage de la documentation de référence de l'API. Dans les deux cas, vous devez modifier la spécification OpenAPI pour éviter d'utiliser la fonctionnalité non compatible jusqu'à ce qu'elle soit compatible avec une prochaine version.

  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, vous pouvez constater des résultats différents 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.

• 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.
• Lors de la configuration de 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.

Ce problème affecte uniquement les utilisateurs qui utilisent MINT ou pour lesquels MINT est activé dans les installations Edge pour Private Cloud.

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 mise à niveau à partir de versions précédentes de Private Cloud, vous rencontrez un problème avec les processeurs de messages. Une augmentation progressive du nombre de threads ouverts entraînera l'épuisement des ressources. L'exception suivante se produit dans le fichier Edge-message-processor system.log:

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

Une faille de déni de service (DoS) a été récemment découverte dans plusieurs du protocole HTTP/2 (CVE-2023-44487), y compris dans Apigee Edge pour Private Cloud. La faille peut entraîner une attaque par déni de service (DoS) de la fonctionnalité de gestion des 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 pour Private Cloud sont exposés au et peuvent être potentiellement vulnérables. Bien que le protocole HTTP/2 soit activé d'autres composants Edge spécifiques à Edge pour Private Cloud, aucun de ces composants n'est exposées à Internet. Sur les composants non-Edge, comme Cassandra, ZooKeeper et autres, HTTP/2 n'est pas activé. Nous vous recommandons de passer la étapes suivantes pour corriger la faille Edge pour Private Cloud:

• Étapes pour Edge for Private Cloud version 4.51.00.11 ou ultérieure
• Étapes pour les versions d'Edge for Private Cloud antérieures à 4.51.00.11

Suivez ces étapes 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 du 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 du processeur de messages:

      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 du processeur de messages:

      apigee-service edge-router restart

4. Mettre à jour le 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 du processeur de messages:

      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 du processeur de messages:

      apigee-service edge-postgres-server restart

Suivez ces étapes si vous utilisez des versions d'Edge pour Private Cloud antérieures à la version 4.51.00.11:

1. Mettez à jour le serveur de gestion:

   1. Sur chaque nœud du 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 du processeur de messages:

      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 du processeur de messages:

      apigee-service edge-router restart

4. Mettre à jour le 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 du processeur de messages:

      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 du processeur de messages:

      apigee-service edge-postgres-server restart

Apigee-postgresql rencontre des problèmes avec la mise à niveau depuis Edge pour Private Cloud de la version 4.50 ou de la version 4.51 à la version 4.52. Les problèmes principaux se produire 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 Mise à jour d'Apigee Edge 4.50.00 ou 4.51.00 vers la version 4.52.00, veillez à effectuer le <ph type="x-smartling-placeholder"></ph> é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 d'un autre pris en charge système d'exploitation d'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: paramètres du pool de connexions LDAP pour JNDI configurés via le 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, des connexions sont ouvertes et fermé à chaque fois pour un usage unique, créant ainsi un grand nombre 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. 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 de Propriétés JNDI (Java Naming and Directory Interface) en fonction des besoins 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 correspond à appartenant à apigee:apigee.
4. Redémarrez chaque processeur de messages.

Pour vérifier que votre pool de connexions JNDI les propriétés de Google Cloud sont prises en compte, effectuer une commande tcpdump pour observer le comportement du pool de connexions LDAP au fil du temps.

139051927: Latences de traitement proxy élevées détectées dans le processeur de messages impactent tous les proxys d'API. Les symptômes se manifestent par un retard de 200 à 300 ms des temps de traitement par rapport à la normale Réponse de l'API et peuvent se produire aléatoirement, même avec un TPS faible. Cela peut se produire lorsque plus de 50 cibles serveurs auxquels un processeur de messages établit des connexions.

Cause: Les processeurs de messages conservent un cache qui mappe l'URL du serveur cible sur l'objet HTTPClient pour et des connexions sortantes vers les serveurs cibles. Par défaut, ce paramètre est défini sur 50, ce qui peut est trop faible pour la plupart des déploiements. Lorsqu'un déploiement comporte plusieurs combinaisons organisation/environnement dans une configuration, et que le nombre de serveurs cibles dépasse 50 en tout, les URL du serveur cible ne cessent d'être évincés 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 Processeur de messages system.logs pour le mot clé "onEvict" ou "Éviction". Leur présence dans les journaux indique que les URL du serveur cible sont évincés du cache HTTPClient car la taille du cache est trop petite.

Solution: Pour Edge for Private Cloud versions 19.01 et 19.06, vous pouvez modifier et configurer la classe HTTPClient cache, /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 est un exemple. La valeur optimale pour votre configuration doit être supérieure à le nombre de serveurs cibles auxquels le processeur de messages se connecterait. Il n'y a pas de côté effets de définir cette propriété sur une valeur plus élevée. Le seul impact possible serait un processeur de messages amélioré. les délais de traitement des demandes par procuration.

Remarque: Edge pour Private Cloud version 50.00 a le paramètre par défaut de 500.

157933959: Insertions et mises à jour simultanées du même mappage clé-valeur (KVM) limitée au au niveau de l'organisation ou de l'environnement entraînent des données incohérentes et des pertes de mises à jour.

Remarque: cette limitation s'applique uniquement à Edge pour Private Cloud. Edge pour le cloud public et hybride ne sont pas soumis à cette limitation.

Pour contourner ce problème dans Edge pour Private Cloud, créez le KVM au niveau du Champ d'application de apiproxy.