Problemas conhecidos com a Apigee

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

Área Problemas conhecidos
SmartDocs
  • O Apigee Edge oferece suporte à especificação OpenAPI 3.0 quando você cria especificações usando o editor de especificações e publica APIs usando SmartDocs no portal, embora ainda não haja suporte a um subconjunto de recursos.

    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.
  • Ao configurar a Política de Segurança de Conteúdo, as alterações podem levar até 15 minutos para serem totalmente aplicadas.
  • Ao personalizar seu tema do portal, pode levar até cinco minutos para que as alterações sejam aplicadas.
Recursos do portal
  • 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:

Siga estas etapas se você estiver usando a nuvem privada do Edge na versão 4.51.00.11 ou mais recente:

  1. Atualize o servidor de gerenciamento:

    1. Em cada nó do servidor de gerenciamento, abra /opt/apigee/customer/application/management-server.properties.
    2. Adicione esta linha ao arquivo de propriedades:
      conf_webserver_http2.enabled=false
    3. Reinicie o componente do servidor de gerenciamento:
      apigee-service edge-management-server restart
  2. Atualize o processador de mensagens:

    1. Em cada nó do processador de mensagens, abra /opt/apigee/customer/application/message-processor.properties.
    2. Adicione esta linha ao arquivo de propriedades:
      conf_webserver_http2.enabled=false
    3. Reinicie o componente do processador de mensagens:
      apigee-service edge-message-processor restart
  3. Atualize o roteador:

    1. Em cada nó do roteador, abra /opt/apigee/customer/application/router.properties
    2. Adicione esta linha ao arquivo de propriedades:
      conf_webserver_http2.enabled=false
    3. Reinicie o componente do processador de mensagens:
      apigee-service edge-router restart
  4. Atualize o QPID:

    1. Em cada nó QPID, abra /opt/apigee/customer/application/qpid-server.properties
    2. Adicione esta linha ao arquivo de propriedades:
      conf_webserver_http2.enabled=false
    3. Reinicie o componente do processador de mensagens:
      apigee-service edge-qpid-server restart
  5. Atualize o Postgres:

    1. Em cada nó do Postgres, abra /opt/apigee/customer/application/postgres-server.properties.
    2. Adicione esta linha ao arquivo de propriedades:
      conf_webserver_http2.enabled=false
    3. Reinicie o componente do processador de mensagens:
      apigee-service edge-postgres-server restart

Siga estas etapas se você estiver usando o Edge para versões da nuvem privada anteriores à 4.51.00.11:

  1. Atualize o servidor de gerenciamento:

    1. Em cada nó do servidor de gerenciamento, abra /opt/apigee/customer/application/management-server.properties.
    2. Adicione estas duas linhas ao arquivo de propriedades:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Reinicie o componente do servidor de gerenciamento:
      apigee-service edge-management-server restart
  2. Atualize o processador de mensagens:

    1. Em cada nó do processador de mensagens, abra /opt/apigee/customer/application/message-processor.properties.
    2. Adicione estas duas linhas ao arquivo de propriedades:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Reinicie o componente do processador de mensagens:
      apigee-service edge-message-processor restart
  3. Atualize o roteador:

    1. Em cada nó do roteador, abra /opt/apigee/customer/application/router.properties
    2. Adicione estas duas linhas ao arquivo de propriedades:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Reinicie o componente do processador de mensagens:
      apigee-service edge-router restart
  4. Atualize o QPID:

    1. Em cada nó QPID, abra /opt/apigee/customer/application/qpid-server.properties
    2. Adicione estas duas linhas ao arquivo de propriedades:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Reinicie o componente do processador de mensagens:
      apigee-service edge-qpid-server restart
  5. Atualize o Postgres:

    1. Em cada nó do Postgres, abra /opt/apigee/customer/application/postgres-server.properties.
    2. Adicione estas duas linhas ao arquivo de propriedades:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. 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:

select count(*) from information_schema.tables

Alternativa: quando Atualizar o Apigee Edge 4.50.00 ou 4.51.00 para 4.52.00, realize etapa preliminar antes de fazer upgrade do Apigee-postgresql.

apigee-mirror no RHEL 8.0

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.

  1. Crie um arquivo de propriedades de configuração se ele ainda não existir:
    /opt/apigee/customer/application/message-processor.properties
  2. 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).
    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. Certifique-se de que o arquivo /opt/apigee/customer/application/message-processor.properties é de propriedade da apigee:apigee.
  4. 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:

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