Vous consultez la documentation Apigee Edge.
Accéder à la documentation d'Apigee X en savoir plus
Les sections suivantes décrivent les problèmes connus liés à Apigee. Dans la plupart des cas, les problèmes listés seront résolus dans une prochaine version.
Problèmes connus de divers problèmes liés à Edge
Les sections suivantes décrivent divers problèmes connus concernant Edge.
Quartier | Problèmes connus |
---|---|
L'expiration du cache entraîne une valeur cachehit incorrecte |
Lorsque la variable de flux Solution:répétez le processus (effectuez un deuxième appel) juste après le premier appel. |
La définition de la règle InvalidateCache PurgeChildEntries sur "true" ne fonctionne pas correctement |
Si vous définissez Solution:Utilisez la règle KeyValueMapOperations pour itérer la gestion des versions du cache et contourner le besoin d'invalidation du cache. |
Problèmes connus avec l'interface utilisateur Edge
Les sections suivantes décrivent les problèmes connus liés à l'interface utilisateur Edge.
Zone | Problèmes connus |
---|---|
Impossible d'accéder à la page d'administration de la zone d'authentification unique Edge à partir de la barre de navigation une fois l'organisation associée à une zone d'identité | Lorsque vous connectez une organisation à une zone d'identité, vous ne pouvez plus accéder à la page Administration des zones d'authentification unique d'Edge dans la barre de navigation de gauche en sélectionnant Administrateur > Authentification unique. Pour contourner ce problème, accédez directement à la page à l'aide de l'URL suivante: https://apigee.com/sso. |
Problèmes connus concernant le portail intégré
Les sections suivantes décrivent les problèmes connus liés au portail intégré.
Zone | Problèmes connus |
---|---|
SmartDocs |
|
Fournisseur d'identité SAML | La déconnexion unique (SLO) avec le fournisseur d'identité SAML n'est pas acceptée pour les domaines personnalisés. Pour activer un domaine personnalisé avec un fournisseur d'identité SAML, laissez le champ URL de déconnexion vide lorsque vous configurez les paramètres SAML. |
Administrateur du portail |
|
Fonctionnalités du portail |
|
Problèmes connus avec Edge pour Private Cloud
Les sections suivantes décrivent les problèmes connus avec Edge pour Private Cloud.
Quartier | Problèmes connus |
---|---|
Mise à jour d'OPDK 4.52.01 Mint |
Ce problème n'affecte que ceux qui utilisent MINT ou pour lesquels MINT est activé dans les installations Edge pour Private Cloud. Composant concerné:Edge-message-processor Problème:Si vous avez activé la monétisation et que vous installez la version 4.52.01 en tant que nouvelle installation ou mise à niveau à partir d'une version précédente du cloud privé, vous rencontrez un problème avec les processeurs de messages. Le nombre de threads ouverts va progressivement augmenter, ce qui entraînera l'épuisement des ressources. L'exception suivante est visible dans le fichier journal système du processeur de messages en périphérie: Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread |
Vulnérabilité HTTP/2 Apigee | Une faille de déni de service (DoS) a été récemment détectée dans plusieurs mises en œuvre du protocole HTTP/2 (CVE-2023-44487), y compris dans Apigee Edge pour le cloud privé. La faille pourrait entraîner une attaque DoS de la fonctionnalité de gestion d'API Apigee. Pour en savoir plus, consultez le bulletin de sécurité Apigee GCP-2023-032. Les composants Edge for Private Cloud du routeur et du serveur de gestion sont exposés à Internet et peuvent être potentiellement vulnérables. Bien que HTTP/2 soit activé sur le port de gestion d'autres composants spécifiques à Edge de Edge for Private Cloud, aucun de ces composants n'est exposé à Internet. Sur les composants autres que Edge, tels que Cassandra, Zookeeper et autres, HTTP/2 n'est pas activé. Nous vous recommandons de suivre les étapes ci-dessous pour corriger la faille Edge for Private Cloud:
Procédez comme suit si vous utilisez Edge Private Cloud version 4.51.00.11 ou ultérieure:
Procédez comme suit si vous utilisez Edge pour des versions de Private Cloud antérieures à 4.51.00.11:
|
Mise à niveau de Postgresql lors de la mise à jour vers la version 4.52 | Apigee-postgresql rencontre des problèmes lors de la mise à niveau de Edge for Private Cloud version 4.50 ou 4.51 vers la version 4.52. Ces 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: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 sur RHEL 8.0 |
Solution:Pour contourner ce problème, installez |
Règle LDAP | 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 utilisation unique, ce qui crée un grand nombre de connexions par heure au serveur LDAP. Solution : Si vous souhaitez modifier les propriétés du pool de connexions LDAP, procédez comme suit afin de définir une modification globale pour toutes les règles LDAP.
Pour vérifier que les propriétés JNDI de votre pool de connexions prennent effet, vous pouvez exécuter une commande tcpdump afin d'observer le comportement du pool de connexions LDAP au fil du temps. |
Délai de traitement des demandes élevé | 139051927: les latences de traitement par proxy élevées détectées dans le processeur de messages affectent tous les proxys d'API. Les symptômes sont des retards de 200 à 300 ms dans les temps de traitement par rapport aux temps de réponse normaux de l'API et peuvent survenir de manière aléatoire, même avec un TPS faible. Cela peut se produire lorsqu'un processeur de messages établit des connexions sur plus de 50 serveurs cibles. Cause: les processeurs de messages conservent un cache qui mappe l'URL du serveur cible sur 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 organisation/environnement dans une configuration et qu'un grand nombre de serveurs cibles dépasse 50 au total, les URL des serveurs cibles continuent d'être 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 du serveur cible sont supprimées du cache HTTPClient, car la taille du cache est trop faible. Solution:Pour Edge for Private Cloud versions 19.01 et 19.06, vous pouvez modifier et configurer le cache HTTPClient, conf/http.properties+HTTPClient.dynamic.cache.elements.size=500 Redémarrez ensuite le processeur de messages. Apportez les mêmes modifications à 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. Définir cette propriété à une valeur plus élevée n'a aucun effet secondaire. Le seul impact serait l'amélioration des temps de traitement des requêtes proxy du processeur de messages.
Remarque:Edge pour Private Cloud version 50.00 a le paramètre par défaut de 500. |
Plusieurs entrées pour les mappages clé-valeur | 157933959: les insertions et les mises à jour simultanées d'un même mappage de clé-valeur (KVM) au niveau de l'organisation ou de l'environnement entraînent des données incohérentes et la perte des mises à jour. Remarque: Cette limitation s'applique uniquement à Edge for Private Cloud. Cette limite ne s'applique pas à Edge for Public Cloud et Hybrid. Pour une solution de contournement dans Edge pour Private Cloud, créez le KVM au champ d'application |