Apigee의 알려진 문제

현재 Apigee Edge 문서가 표시되고 있습니다.
Apigee X 문서로 이동
정보

다음 섹션에서는 Apigee의 알려진 문제를 설명합니다. 대부분의 경우 나열된 문제는 향후 출시 버전에서 해결될 예정입니다.

Miscellaneous Edge의 알려진 문제

다음 섹션에서는 Edge의 알려진 기타 문제를 설명합니다.

영역 알려진 문제
캐시 만료로 인해 cachehit 값이 잘못됨

LookupCache 정책 이후에 cachehit 흐름 변수가 사용되면 비동기 동작에 대해 디버그 지점이 전달되는 방식으로 인해 LookupPolicy가 콜백이 실행되기 전에 DebugInfo 객체를 채우므로 오류가 발생합니다.

해결 방법: 첫 번째 호출 직후에 프로세스 (두 번째 호출)를 다시 반복합니다.

InvalidateCache 정책 PurgeChildEntries을 true로 설정하면 올바르게 작동하지 않음

InvalidateCache 정책에서 PurgeChildEntries를 설정하면 KeyFragment 요소 값만 삭제되지만 전체 캐시는 삭제됩니다.

해결 방법: KeyValueMapOperations 정책을 사용하여 캐시 버전 관리를 반복하고 캐시 무효화 필요성을 우회합니다.

Edge UI의 알려진 문제

다음 섹션에서는 Edge UI의 알려진 문제를 설명합니다.

영역 알려진 문제
조직이 ID 영역에 매핑되면 탐색 메뉴에서 Edge SSO 영역 관리 페이지에 액세스할 수 없습니다. 조직을 ID 영역에 연결하면 더 이상 왼쪽 탐색 메뉴에서 Admin > SSO를 선택하여 Edge SSO 영역 관리 페이지에 액세스할 수 없습니다. 이 문제를 해결하려면 다음 URL을 사용하여 페이지로 바로 이동합니다.(https://apigee.com/sso).

통합 포털의 알려진 문제

다음 섹션에서는 통합 포털의 알려진 문제를 설명합니다.

영역 알려진 문제
SmartDocs
  • Apigee Edge는 사양 편집기를 사용하여 사양을 생성하고 포털에서 SmartDocs를 사용하여 API를 게시할 때 OpenAPI 사양 3.0을 지원합니다. 단, 일부 기능은 아직 지원되지 않습니다.

    예를 들어 다음의 OpenAPI 사양 3.0 기능이 아직 지원되지 않습니다.

    • 스키마 결합 및 확장을 위한 allOf 속성
    • 원격 참조

    OpenAPI 사양에서 지원되지 않는 기능을 참조하는 경우, 도구가 기능을 무시하지만 API 참조 문서는 계속 렌더링합니다. 다른 경우에는 지원되지 않는 기능이 API 참조 문서의 성공적인 렌더링을 방지하는 오류를 일으킵니다. 두 경우 모두 지원되지 않는 기능이 향후 출시 버전에서 지원될 때까지 사용되지 않도록 OpenAPI 사양을 수정해야 합니다.

    참고: 사양 편집기는 API 참조 문서를 렌더링할 때 SmartDocs보다 덜 제한적이므로 도구마다 결과가 다를 수 있습니다.

  • 포털에서 이 API 사용해 보기를 사용하는 경우 OpenAPI 사양에서 consumes에 설정된 값에 관계없이 Accept 헤더가 application/json으로 설정됩니다.
SAML ID 공급업체 커스텀 도메인에서는 SAML ID 공급업체를 사용한 단일 로그아웃 (SLO)이 지원되지 않습니다. SAML ID 공급업체로 커스텀 도메인을 사용 설정하려면 SAML 설정을 구성할 때 로그아웃 URL 필드를 비워 둡니다.
포털 관리자
  • 현재 여러 사용자의 동시 포털 업데이트(예: 페이지, 테마, 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
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.