בעיות מוכרות ב-Apigee

כשמשתמשים במשתנה התהליך cachehit אחרי המדיניות של LookupCache, בגלל האופן שבו נשלחים נקודות ניפוי באגים להתנהגות אסינכררונית, המדיניות של LookupPolicy מאכלסת את האובייקט DebugInfo לפני שהקריאה החוזרת (call back) מבוצעת, וכתוצאה מכך מתקבלת שגיאה.

פתרון אפשרי: חוזרים על התהליך (מתקשרים בשיחה שנייה) מיד אחרי השיחה הראשונה.

הגדרת PurgeChildEntries במדיניות InvalidateCache אמורה למחוק את ערכי האלמנט KeyFragment בלבד, אבל היא מנקה את כל המטמון.

פתרון עקיף: משתמשים במדיניות KeyValueMapOperations כדי לבצע איטרציה של ניהול גרסאות במטמון ולעקוף את הצורך בביטול התוקף של המטמון.

מצב כזה יכול לקרות, למשל, כשמתבצעות הפעלות בו-זמניות של צינור עיבוד נתונים לפריסה של CI/CD באמצעות גרסאות שונות. כדי למנוע את הבעיה הזו, מומלץ לא לפרוס שרתים proxy של API או תהליכים משותפים לפני שהפריסה הנוכחית תושלם.

פתרון עקיף: הימנעו מפריסות בו-זמניות של proxy ל-API או של SharedFlow.

לפעמים, נתונים כפולים של קריאות ל-API יכולים להופיע ב-Edge API Analytics. במקרה כזה, המספרים שמוצגים לקריאות ל-API ב-Edge API Analytics גבוהים מהערכים המקבילים שמוצגים בכלי ניתוח נתונים של צד שלישי.

פתרון עקיף: מייצאים את נתוני Analytics ומשתמשים בשדה gateway_flow_id כדי לבטל את הכפילויות בנתונים.

• ב-Apigee Edge יש תמיכה במפרט OpenAPI 3.0 כשיוצרים מפרטים באמצעות עורך המפרטים ומפרסמים ממשקי API באמצעות SmartDocs בפורטל, אבל עדיין אין תמיכה בקבוצת משנה של תכונות.

  לדוגמה, התכונות הבאות במפרט OpenAPI 3.0 עדיין לא נתמכות:

  • מאפייני allOf לשילוב ולהרחבה של סכימות
  • הפניות מרחוק

  אם יש הפניה לתכונה שאינה נתמכת במפרט OpenAPI, במקרים מסוימים הכלים יתעלמו מהתכונה אבל עדיין יציגו את תיעוד העזר של ה-API. במקרים אחרים, תכונה שאינה נתמכת תגרום לשגיאות שמונעות את היצירה המוצלחת של מסמכי התיעוד של הפניות ה-API. בכל מקרה, תצטרכו לשנות את מפרט OpenAPI כדי להימנע משימוש בתכונה שלא נתמכת, עד שהיא תהיה נתמכת בגרסה עתידית.

  הערה: מכיוון שעורך המפרט פחות מגביל מ-SmartDocs כשמדובר ברינדור של מסמכי עזרה של ממשקי API, יכול להיות שתקבלו תוצאות שונות בכלי השונים.

• כשמשתמשים ב'ניסיון ב-API הזה' בפורטל, הכותרת Accept מוגדרת כ-application/json ללא קשר לערך שהוגדר ל-consumes במפרט OpenAPI.
• 138438484: אין תמיכה במספר שרתים.

• בשלב זה אין תמיכה בעדכוני פורטל בו-זמניים (כמו עריכת דפים, עיצובים, קובצי CSS או סקריפטים) על ידי כמה משתמשים.
• אם תמחקו דף של מסמכי עזרה של API מהפורטל, לא תוכלו ליצור אותו מחדש. תצטרכו למחוק את מוצר ה-API ולהוסיף אותו מחדש, וליצור מחדש את מסמכי העזרה של ה-API.
• כשמגדירים את מדיניות אבטחת התוכן, יכול להיות שיחלפו עד 15 דקות עד שהשינויים יחולו במלואם.
• כשמתאימים אישית את העיצוב של הפורטל, יכול להיות שיחלפו עד 5 דקות עד שהשינויים יחולו במלואם.

• החיפוש ישולב בפורטל המשולב בגרסה עתידית.

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".

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

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:

• Steps for Edge for Private Cloud versions 4.51.00.11 or newer
• Steps for Edge for Private Cloud versions older than 4.51.00.11

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

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.

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.

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.

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.