Các vấn đề đã biết với Apigee

Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến tài liệu về Apigee X.
thông tin

Các phần sau đây mô tả các vấn đề đã biết với Apigee. Trong hầu hết các trường hợp, các vấn đề được liệt kê sẽ được khắc phục trong một bản phát hành trong tương lai.

Các vấn đề đã biết khác về Edge

Các phần sau đây mô tả các vấn đề đã biết khác nhau với Edge.

Khu vực/Tóm tắt Vấn đề đã biết
Kết quả hết hạn bộ nhớ đệm dẫn đến giá trị cachehit không chính xác

Khi biến flow cachehit được sử dụng sau chính sách LookupCache, do cách các điểm gỡ lỗi được gửi cho hành vi không đồng bộ, LookupPolicy sẽ điền sẵn đối tượng DebugInfo trước khi lệnh gọi lại được thực thi, dẫn đến lỗi.

Giải pháp: Lặp lại quy trình (thực hiện lệnh gọi thứ hai) ngay sau lệnh gọi đầu tiên.

Việc đặt Chính sách InvalidateCache PurgeChildEntries thành true không hoạt động đúng cách

Việc đặt PurgeChildEntries trong chính sách InvalidateCache chỉ nên xoá các giá trị phần tử KeyFragment mà còn xoá toàn bộ bộ nhớ đệm.

Giải pháp: Sử dụng chính sách KeyValueMapOperations để lặp lại việc tạo phiên bản bộ nhớ đệm và bỏ qua việc cần phải vô hiệu hoá bộ nhớ đệm.

Các yêu cầu triển khai đồng thời cho một SharedFlow hoặc proxy API có thể dẫn đến trạng thái không nhất quán trong Máy chủ quản lý, trong đó nhiều bản sửa đổi được hiển thị là đã triển khai.

Điều này có thể xảy ra, ví dụ: khi các lần chạy đồng thời của quy trình triển khai CI/CD xảy ra bằng các bản sửa đổi khác nhau. Để tránh vấn đề này, hãy tránh triển khai proxy API hoặc SharedFlow trước khi quá trình triển khai hiện tại hoàn tất.

Giải pháp: Tránh triển khai proxy API hoặc SharedFlow đồng thời.

Số lệnh gọi API hiển thị trong Phân tích API Edge có thể chứa dữ liệu trùng lặp.

Đôi khi, Edge API Analytics có thể chứa dữ liệu trùng lặp cho các lệnh gọi API. Trong trường hợp đó, số lượng hiển thị cho các lệnh gọi API trong Edge API Analytics sẽ cao hơn các giá trị tương đương hiển thị trong các công cụ phân tích của bên thứ ba.

Giải pháp: Xuất dữ liệu phân tích và sử dụng trường gateway_flow_id để loại bỏ dữ liệu trùng lặp.

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

Các vấn đề đã biết về trang tổng quan tích hợp

Các phần sau đây mô tả các vấn đề đã biết với cổng thông tin tích hợp.

Khu vực Vấn đề đã biết
SmartDocs
  • Apigee Edge hỗ trợ Bản đặc tả OpenAPI 3.0 khi bạn tạo bản đặc tả bằng trình chỉnh sửa bản đặc tảphát hành API bằng SmartDocs trên cổng thông tin, mặc dù một số tính năng chưa được hỗ trợ.

    Ví dụ: các tính năng sau đây trong Quy cách OpenAPI 3.0 chưa được hỗ trợ:

    • Các thuộc tính allOf để kết hợp và mở rộng giản đồ
    • Tham chiếu từ xa

    Nếu một tính năng không được hỗ trợ được tham chiếu trong Quy cách OpenAPI, thì trong một số trường hợp, các công cụ sẽ bỏ qua tính năng đó nhưng vẫn hiển thị tài liệu tham khảo API. Trong các trường hợp khác, một tính năng không được hỗ trợ sẽ gây ra lỗi khiến bạn không thể hiển thị thành công tài liệu tham khảo API. Trong cả hai trường hợp, bạn sẽ cần sửa đổi Thông số kỹ thuật OpenAPI để tránh sử dụng tính năng không được hỗ trợ cho đến khi tính năng đó được hỗ trợ trong bản phát hành trong tương lai.

    Lưu ý: Vì trình chỉnh sửa thông số kỹ thuật ít hạn chế hơn SmartDocs khi hiển thị tài liệu tham khảo API, nên bạn có thể nhận được kết quả khác nhau giữa các công cụ.

  • Khi sử dụng tính năng Thử API này trong cổng thông tin, tiêu đề Accept sẽ được đặt thành application/json bất kể giá trị được đặt cho consumes trong Thông số kỹ thuật OpenAPI.
  • 138438484: Không hỗ trợ nhiều máy chủ.
Nhà cung cấp dịch vụ danh tính SAML Chúng tôi không hỗ trợ tính năng đăng xuất một lần (SLO) bằng nhà cung cấp dịch vụ danh tính SAML cho miền tuỳ chỉnh. Để bật miền tuỳ chỉnh bằng nhà cung cấp danh tính SAML, hãy để trống trường URL đăng xuất khi bạn định cấu hình chế độ cài đặt SAML.
Quản trị viên cổng thông tin
  • Hiện tại, chúng tôi không hỗ trợ việc nhiều người dùng cập nhật cùng lúc trang web (chẳng hạn như chỉnh sửa trang, giao diện, CSS hoặc tập lệnh).
  • Nếu xoá một trang tài liệu tham khảo API khỏi cổng thông tin, bạn sẽ không thể tạo lại trang đó; bạn cần xoá và thêm lại sản phẩm API rồi tạo lại tài liệu tham khảo API.
  • Khi định cấu hình chính sách bảo mật nội dung, có thể mất đến 15 phút để các thay đổi được áp dụng đầy đủ.
  • Khi tuỳ chỉnh giao diện cổng thông tin, có thể mất đến 5 phút để các thay đổi được áp dụng đầy đủ.
Các tính năng của Cổng thông tin
  • Tính năng Tìm kiếm sẽ được tích hợp vào cổng thông tin tích hợp trong một bản phát hành trong tương lai.

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.

Such errors occur because warnings are generated by Cassandra database but the application component cannot handle it. To mitigate, avoid or suppress warnings in your Cassandra nodes. Most of the times, warnings are generated due to excessive tombstones. To address warnings associated with excessive tombstones, you can follow 1 or a combination of options listed below:

  1. Reduce gc_grace_seconds: For the table displayed in the log message message associated with the error, reduce gc_grace_seconds by running the following command like below via 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, follow the instructions below:
    • On a Cassandra node, create or edit file $APIGEE_ROOT/customer/application/cassandra.properties
    • 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
    • Ensure the file above is owned and readable by apigee user: chown apigee:apigee $APIGEE_ROOT/customer/application/cassandra.properties
    • Restart Cassandra application on the node: apigee-service apigee-cassandra restart
    • 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
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.

Such errors occur because warnings are generated by Cassandra database but the application component cannot handle it.To mitigate, avoid or suppress warnings in your Cassandra nodes. Most of the times, warnings are generated due to excessive tombstones. To address warnings associated with excessive tombstones, you can follow 1 or a combination of options listed below:

  1. Reduce gc_grace_seconds: For the table displayed in the log message message associated with the error, reduce gc_grace_seconds by running the following command like below via 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, follow the instructions below:
    • On a Cassandra node, create or edit file $APIGEE_ROOT/customer/application/cassandra.properties
    • 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
    • Ensure the file above is owned and readable by apigee user: chown apigee:apigee $APIGEE_ROOT/customer/application/cassandra.properties
    • Restart Cassandra application on the node: apigee-service apigee-cassandra restart
    • 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.

412696630: Failure to load keystores at startup

The edge-message-processor or edge-router components may intermittently fail to load one or more keystores at startup, resulting in traffic errors when the keystore is utilized by an API proxy or in a virtual host.

To mitigate this, you can do the following:

  1. In a message processor node, add or edit file $APIGEE_ROOT/customer/application/message-processor.properties
  2. Add property conf_deployment_bootstrap.executor.thread.count=1
  3. Save the file and ensure it is readable and owned by apigee user chown apigee:apigee $APIGEE_ROOT/customer/application/message-processor.properties
  4. Restart the message processor service apigee-service edge-message-processor restart
  5. Repeat the above on each message processor node one by one.
  6. In a router node, add or edit file $APIGEE_ROOT/customer/application/router.properties
  7. Add property conf_deployment_bootstrap.executor.thread.count=1
  8. Save the file and ensure it is readable and owned by apigee user chown apigee:apigee $APIGEE_ROOT/customer/application/router.properties.
  9. Restart the router service apigee-service edge-router restart.
  10. Repeat the above on each router node one by one.
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.