Problèmes connus concernant Apigee

Vous consultez la documentation d'Apigee Edge.
Accédez à la documentation sur Apigee X. info

Les sections suivantes décrivent les problèmes connus liés à Apigee. Dans la plupart des cas, les problèmes répertoriés seront résolus dans une prochaine version.

Miscellaneous Edge known issues

The following sections describe miscellaneous known issues with Edge.

Area/Summary Known issues
Cache expire results in incorrect cachehit value

When the cachehit flow variable is used after the LookupCache policy, due to the way debug points are dispatched for asynchronous behavior, the LookupPolicy populates the DebugInfo object before the call back has executed, resulting in an error.

Workaround: Repeat the process (make second call) again right after the first call.

Setting InvalidateCache Policy PurgeChildEntries to true does not work correctly

Setting PurgeChildEntries in the InvalidateCache policy should purge the KeyFragment element values only but clears the entire cache.

Workaround: Use the KeyValueMapOperations policy to iterate cache versioning and bypass the need for cache invalidation.

Concurrent deployment requests for a SharedFlow or API proxy can result in an inconsistent state in the Management Server where multiple revisions are shown as deployed.

This can happen, for example, when concurrent runs of a CI/CD deployment pipeline occur using different revisions. To avoid this problem, avoid deploying API proxies or SharedFlows before the current deployment is complete.

Workaround: Avoid concurrent API proxy or SharedFlow deployments.

API call counts shown in Edge API Analytics might contain duplicate data.

Edge API Analytics can sometimes contain duplicate data for API calls. In that case the counts shown for API calls in Edge API Analytics are higher than the comparable values shown in third-party analytics tools.

Workaround: Export the analytics data and use the gateway_flow_id field to de-duplicate the data.

Known issues with the Edge UI

The following sections describe the known issues with the Edge UI.

Area Known issues
Can't access Edge SSO Zone Administration page from navigation bar after organization is mapped to an identity zone When you connect an organization to an identity zone, you can no longer access the Edge SSO Zone Administration page from the left navigation bar by selecting Admin > SSO. As a workaround, navigate to the page directly using the following URL: https://apigee.com/sso

Problèmes connus liés au portail intégré

Les sections suivantes décrivent les problèmes connus liés au portail intégré.

Zone Problèmes connus
SmartDocs
  • 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.
Fournisseur d'identité SAML La déconnexion unique (SLO) avec le fournisseur d'identité SAML n'est pas disponible pour les domaines personnalisés. Pour activer un domaine personnalisé avec un fournisseur d'identité SAML, laissez le champ Sign-out URL (URL de déconnexion) vide lorsque vous configurez les paramètres SAML.
Administrateur de portail
  • 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.
Fonctionnalités du portail
  • La recherche sera ajoutée au portail intégré dans une prochaine version.

Known issues with Edge for Private Cloud

The following sections describe the known issues with Edge for Private Cloud.

Area Known issues
Edge for Private Cloud 4.53.00 440148595: End of Life Popup Warning Displayed Excessively

In Edge for Private Cloud 4.53.00 and later, the UI displays an "End of Life" (EOL) warning pop-up. This warning appears
repeatedly and cannot be prevented or reduced in frequency.

There is currently no method available for users to disable or reduce the frequency of this EOL warning.
Edge for Private Cloud 4.53.01
443272053: Datastore errors in edge components

In Edge for Private Cloud 4.53.00 or later, a specific type of interaction between Cassandra and application components (Management server, Message Processor or Router) may cause datastore errors. When such an error occurs, you'll observe logs of the following pattern in the specific application component's system logs:

com.datastax.driver.core.exceptions.ProtocolError: An unexpected protocol error occurred on host WW.XX.YY.ZZ:9042.

These errors occur when the application component is not configured to handle warnings generated by the Cassandra database. You can mitigate this issue by avoiding or suppressing warnings in your Cassandra nodes. In most cases, warnings are generated due to excessive tombstones. You can follow one of the following options or a combination of options listed:

  1. Reduce gc_grace_seconds: For the table displayed in the log message associated with the error, reduce gc_grace_seconds by running the following command like the following, using cqlsh: 
    Below command sets gc_grace_seconds of kms.oauth_20_access_tokens to 1 day from default 10 days
ALTER TABLE kms.oauth_20_access_tokens WITH gc_grace_seconds = '86400';
  2. Increase tombstone thresholds in Cassandra for generating warnings. For this, use the following instructions:
    1. On a Cassandra node, create or edit file $APIGEE_ROOT/customer/application/cassandra.properties.
    2. Increase Tombstone warn threshold to 100k from the default 10k or set larger values as appropriate by adding the following line: 
      conf_cassandra_tombstone_warn_threshold=100000
    3. Ensure the file above is owned and readable by apigee user: 
      chown apigee:apigee $APIGEE_ROOT/customer/application/cassandra.properties
    4. Restart Cassandra application on the node: 
      apigee-service apigee-cassandra restart
    5. Repeat the above steps on each Cassandra node, one by one.
42733857: Latency in updating encrypted key value maps (KVMs)

When working with Encrypted Key Value Maps that contain a large number of entries, users may experience latencies when adding or updating entries, whether through management APIs or the PUT element within the KeyValueMapOperations policy . The extent of the performance impact is generally proportional to the total number of entries stored in the encrypted KVM.

To mitigate this issue, it is recommended that users avoid creating encrypted KVMs with an excessive number of entries. A viable solution is to divide a large KVM into multiple, smaller KVMs. Additionally, if the use case permits, migrating to a non-encrypted KVM can also serve as an effective mitigation strategy. Please note that Apigee is aware of this issue and plans to release a fix in a future patch.
Java Callouts

Customer Java callouts that attempt to load the Bouncy Castle cryptography provider using the name "BC" might fail because the default provider has been changed to Bouncy Castle FIPS to support FIPS. The new provider name to use is "BCFIPS".
Edge for Private Cloud 4.53.00
Java Callouts

Customer Java callouts that attempt to load the Bouncy Castle cryptography provider using the name "BC" might fail because the default provider has been changed to Bouncy Castle FIPS to support FIPS. The new provider name to use is "BCFIPS".
Edge for Private Cloud 4.52.01 Mint update

This issue affects only those who are using MINT or have MINT enabled in Edge for Private Cloud installations.

Component affected: edge-message-processor

Issue: If you have monetization enabled and are installing 4.52.01 as a fresh install or upgrading from previous Private Cloud versions, you will encounter an issue with message processors. There will be a gradual increase in open thread count leading to resource exhaustion. The following exception is seen in edge-message-processor system.log:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread
Apigee HTTP/2 vulnerability

A Denial-of-Service (DoS) vulnerability was recently discovered in multiple implementations of the HTTP/2 protocol (CVE-2023-44487), including in Apigee Edge for Private Cloud. The vulnerability could lead to a DoS of Apigee API management functionality. For more details, see Apigee Security Bulletin GCP-2023-032.

The Edge for Private Cloud router and management server components are exposed to the internet and can potentially be vulnerable. Although HTTP/2 is enabled on the management port of other Edge-specific components of Edge for Private Cloud, none of those components are exposed to the internet. On non-Edge components, like Cassandra, Zookeeper and others, HTTP/2 is not enabled. We recommend that you take the following steps to address the Edge for Private Cloud vulnerability:

Follow these steps if you are using Edge Private Cloud versions 4.51.00.11 or newer:

  1. Update the management server:

    1. On each management server node, open /opt/apigee/customer/application/management-server.properties
    2. Add this line to the properties file: 
      conf_webserver_http2.enabled=false
    3. Restart the management server component: 
      apigee-service edge-management-server restart

  2. Update the message processor:

    1. On each message processor node, open /opt/apigee/customer/application/message-processor.properties
    2. Add this line to the properties file: 
      conf_webserver_http2.enabled=false
    3. Restart the message processor component: 
      apigee-service edge-message-processor restart

  3. Update the router:

    1. On each router node, open /opt/apigee/customer/application/router.properties
    2. Add this line to the properties file: 
      conf_webserver_http2.enabled=false
    3. Restart the message processor component: 
      apigee-service edge-router restart

  4. Update QPID:

    1. On each QPID node, open /opt/apigee/customer/application/qpid-server.properties
    2. Add this line to the properties file: 
      conf_webserver_http2.enabled=false
    3. Restart the message processor component: 
      apigee-service edge-qpid-server restart

  5. Update Postgres:

    1. On each Postgres node, open /opt/apigee/customer/application/postgres-server.properties
    2. Add this line to the properties file: 
      conf_webserver_http2.enabled=false
    3. Restart the message processor component: 
      apigee-service edge-postgres-server restart

Follow these steps if you are using Edge for Private Cloud versions older than 4.51.00.11:

  1. Update the management server:

    1. On each management server node, open /opt/apigee/customer/application/management-server.properties
    2. Add the following two lines to the properties file: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. Restart the management server component: 
      apigee-service edge-management-server restart

  2. Update the message processor:

    1. On each message processor node, open /opt/apigee/customer/application/message-processor.properties
    2. Add the following two lines to the properties file: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. Restart the message processor component: 
      apigee-service edge-message-processor restart

  3. Update the router:

    1. On each router node, open /opt/apigee/customer/application/router.properties
    2. Add the following two lines to the properties file: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. Restart the message processor component: 
      apigee-service edge-router restart

  4. Update QPID:

    1. On each QPID node, open /opt/apigee/customer/application/qpid-server.properties
    2. Add the following two lines to the properties file: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. Restart the message processor component: 
      apigee-service edge-qpid-server restart

  5. Update Postgres:

    1. On each Postgres node, open /opt/apigee/customer/application/postgres-server.properties
    2. Add the following two lines to the properties file: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. Restart the message processor component: 
      apigee-service edge-postgres-server restart
Postgresql upgrade when updating to version 4.52

Apigee-postgresql is having issues with upgrading from Edge for Private Cloud version 4.50 or 4.51 to version 4.52. The issues mainly occur when the number of tables is greater than 500.

You can check the total number of tables in Postgres by running the SQL query below:

select count(*) from information_schema.tables

Workaround: When Updating Apigee Edge 4.50.00 or 4.51.00 to 4.52.00, be sure to perform the preliminary step before upgrading Apigee-postgresql.
LDAP policy

149245401: LDAP connection pool settings for JNDI configured through the LDAP resource are not reflected, and JNDI defaults cause single-use connections each time. As a result, connections are being opened and closed each time for single use, creating a large number of connections per hour to the LDAP server.

Workaround:

In order to change the LDAP connection pool properties, do the following steps to set a global change across all LDAP policies.

  1. Create a configuration properties file if it does not already exist: 
    /opt/apigee/customer/application/message-processor.properties
  2. Add the following to the file (replace values of Java Naming and Directory Interface (JNDI) properties based on your LDAP resource configuration requirement). 
    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. Make sure the file /opt/apigee/customer/application/message-processor.properties is owned by apigee:apigee.
  4. Restart each message processor.

To verify that your connection pool JNDI properties are taking effect, you can perform a tcpdump to observe the behavior of the LDAP connection pool over time.
High Request Processing Latency

139051927: High proxy processing latencies found in the Message Processor are affecting all API Proxies. Symptoms include 200-300ms delays in processing times over normal API response times and can occur randomly even with low TPS. This can occur when than more than 50 target servers in which a message processor makes connections.

Root cause: Message processors keep a cache that maps target server URL to HTTPClient object for outgoing connections to target servers. By default this setting is set to 50 which may be too low for most deployments. When a deployment has multiple org/env combinations in a setup, and have a large number of target servers that exceed 50 altogether, the target server URLs keep getting evicted from cache, causing latencies.

Validation: To determine if target server URL eviction is causing the latency problem, search the Message Processor system.logs for keyword "onEvict" or "Eviction". Their presence in the logs indicate that target server URLs are getting evicted from the HTTPClient cache because the cache size is too small.

Workaround: For Edge for Private Cloud versions 19.01 and 19.06, you can edit and configure the HTTPClient cache, /opt/apigee/customer/application/message-processor.properties:

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

Then restart the message processor. Make the same changes for all message processors.

The value 500 is an example. The optimal value for your setup should be greater than the number of target servers that the message processor would connect to. There are no side effects from setting this property higher, and the only affect would be an improved message processor proxy request processing times.

Note: Edge for Private Cloud version 50.00 has the default setting of 500.
Multiple entries for key value maps

157933959: Concurrent inserts and updates to the same key value map (KVM) scoped to the organization or environment level causes inconsistent data and lost updates.

Note: This limitation only applies to Edge for Private Cloud. Edge for Public Cloud and Hybrid do not have this limitation.

For a workaround in Edge for Private Cloud, create the KVM at the apiproxy scope.