Problemas conocidos con Apigee

Estás viendo la documentación de Apigee Edge.
Ve a la documentación de Apigee X.
Información

En las siguientes secciones, se describen los problemas conocidos de Apigee. En la mayoría de los casos, los problemas mencionados se solucionarán en una versión futura.

Otros problemas conocidos de Edge

En las siguientes secciones, se describen varios problemas conocidos con Edge.

Área Errores conocidos
El vencimiento de la caché genera un valor de cachehit incorrecto

Cuando la variable de flujo cachehit se usa después de la política LookupCache, debido a la forma en que se despachan los puntos de depuración para comportamiento asíncrono, LookupPolicy propaga el objeto DebugInfo antes de que se ejecute la devolución de llamada, lo que genera un error.

Solución alternativa: Repite el proceso (haz una segunda llamada) justo después de la primera llamada.

No funciona correctamente la configuración de la política InvalidateCache PurgeChildEntries como verdadera.

Si configuras PurgeChildEntries en la política InvalidateCache, solo se deberían borrar definitivamente los valores del elemento KeyFragment, pero se borra toda la caché.

Solución alternativa: Usa la política de KeyValueMapOperations para iterar el control de versiones de la caché y evitar la necesidad de invalidar la caché.

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

Problemas conocidos con el portal integrado

En las siguientes secciones, se describen los problemas conocidos con el portal integrado.

Área Errores conocidos
SmartDocs
  • Apigee Edge admite la especificación 3.0 de OpenAPI cuando creas especificaciones con el editor de especificaciones y publicas APIs con SmartDocs en tu portal, aunque aún no se admite un subconjunto de funciones.

    Por ejemplo, aún no se admiten las siguientes características de OpenAPI Specification 3.0:

    • Propiedades allOf para combinar y extender esquemas
    • Referencias remotas

    Si se hace referencia a una función no compatible en tu especificación de OpenAPI, en algunos casos, las herramientas la ignorarán, pero aun así renderizarán la documentación de referencia de la API. En otros casos, una función no compatible generará errores que impedirán el procesamiento correcto de la documentación de referencia de la API. En cualquier caso, deberás modificar tu especificación de OpenAPI para evitar el uso de la característica no compatible hasta que sea compatible con una versión futura.

    Nota: Debido a que el editor de especificaciones es menos restrictivo que SmartDocs cuando se procesa la documentación de referencia de la API, es posible que experimentes resultados diferentes entre las herramientas.

  • Cuando se usa Probar esta API en el portal, el encabezado Accept se configura como application/json, sin importar el valor establecido para consumes en la OpenAPI Specification.
Proveedor de identidad de SAML El cierre de sesión único (SLO) con el proveedor de identidad SAML no es compatible con los dominios personalizados. Para habilitar un dominio personalizado con un proveedor de identidad de SAML, deja el campo URL de cierre de sesión en blanco cuando establezcas la configuración de SAML.
Administrador del portal
  • En este momento, no se admiten las actualizaciones simultáneas del portal (como ediciones a las páginas, el tema, CSS o las secuencias de comandos).
  • Si borras una página de documentación de referencia de la API del portal, no hay forma de volver a crearla; deberás borrar y volver a agregar el producto de API, y volver a generar la documentación de referencia de la API.
  • Cuando configures la política de seguridad del contenido, es posible que los cambios tarden hasta 15 minutos en aplicarse por completo.
  • Cuando personalizas el tema de tu portal, los cambios pueden tardar hasta 5 minutos en aplicarse por completo.
Funciones del portal
  • La Búsqueda se integrará en el portal integrado en una versión futura.

Known issues with Edge for Private Cloud

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

Area Known issues
4.53.00 SSO and new UI installation

This issue affects users attempting to install SSO or the new UI on FIPS-enabled RHEL 8 on Edge for Private Cloud 4.53.00.

Component affected: SSO and new UI

Issue: If you are installing SSO or the new UI on FIPS-enabled RHEL 8 operating system, the installation fails.

Workaround: You are encouraged to use the Classic UI, which is feature-complete and meets the UI functionality needs.

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.

apigee-mirror on RHEL 8.0

apigee-mirror does not work on Red Hat Enterprise Linux (RHEL) 8.0.

Workaround: As a workaround, install apigee-mirror on a server running a lower version of RHEL or another supported operating system for Apigee. You can then use the mirror to add packages even if you installed Apigee on RHEL 8.0 servers.

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.