Você está vendo a documentação do Apigee Edge.
Acesse a
documentação da Apigee X. informações
As seções a seguir descrevem os problemas conhecidos da Apigee. Na maioria dos casos, os problemas listados serão corrigidos em uma versão futura.
Problemas conhecidos do Edge
Confira nas seções a seguir alguns problemas conhecidos do Edge.
Área | Problemas conhecidos |
---|---|
A expiração do cache resulta em um valor cachehit incorreto |
Quando a variável de fluxo Alternativa:repita o processo (faça a segunda chamada) novamente logo após a primeira chamada. |
A configuração da política InvalidateCache
PurgeChildEntries como verdadeira não funciona corretamente |
A definição de Solução alternativa: use a política KeyValueMapOperations para iterar o controle de versões de cache e ignorar a necessidade de invalidação de cache. |
Problemas conhecidos com a IU do Edge
As seções a seguir descrevem os problemas conhecidos com a IU do Edge.
Área | Problemas conhecidos |
---|---|
Não é possível acessar a página de administração da zona de SSO do Edge na barra de navegação após a organização ser mapeada para uma zona de identidade | Quando você conectar uma organização a uma zona de identidade, não poderá mais acessar a página de administração da zona SSO do Edge na barra de navegação à esquerda selecionando Administrador > SSO. Como solução alternativa, acesse a página diretamente usando o seguinte URL: https://apigee.com/sso (em inglês) |
Problemas conhecidos com o portal integrado
As seções a seguir descrevem os problemas conhecidos do portal integrado.
Área | Problemas conhecidos |
---|---|
SmartDocs |
|
Provedor de identidade SAML | O logout único (SLO) com o provedor de identidade SAML não é compatível com domínios personalizados. Para ativar um domínio personalizado com um provedor de identidade SAML, deixe o campo URL de saída em branco ao definir as configurações de SAML. |
Administrador do portal |
|
Recursos do portal |
|
Problemas conhecidos com o Edge para nuvem privada
As seções a seguir descrevem os problemas conhecidos do Edge para nuvem privada.
Área | Problemas conhecidos |
---|---|
Atualização do OPDK 4.52.01 Mint |
Esse problema afeta apenas quem usa o MINT ou o que tem o MINT ativado no Edge para instalações de nuvem privada. Componente afetado:processador de mensagens de borda Problema: se a monetização estiver ativada e você estiver instalando a versão 4.52.01 como uma nova instalação ou fazendo upgrade de versões anteriores da nuvem privada, haverá um problema com os processadores de mensagens. Há um aumento gradual na contagem de linhas de execução abertas, o que leva ao esgotamento dos recursos. A seguinte exceção é encontrada no system.log do processador de mensagens de borda: Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread |
Vulnerabilidade HTTP/2 da Apigee | Uma vulnerabilidade de negação de serviço (DoS) foi descoberta recentemente em várias implementações do protocolo HTTP/2 (CVE-2023-44487), inclusive no Apigee Edge para nuvem privada. A vulnerabilidade pode levar a um ataque de negação de serviço (DoS) da funcionalidade de gerenciamento da API da Apigee. Para mais detalhes, consulte o Boletim de segurança da Apigee GCP-2023-032. Os componentes do roteador e do servidor de gerenciamento do Edge para nuvem privada estão expostos à Internet e podem ficar vulneráveis. Embora o HTTP/2 esteja ativado na porta de gerenciamento de outros componentes específicos do Edge para nuvem privada, nenhum desses componentes está exposto à Internet. Em componentes que não são do Edge, como o Cassandra, o Zookeeper e outros, o HTTP/2 não está ativado. Recomendamos que você siga as etapas a seguir para solucionar a vulnerabilidade do Edge para nuvem privada:
Siga estas etapas se você estiver usando a nuvem privada do Edge 4.51.00.11 ou mais recente:
Siga estas etapas se você estiver usando o Edge para versões de nuvem privada anteriores à 4.51.00.11:
|
Atualização do Postgresql ao atualizar para a versão 4.52 | O Apigee-postgresql está tendo problemas com o upgrade do Edge para nuvem privada versão 4.50 ou 4.51 para a versão 4.52. Os problemas ocorrem principalmente quando o número de tabelas é maior que 500. Para verificar o número total de tabelas no Postgres, execute a consulta SQL abaixo: select count(*) from information_schema.tables Solução alternativa: ao atualizar o Apigee Edge 4.50.00 ou 4.51.00 para 4.52.00, realize a etapa preliminar antes de fazer upgrade do Apigee-postgresql. |
apigee-mirror no RHEL 8.0 |
Solução alternativa: como solução alternativa, instale |
Política LDAP | 149245401: as configurações do pool de conexões LDAP para JNDI definidas pelo recurso LDAP não são refletidas, e os padrões JNDI causam conexões de uso único todas as vezes. Como resultado, as conexões estão sendo abertas e fechadas sempre para uso único, criando um grande número de conexões por hora com o servidor LDAP. Alternativa: Para alterar as propriedades do pool de conexão LDAP, siga as etapas abaixo para definir uma alteração global em todas as políticas LDAP.
Para verificar se as propriedades JNDI do pool de conexões estão funcionando, execute um tcpdump para observar o comportamento do pool de conexões LDAP ao longo do tempo. |
Latência alta do processamento de solicitações | 139051927: altas latências de processamento de proxy encontradas no processador de mensagens estão afetando todos os proxies de API. Os sintomas incluem atrasos de 200 a 300 ms nos tempos de processamento em relação aos tempos de resposta normais da API e podem ocorrer de forma aleatória, mesmo com TPS baixo. Isso pode ocorrer quando há mais de 50 servidores de destino em que um processador de mensagens faz conexões. Causa raiz:os processadores de mensagens mantêm um cache que mapeia o URL do servidor de destino para o objeto HTTPClient das conexões de saída com os servidores de destino. Por padrão, essa configuração é definida como 50, o que pode ser muito baixo para a maioria das implantações. Quando uma implantação tem várias combinações de organização/ambiente em uma configuração e tem um grande número de servidores de destino que excedem 50 no total, os URLs do servidor de destino continuam sendo removidos do cache, causando latências. Validação: para determinar se a remoção do URL do servidor de destino está causando o problema de latência, procure a palavra-chave "onEvict" ou "Remoção" no system.logs do processador de mensagens. A presença deles nos registros indica que os URLs do servidor de destino estão sendo removidos do cache do HTTPClient porque o tamanho do cache é muito pequeno. Solução alternativa:
para o Edge para as versões 19.01 e 19.06, é possível editar e configurar o cache
do HTTPClient, conf/http.properties+HTTPClient.dynamic.cache.elements.size=500 Em seguida, reinicie o processador de mensagens. Faça as mesmas mudanças para todos os processadores de mensagens. O valor 500 é um exemplo. O valor ideal para sua configuração precisa ser maior que o número de servidores de destino aos quais o processador de mensagens se conectaria. Não há efeitos colaterais de definir essa propriedade mais alta, e o único efeito seria um tempo de processamento de solicitação de proxy do processador de mensagens melhorado.
Observação:o Edge para nuvem privada versão 50.00 tem a configuração padrão de 500. |
Várias entradas para mapas de chave-valor | 157933959: inserções e atualizações simultâneas no mesmo mapa de chave-valor (KVM) com escopo para o nível da organização ou do ambiente causam dados inconsistentes e perda de atualizações. Observação:essa limitação se aplica apenas ao Edge para nuvem privada. O Edge para nuvem pública e híbrida não tem essa limitação. Para uma solução alternativa no Edge para nuvem privada, crie a KVM no
escopo |