Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントをご覧ください。
以下のセクションでは、Apigee Edge の既知の問題について説明します。ほとんどの場合、ここに記載されている問題は今後のリリースで修正される予定です。
その他の Edge の既知の問題
以下のセクションでは、Edge に関するその他の既知の問題について説明します。
領域 | 既知の問題 |
---|---|
キャッシュの有効期限によって cachehit の値が間違っている |
回避策: 最初の呼び出しの直後に、プロセスをもう一度繰り返します(2 回目の呼び出しを行います)。 |
InvalidateCache ポリシー PurgeChildEntries を true に設定しても、正しく機能しない |
InvalidateCache ポリシーで 回避策: KeyValueMapOperations ポリシーを使用してキャッシュ バージョニングを繰り返し、キャッシュ無効化の必要性を回避します。 |
Edge UI に関する既知の問題
以降のセクションでは、Edge UI の既知の問題について説明します。
地域 | 既知の問題 |
---|---|
組織が ID ゾーンにマッピングされていると、ナビゲーション バーから [Edge SSO Zone Administration] ページにアクセスできなくなります。 | 組織を ID ゾーンに接続すると、左側のナビゲーション バーから [Admin] > [SSO] を選択しても、Edge SSO Zone 管理ページにアクセスできなくなります。回避策として、https://apigee.com/sso からページに直接移動します。 |
統合ポータルに関する既知の問題
以下のセクションでは、統合ポータルの既知の問題について説明します。
地域 | 既知の問題 |
---|---|
SmartDocs |
|
SAML ID プロバイダ | SAML ID プロバイダでのシングル ログアウト(SLO)は、カスタム ドメインではサポートされていません。SAML ID プロバイダでカスタム ドメインを有効にするには、SAML 設定を構成するときに [Sign-out URL] フィールドを空白のままにします。 |
ポータル管理者 |
|
ポータルの機能 |
|
Edge for Private Cloud に関する既知の問題
次のセクションでは、Edge for Private Cloud の既知の問題について説明します。
地域 | 既知の問題 |
---|---|
バージョン 4.52 への更新時の Postgresql アップグレード | Apigee-postgresql で、Edge for Private Cloud バージョン 4.50 または 4.51 からバージョン 4.52 へのアップグレードで問題が発生しています。この問題は、主にテーブル数が 500 を超える場合に発生します。 Postgres のテーブルの総数を確認するには、以下の SQL クエリを実行します。 select count(*) from information_schema.tables 回避策: Apigee Edge 4.50.00 または 4.51.00 を 4.52.00 にアップデートする場合は、Apigee-postgresql をアップグレードする前に 予備手順を実施してください。 |
apigee-mirror (RHEL 8.0) |
回避策: 回避策として、以前のバージョンの RHEL、または Apigee でサポートされている別のオペレーティング システムを実行しているサーバーに |
LDAP ポリシー | 149245401: LDAP リソースを介して構成された JNDI の LDAP 接続プール設定が反映されず、JNDI のデフォルトにより毎回 1 回限りの接続が発生します。その結果、接続の開閉は 1 回使用されるたびに行われ、LDAP サーバーに 1 時間あたりに大量の接続が作成されます。 回避策: LDAP 接続プールのプロパティを変更するには、次の手順を行い、すべての LDAP ポリシーでグローバルな変更を設定します。
接続プールの JNDI プロパティが有効かどうかを確認するには、tcpdump を実行して LDAP 接続プールの動作を時系列でモニタリングします。 |
高リクエスト処理レイテンシ | 139051927: Message Processor で検出されたプロキシ処理の高レイテンシが、すべての API プロキシに影響を及ぼしています。症状には、通常の API 応答時間と比較して処理時間が 200 ~ 300 ms 遅延する傾向があり、TPS が低い場合でもランダムに発生する可能性があります。これは、Message Processor が接続するターゲット サーバーが 50 を超える場合に発生します。 根本原因: Message Processor が保持しているキャッシュは、ターゲット サーバーへの送信接続用のターゲット サーバーの URL を HTTPClient オブジェクトにマッピングするものです。この設定はデフォルトで 50 に設定されており、ほとんどのデプロイでは低すぎる可能性があります。デプロイに組織と環境の組み合わせが複数あり、ターゲット サーバーの数が非常に多い場合、ターゲット サーバーの URL がキャッシュから削除され、レイテンシが発生します。 検証: ターゲット サーバーの URL の削除がレイテンシの問題の原因であるかどうかを確認するには、Message Processor system.logs でキーワード「onEvict」または「Eviction」を検索します。このログは、キャッシュ サイズが小さすぎるためにターゲット サーバーの URL が HTTPClient キャッシュから削除されることを示しています。 回避策: Edge for Private Cloud バージョン 19.01 と 19.06 では、HTTPClient キャッシュ conf/http.properties+HTTPClient.dynamic.cache.elements.size=500 Message Processor を再起動します。すべての Message Processor で同じ変更を行います。 値 500 は一例です。設定に最適な値は、Message Processor が接続するターゲット サーバーの数よりも大きくする必要があります。このプロパティを高く設定しても副作用はありません。唯一の影響は、Message Processor のリクエスト処理時間の改善です。
注: Edge for Private Cloud バージョン 50.00 のデフォルト設定は 500 です。 |
Key-Value マップの複数のエントリ | 157933959: 組織レベルまたは環境レベルをスコープとする同じ Key-Value マップ(KVM)への挿入と更新が同時に行われると、データに不整合と更新が失われます。 注: この制限は、Edge for Private Cloud にのみ適用されます。Edge for Public Cloud とハイブリッドにはこの制限がありません。 Edge for Private Cloud の回避策として、 |