Stai visualizzando la documentazione di Apigee Edge.
Consulta la
documentazione di Apigee X. informazioni
Le seguenti sezioni descrivono i problemi noti di Apigee. Nella maggior parte dei casi, i problemi elencati verranno risolti in una release futura.
Problemi noti di vari Edge
Le seguenti sezioni descrivono vari problemi noti relativi a Edge.
Area | Problemi noti |
---|---|
La scadenza della cache restituisce un valore cachehit errato |
Quando la variabile di flusso Soluzione: ripeti la procedura (effettua una seconda chiamata) di nuovo subito dopo la prima. |
L'impostazione del criterio InvalidateCache
PurgeChildEntries su true non funziona correttamente |
L'impostazione di Soluzione:utilizza il criterio KeyValueMapOperations per iterare il controllo delle versioni della cache e ignorare la convalida della cache. |
Problemi noti relativi all'interfaccia utente Edge
Le seguenti sezioni descrivono i problemi noti dell'interfaccia utente Edge.
Area | Problemi noti |
---|---|
Impossibile accedere alla pagina di amministrazione della zona SSO perimetrale dalla barra di navigazione dopo che l'organizzazione è stata mappata a una zona di identità | Quando connetti un'organizzazione a una zona di identità, non puoi più accedere alla pagina di amministrazione delle zone SSO Edge dalla barra di navigazione a sinistra selezionando Amministratore > SSO. Per risolvere il problema, vai alla pagina direttamente utilizzando il seguente URL: https://apigee.com/sso |
Problemi noti relativi al portale integrato
Le seguenti sezioni descrivono i problemi noti relativi al portale integrato.
Area | Problemi noti |
---|---|
SmartDocs |
|
Provider di identità SAML | L'uscita singola (SLO) con il provider di identità SAML non è supportata per i domini personalizzati. Per attivare un dominio personalizzato con un provider di identità SAML, lascia vuoto il campo Sign-out URL (URL di disconnessione) quando configuri le impostazioni SAML. |
Amministratore portale |
|
Funzionalità del portale |
|
Problemi noti relativi a Edge per cloud privato
Le seguenti sezioni descrivono i problemi noti relativi a Edge per Cloud privato.
Area | Problemi noti |
---|---|
Aggiornamento menta OPDK 4.52.01 |
Questo problema riguarda solo coloro che utilizzano MINT o hanno MINT abilitato in Edge per le installazioni di cloud privato. Componente interessato: edge-message-processor Problema: se hai abilitato la monetizzazione e stai installando la versione 4.52.01 come nuova installazione o eseguendo l'upgrade dalle versioni precedenti di Private Cloud, potresti riscontrare un problema con i processori di messaggi. Ci sarà un aumento graduale del numero di thread aperti, con l'esaurimento delle risorse. La seguente eccezione è presente in edge-message-processor system.log: Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread |
Vulnerabilità HTTP/2 Apigee | Di recente, è stata scoperta una vulnerabilità denial of service (DoS) in più implementazioni del protocollo HTTP/2 (CVE-2023-44487), tra cui Apigee Edge per il cloud privato. La vulnerabilità potrebbe portare a un DoS della funzionalità di gestione delle API Apigee. Per ulteriori dettagli, consulta il Bollettino sulla sicurezza Apigee GCP-2023-032. I componenti del router e del server di gestione di Edge per Cloud privato sono esposti a internet e possono essere potenzialmente vulnerabili. Anche se HTTP/2 è abilitato sulla porta di gestione di altri componenti specifici di Edge per il cloud privato, nessuno di questi componenti è esposto a internet. Sui componenti non Edge, come Cassandra, Zookeeper e altri, HTTP/2 non è abilitato. Ti consigliamo di seguire questi passaggi per risolvere la vulnerabilità Edge per cloud privato:
Segui questi passaggi se utilizzi Edge Private Cloud 4.51.00.11 o versioni successive:
Segui questi passaggi se utilizzi versioni di Edge per Cloud privato precedenti alla 4.51.00.11:
|
Upgrade di Postgresql alla versione 4.52 | Apigee-postgresql riscontra problemi con l'upgrade da Edge per Cloud privato versione 4.50 o 4.51 alla versione 4.52. I problemi si verificano principalmente quando il numero di tabelle è maggiore di 500. Puoi controllare il numero totale di tabelle in Postgres eseguendo la query SQL di seguito: select count(*) from information_schema.tables Soluzione:quando aggiorni Apigee Edge 4.50.00 o la versione 4.51.00 alla versione 4.52.00, assicurati di eseguire il passaggio preliminare prima di eseguire l'upgrade di Apigee-postgresql. |
apigee-mirror su RHEL 8.0 |
Soluzione:
come soluzione alternativa, installa |
Criterio LDAP | 149245401: le impostazioni del pool di connessioni LDAP per JNDI configurato tramite la risorsa LDAP non vengono applicate e i valori predefiniti di JNDI causano ogni volta connessioni a uso singolo. Di conseguenza, le connessioni vengono aperte e chiuse ogni volta per uso singolo, creando un numero elevato di connessioni all'ora al server LDAP. Soluzione alternativa: Per modificare le proprietà del pool di connessioni LDAP, segui questi passaggi per impostare una modifica globale di tutti i criteri LDAP.
Per verificare che le proprietà JNDI del pool di connessioni vengano applicate, puoi eseguire un tcpdump per osservare il comportamento del pool di connessioni LDAP nel tempo. |
Latenza elevata di elaborazione delle richieste | 139051927: le latenze elevate di elaborazione proxy rilevate nel processore di messaggi interessano tutti i proxy API. I sintomi includono ritardi di 200-300 ms nei tempi di elaborazione rispetto ai normali tempi di risposta dell'API e possono verificarsi in modo casuale anche con TPS bassi. Questo può verificarsi quando più di 50 server di destinazione in cui un processore di messaggi stabilisce connessioni. Causa principale: i processori dei messaggi conservano una cache che mappa l'URL del server di destinazione all'oggetto HTTPClient per le connessioni in uscita ai server di destinazione. Per impostazione predefinita, il valore è 50, che potrebbe essere troppo basso per la maggior parte dei deployment. Quando un deployment ha più combinazioni organizzazione/ambiente in una configurazione e ha un numero elevato di server di destinazione che supera in totale i 50, gli URL dei server di destinazione continuano a essere rimossi dalla cache, causando latenze. Convalida: per determinare se l'eliminazione dell'URL del server di destinazione causa il problema di latenza, cerca la parola chiave "onEvict" o "Eviction" nel sistema di elaborazione dei messaggi system.logs. La loro presenza nei log indica che gli URL dei server di destinazione vengono rimossi dalla cache HTTPClient perché le dimensioni della cache sono troppo ridotte. Soluzione:per Edge per Cloud privato versioni 19.01 e 19.06, puoi modificare e configurare la cache HTTPClient, conf/http.properties+HTTPClient.dynamic.cache.elements.size=500 Quindi riavvia il processore dei messaggi. Apporta le stesse modifiche a tutti i processori di messaggi. Il valore 500 è un esempio. Il valore ottimale per la configurazione deve essere maggiore del numero di server di destinazione a cui si connette il processore di messaggi. L'impostazione di questa proprietà su un valore più elevato non ha effetti collaterali e l'unico effetto è un miglioramento dei tempi di elaborazione delle richieste proxy dell'elaboratore dei messaggi.
Nota:l'impostazione predefinita di Edge per cloud privato 50.00 è 500. |
Più voci per le mappe chiave-valore | 157933959: l'inserimento e gli aggiornamenti simultanei della stessa mappa chiave-valore (KVM) con ambito a livello di organizzazione o di ambiente causano dati incoerenti e perdite di aggiornamenti. Nota:questo limite si applica solo a Edge per cloud privato. Edge per cloud pubblico e ibrido non presentano questa limitazione. Per una soluzione alternativa in Edge per cloud privato, crea il KVM nell'ambito |