Известные проблемы с Apigee

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee
X.info

В следующих разделах описаны известные проблемы Apigee Edge и Edge for Private Cloud. В большинстве случаев перечисленные проблемы будут исправлены в будущих версиях.

Разное Известные проблемы Edge

В следующих разделах описаны различные известные проблемы с Edge.

Район/Сводка Известные проблемы
Срок действия кэша приводит к неправильному значению cachehit

Когда переменная потока cachehit используется после политики LookupCache, из-за способа отправки точек отладки для асинхронного поведения LookupPolicy заполняет объект DebugInfo до выполнения обратного вызова, что приводит к ошибке.

Обходной путь: повторите процесс (сделайте второй звонок) еще раз сразу после первого звонка.

Установка для политики InvalidateCache PurgeChildEntries значения true работает неправильно.

Установка PurgeChildEntries в политике InvalidateCache должна очищать только значения элемента KeyFragment , но очищает весь кеш.

Обходной путь: используйте политику KeyValueMapOperations , чтобы итерировать управление версиями кэша и обойти необходимость аннулирования кэша.

Одновременные запросы на развертывание прокси-сервера SharedFlow или API могут привести к несогласованному состоянию на сервере управления, где несколько версий отображаются как развернутые.

Это может произойти, например, когда одновременно выполняются конвейеры развертывания CI/CD с использованием разных версий. Чтобы избежать этой проблемы, избегайте развертывания прокси-серверов API или SharedFlows до завершения текущего развертывания.

Обходной путь: избегайте одновременного развертывания прокси-сервера API или SharedFlow.

Количество вызовов API, отображаемое в Edge API Analytics, может содержать повторяющиеся данные.

Edge API Analytics иногда может содержать повторяющиеся данные для вызовов API. В этом случае количество вызовов API, отображаемое в Edge API Analytics, выше, чем сопоставимые значения, отображаемые в сторонних аналитических инструментах.

Обходной путь: экспортируйте аналитические данные и используйте поле шлюза_flow_id для дедупликации данных.

Известные проблемы с пользовательским интерфейсом Edge

В следующих разделах описаны известные проблемы пользовательского интерфейса Edge.

Область/Краткое описание Известные проблемы
Не удается получить доступ к странице администрирования зоны Edge SSO из панели навигации после сопоставления организации с зоной идентификации.

После подключения организации к зоне идентификации доступ к странице администрирования зоны Edge SSO через левую панель навигации (выбор пункта «Администрирование» > «SSO») становится невозможен.

Временное решение: перейдите на страницу напрямую, используя следующий URL: https://apigee.com/sso

Настройка TLS в пользовательском интерфейсе Edge

Параметры TLS_DISABLED_ALGO и TLS_ENABLED_CIPHERS работают некорректно.

Временное решение: выполните следующие действия, чтобы включить определенные алгоритмы шифрования для пользовательского интерфейса Edge:

  1. Откройте конфигурационный файл /opt/apigee/etc/edge-ui.d/SSL.sh .
  2. Добавьте свойство -Djdk.tls.server.cipherSuites с разделенным запятыми списком наборов шифров в нотации IANA в поле UI_OPTIONS . Например:
    UI_OPTIONS=" -Dhttp.port=disabled -Dhttps.port=9433 -Dhttps.keyStoreType=JKS -Dhttps.keyStore=/opt/apigee/customer/conf/keystore.jks -Dplay.http.sslengineprovider=services.CustomSSLEngineProvider -Dhttps.keyStorePasswordEncrypted=mypass -Djdk.tls.server.cipherSuites=TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384"
  3. Сохраните изменения в конфигурационном файле.
  4. Перезапустите пользовательский интерфейс Edge:
    /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

Известные проблемы с интегрированным порталом

В следующих разделах описаны известные проблемы интегрированного портала.

Область Известные проблемы
СмартДокс
  • Apigee Edge поддерживает спецификацию OpenAPI 3.0, когда вы создаете спецификации с помощью редактора спецификаций и публикуете API с помощью SmartDocs на своем портале, хотя подмножество функций еще не поддерживается.

    Например, следующие функции спецификации OpenAPI 3.0 пока не поддерживаются:

    • allOf свойства для объединения и расширения схем
    • Удаленные ссылки

    Если в вашей спецификации OpenAPI указана неподдерживаемая функция, в некоторых случаях инструменты проигнорируют эту функцию, но все равно отобразят справочную документацию API. В других случаях неподдерживаемая функция приведет к ошибкам, препятствующим успешному отображению справочной документации API. В любом случае вам потребуется изменить спецификацию OpenAPI, чтобы избежать использования неподдерживаемой функции до тех пор, пока она не будет поддерживаться в будущем выпуске.

    Примечание . Поскольку редактор спецификаций менее строгий, чем SmartDocs, при отображении справочной документации API, вы можете получить разные результаты при использовании разных инструментов.

  • При использовании «Попробуйте этот API» на портале для заголовка Accept устанавливается значение application/json независимо от значения, установленного для consumes в спецификации OpenAPI.
  • 138438484: несколько серверов не поддерживаются.
Поставщик удостоверений SAML Единый выход из системы (SLO) с помощью поставщика удостоверений SAML не поддерживается для личных доменов. Чтобы включить личный домен с поставщиком удостоверений SAML, оставьте поле URL-адрес выхода пустым при настройке параметров SAML .
Администратор портала
  • Одновременное обновление портала (например, редактирование страниц, тем, CSS или сценариев) несколькими пользователями в настоящее время не поддерживается.
  • Если вы удалите страницу справочной документации API с портала, восстановить ее будет невозможно; вам потребуется удалить и повторно добавить продукт API, а также заново создать справочную документацию по API.
  • При настройке политики безопасности контента для полного применения изменений может потребоваться до 15 минут.
  • При настройке темы портала для полного применения изменений может потребоваться до 5 минут.
Возможности портала
  • Поиск будет интегрирован в интегрированный портал в будущей версии.

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.01 NGINX Vulnerability Assessment (CVE-2026-42945)

A vulnerability (CVE-2026-42945) was disclosed affecting the ngx_http_rewrite_module in NGINX. Security scanning tools may flag the NGINX binaries included with Apigee Edge for Private Cloud because this module is statically compiled into NGINX.

Impact on Apigee Edge for Private Cloud:

Apigee Edge for Private Cloud is not affected by this vulnerability in its default, shipped configuration. The exploitability of CVE-2026-42945 is dependent on specific NGINX configuration patterns, notably the use of the rewrite directive in a particular sequence. These patterns are not present in any standard Apigee Edge for Private Cloud NGINX configurations.

Action Required:

  • For Default Apigee Edge for Private Cloud Configurations: No patches, upgrades, or operational changes are required. Scanner findings regarding CVE-2026-42945 can be treated as false positives for default installations. You can use the following text to document this exception in your vulnerability management system:

    CVE-2026-42945 — Accepted exception (false positive for Apigee Edge for Private Cloud). Apigee Edge for Private Cloud does not use the rewrite directive in any shipped NGINX configuration. The vulnerable code path in ngx_http_rewrite_module is configuration-gated and is not reachable in the default Apigee Edge for Private Cloud deployment.

  • For Customized NGINX Configurations: If you have manually modified the NGINX configuration files within your Apigee Edge for Private Cloud installation (for example, under /opt/nginx), you should perform the following self-check to ensure your customizations have not inadvertently introduced the vulnerable pattern:
    1. Check for rewrite directive: On each NGINX node, run the command:
      sudo grep -rnI '^\s*rewrite\b' /opt/nginx
    2. Analyze Results:
      • If the command returns no output, your system is not affected.
      • If matches are found, review each instance. The vulnerability is present only if all the following conditions are met for a given block:
        • The rewrite directive is used.
        • It is immediately followed by another rewrite, if, or set directive within the same configuration block.
        • An unnamed PCRE capture group (for example, $1, $2, etc.) is used in the directives.
        • The replacement string in the directive contains a question mark (?).
    3. Mitigation (if vulnerable): If all the above conditions are true for any part of your custom configuration, mitigate by:
      • Removing the question mark (?) from the replacement string.
      • Using named PCRE capture groups instead of unnamed ones.
      • Re-evaluating the need for the chained directives.
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 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.