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 cachehit é usada após a política LookupCache, devido à maneira como os pontos de depuração são enviados para comportamento assíncrono, o LookupPolicy preenche o objeto DebugInfo antes que a chamada de retorno seja executada, resultando em um erro.
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 PurgeChildEntries na
política InvalidateCache precisa limpar apenas os valores do elemento KeyFragment, mas
limpa todo o cache.
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.
Por exemplo, os recursos a seguir da especificação OpenAPI 3.0 ainda não são compatíveis:
Propriedades allOf para combinar e estender esquemas
Referências remotas
Se um recurso incompatível for referenciado na especificação OpenAPI, em alguns casos, as ferramentas ignorarão o recurso, mas ainda assim
renderizarão a documentação de referência da API. Em outros casos, um recurso não suportado causará erros que impedem a renderização bem-sucedida
da documentação de referência da API. Em ambos os casos, você precisará modificar a especificação OpenAPI para evitar o uso do recurso não compatível até que ele seja
compatível em uma versão futura.
Observação: como o editor de especificações é menos restritivo que o SmartDocs ao renderizar a documentação de referência da API, você pode encontrar resultados diferentes entre as ferramentas.
Ao usar o Testar esta API no portal, o cabeçalho Accept é definido como application/json, independentemente do valor definido para consumes na especificação OpenAPI.
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
No momento, não há suporte para atualizações de portal simultâneas (como edições de página, tema, CSS ou script) de vários usuários.
Se você excluir uma página de documentação de referência da API do portal, não será possível recriá-la. será necessário excluir e adicionar novamente
o produto da API e gerar a documentação de referência da API novamente.
A pesquisa será integrada ao portal integrado em uma versão futura.
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 está usando o MINT ou o ativou no Edge para instalações de nuvem privada.
Componente afetado:processador de mensagens periféricas
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, os processadores de mensagens vão ter problemas. Haverá um aumento gradual na contagem de linhas de execução abertas, o que vai esgotar os recursos. A exceção a seguir é vista no system.log do processador de mensagens Edge:
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
do protocolo HTTP/2 (CVE-2023-44487), incluindo no Apigee Edge para
de nuvem privada virtual. A vulnerabilidade pode levar a um DoS da funcionalidade de gerenciamento de APIs da Apigee.
Para mais detalhes, consulte o Boletim de segurança da Apigee GCP-2023-032.
Os componentes de roteador e servidor de gerenciamento de borda da nuvem privada ficam expostos ao
na Internet e podem ficar vulneráveis. Embora o HTTP/2 esteja ativado no console
de outros componentes específicos do Edge para nuvem privada, nenhum desses componentes
expostos à Internet. Em componentes não Edge, como Cassandra, Zookeeper e outros,
O HTTP/2 não está ativado. Recomendamos que você faça
etapas a seguir para solucionar a vulnerabilidade do Edge for Private Cloud:
Reinicie o componente do processador de mensagens:
apigee-service edge-postgres-server restart
.
Upgrade do Postgresql ao atualizar para a versão 4.52
O Apigee-postgresql está com problemas para fazer upgrade do Edge para a nuvem privada
da versão 4.50 ou da 4.51 para a 4.52. Os principais problemas
ocorre quando o número de tabelas é maior que 500.
Verifique o número total de tabelas no Postgres executando a consulta SQL abaixo:
apigee-mirror não funciona no Red Hat Enterprise Linux (RHEL) 8.0.
Alternativa:
Como solução alternativa, instale o apigee-mirror em um servidor com uma versão anterior
do RHEL ou de outro
compatível
sistema operacional para Apigee. Você pode então usar o espelho para
adicionar pacotes mesmo se tiver instalado a Apigee em servidores RHEL 8.0.
Política de LDAP
149245401: configurações de pool de conexão LDAP para JNDI definidas por meio do
Recurso LDAP
não são refletidos, e os padrões JNDI sempre causam conexões de uso único.
Como resultado, as conexões estão sendo abertas
e fechadas cada vez para uso único, criando um grande número de
por hora para o servidor LDAP.
Alternativa:
Para mudar as propriedades do pool de conexões LDAP, faça o seguinte:
as etapas a seguir para definir uma alteração global em todas as políticas LDAP.
Crie um arquivo de propriedades de configuração se ele ainda não existir:
Adicione o seguinte ao arquivo (substitua os valores de
Propriedades da Java Naming and Directory Interface (JNDI)
com base no requisito de configuração de recurso LDAP).
Certifique-se de que o arquivo
/opt/apigee/customer/application/message-processor.properties é
de propriedade da apigee:apigee.
Reinicie cada processador de mensagens.
Para verificar se o JNDI do pool de conexões
propriedades estiverem entrando em vigor, será possível
executar um tcpdump para observar o comportamento do pool de conexões LDAP
ao longo do tempo.
Alta latência de 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 acima do normal
Resposta da API
e podem ocorrer de forma aleatória, mesmo com um TPS baixo. Isso pode ocorrer quando mais de 50
servidores 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 para
conexões de saída a servidores de destino. Por padrão, essa configuração é definida como 50, 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 tiver um grande número de servidores de destino que excedam 50 no total, os URLs do servidor de destino
continuam sendo eliminados 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, pesquise o
System.logs do processador de mensagens
para a palavra-chave "onEvict" ou "Remoção". A presença deles nos registros indica que os URLs do servidor de destino
estão sendo removidos do cache HTTPClient porque o tamanho do cache é muito pequeno.
Alternativa:
No Edge para nuvem privada versões 19.01 e 19.06, é possível editar e configurar o HTTPClient
cache, /opt/apigee/customer/application/message-processor.properties:
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 deve ser maior do que
o número de servidores de destino aos quais o processador de mensagens se conecta. Não há lado
efeitos de
definindo essa propriedade como mais alta, e o único efeito seria uma melhoria no processador de mensagens
solicitações por proxy.
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
no nível da organização ou do ambiente causa dados inconsistentes e atualizações perdidas.
Observação:essa limitação se aplica apenas ao Edge para nuvem privada. Edge para nuvem pública
e o modelo híbrido não têm essa limitação.
Para uma solução alternativa no Edge para nuvem privada, crie a KVM no
Escopo apiproxy.