Problemas conhecidos com a Apigee

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

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

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

• A pesquisa será integrada ao portal integrado em uma versão futura.

Para o Edge para nuvem privada 4.53.00, a configuração de novos clusters só é possível com um procedimento de instalação nova. Não há suporte para upgrades no local. Se você estiver usando uma versão mais antiga do Edge para nuvem privada, o upgrade direto para o Edge para nuvem privada 4.53.00 não estará disponível.

Embora não haja suporte para upgrades no local, é possível configurar um novo cluster do Edge para nuvem particular 4.53.00 e usar APIs de gerenciamento para exportar dados do cluster antigo e importá-los para o novo cluster 4.53.00.

Esse problema afeta os usuários que tentam instalar o SSO ou a nova interface no RHEL 8 com a ativação do FIPS no Edge para nuvem privada 4.53.00.

Componente afetado:SSO e nova interface

Problema:se você estiver instalando o SSO ou a nova interface no sistema operacional RHEL 8 com suporte ao FIPS, a instalação falhará.

Solução alternativa:use a interface clássica, que tem todos os recursos e atende às necessidades de funcionalidade da interface.

Esse problema afeta apenas quem está usando o MINT ou tem o MINT ativado nas instalações do Edge para nuvem privada.

Componente afetado:edge-message-processor

Problema:se a monetização estiver ativada e você instalar o 4.52.01 como uma nova instalação ou fizer upgrade de versões anteriores da Nuvem particular, vai ocorrer um problema com os processadores de mensagens. Haverá um aumento gradual na contagem de linhas de execução abertas, o que leva ao esgotamento de recursos. A seguinte exceção é mostrada no edge-message-processor system.log:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread

Uma vulnerabilidade de negação de serviço (DoS) foi descoberta recentemente em várias implementações do protocolo HTTP/2 (CVE-2023-44487), incluindo no Apigee Edge para nuvem privada. 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 sã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 deles está exposto à Internet. Em componentes que não são do Edge, como Cassandra, Zookeeper e outros, o HTTP/2 não está ativado. Recomendamos que você siga as etapas abaixo para lidar com a vulnerabilidade do Edge para nuvem privada:

• Etapas para o Edge para nuvem privada versão 4.51.00.11 ou mais recente
• Etapas para versões do Edge para nuvem privada anteriores à 4.51.00.11

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

1. Atualizar 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. Atualizar 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. Atualização do 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. Atualização do 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 estiver usando versões do Edge para 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 as duas linhas a seguir 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 as duas linhas a seguir 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. Atualizar o roteador:

   1. Em cada nó do roteador, abra /opt/apigee/customer/application/router.properties
   2. Adicione as duas linhas a seguir 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. Atualização do 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. Atualização do 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

O Apigee-postgresql está com problemas ao fazer upgrade da versão 4.50 ou 4.51 do Edge para nuvem privada 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, execute a etapa preliminar antes de fazer upgrade do Apigee-postgresql.

apigee-mirror não funciona no Red Hat Enterprise Linux (RHEL) 8.0.

Alternativa: como alternativa, instale apigee-mirror em um servidor que execute uma versão anterior do RHEL ou outro sistema operacional compatível com a Apigee. Você pode usar o espelho para adicionar pacotes, mesmo que tenha instalado o Apigee em servidores RHEL 8.0.

149245401: as configurações do pool de conexões LDAP para JNDI configuradas pelo recurso LDAP não são refletidas, e os padrões do JNDI causam conexões de uso único sempre. Como resultado, as conexões são abertas e fechadas a cada uso, criando um grande número de conexões por hora para o servidor LDAP.

Alternativa:

Para mudar as propriedades do pool de conexões LDAP, siga as etapas abaixo para definir uma mudança 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 das propriedades 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. Confira se o arquivo /opt/apigee/customer/application/message-processor.properties pertence à apigee:apigee.
4. Reinicie cada processador de mensagens.

Para verificar se as propriedades JNDI do pool de conexões estão entrando em vigor, execute um tcpdump para observar o comportamento do pool de conexões LDAP ao longo do tempo.

139051927: as latências de processamento de proxy altas 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 normais de resposta da API e podem ocorrer aleatoriamente, 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 para 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 org/env em uma configuração e um grande número de servidores de destino que excede 50, os URLs dos servidores 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, pesquise no system.logs do processador de mensagens pela 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 do HTTPClient porque o tamanho do cache é muito pequeno.

Solução alternativa:nas versões 19.01 e 19.06 do Edge para nuvem privada, é possível editar e configurar o cache HTTPClient, /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 precisa ser maior que o número de servidores de destino com os quais o processador de mensagens se conectaria. Não há efeitos colaterais ao definir essa propriedade em um valor mais alto, e o único efeito seria um melhor processador de mensagens para processar os tempos de solicitação do proxy.

Observação:a versão 50.00 do Edge para nuvem privada tem a configuração padrão de 500.

157933959: Inserções e atualizações simultâneas no mesmo mapa de valores-chave (KVM) com escopo no 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 o KVM no escopo apiproxy.