Engine

Esta mensagem não é um erro, mas sim uma crítica de segurança. Apenas usuários com permissão de acesso remoto pode acessar uma instância do Engine em uma determinada base.

O responsável pela liberação de acesso é o Administrador do Sistema responsável pela base.

Para liberar o acesso do usuário para realizar o acesso remoto siga os passos a baixo:

• Vá em “Administração do sistema > Segurança > Grupos e usuários > Usuários”;
• Selecione o usuário que deseje dar o acesso remoto e entre no modo ficha;
• No campo Política de Segurança, selecione uma política de segurança que tenha o acesso remoto habilitado. Para identificar se uma política de segurança possui acesso remoto habilitado, basta verificar se o caixa de verificação (checkbox) Acesso Remoto está marcado. Para abrir o cadastro de política de segurança a partir do cadastro de usuários, basta clicar duas vezes no campo Política de Segurança.
• Se não houver política de segurança cadastrada com o acesso remoto habilitado, você deve cadastrar uma e associar ao usuário.

Este problema ocorre, porque existe um erro de programação no processo.

A propriedade indexFieldName está com a quantidade de campos menor que a quantidade de posição do array atribuída no primeiro ou segundo parâmetro do método setRange.

Exemplo:

__includeOnce(-1898145959); /* QueryAnalyzer.js */
const classKey = -1894834681; /* Vínculos Entre Fluxos de Tarefas e Situações */
const ds = connection.cloneLocalCacheByClass(classKey);

const fluxos = [ -1895831369, -1895831370, -1895831371 ];
ds.indexFieldNames = "CHTABELA"; // 1 campo
ds.setRange( fluxos, fluxos ); // 3 posições para cada parâmetro
ds;

Correto:

__includeOnce(-1898145959); /* QueryAnalyzer.js */
const classKey = -1894834681; /* Vínculos Entre Fluxos de Tarefas e Situações */
const ds = connection.cloneLocalCacheByClass(classKey);

const fluxos = [-1895831371 , -1895831369 ];
ds.indexFieldNames = "CHTABELA"; // 1 campo
ds.setRange( fluxos[0], fluxos[1]); // 1 posição para cada parâmetro
ds;

Este erro ocorre quando a quantidade máxima de conexões com um banco de dados foi excedida.

A configuração da quantidade máxima de banco de dados é feito no manage em Configuration/Databases/MDBC.

Quando há pouca memória virtual disponível para o sistema de modo que não haja memória suficiente para alocar uma string de um determinado tamanho.

O sistema passa a subir esta mensagem de erro. A quantidade máxima de memória virtual por processo é limitada pelo sistema operacional. Em sistemas operacionais de 32bits a quantidade máxima de memória virtual é 2GB.

Para resolver este problema é necessário fazer o diagnóstico do consumo excessivo de memória e corrigir o trecho de código que causa o consumo excessivo de memória.

Está mensagem ocorre quando scheduler tentar autenticar o usuário que está executando a tarefa.

Observações:

1. Verifique se a chave do usuário existe na base que a tarefa está sendo executada.
2. Altere a chave do usuário, caso precise.

Este erro geralmente ocorre quando o IP:PORTA de uma base de destino está errado e coincidiu de apontar para outro um serviço qualquer na rede ou internet.

Exemplo concreto:

No processo de atualizar da iVFS se você informar o IP:PORTA de um servidor de FTP est mensagem de erro irá aparecer.

Tecnicamente falando, o problema ocorre ao criar uma instância do objeto Connection com os parâmetros IP:PORTA de um outro serviço qualquer que não seja um Engine usando o protocolo IAP.

O protocolo IAP tenta obter a versão da base que o Connection está tentando se conectar e um outro serviço, que não conhece o protocolo IAP, responde com um valor inesperado.

Para resolver o problema certifique-se de que o IP e a porta estão corretos.

Este erro pode ocorrer durante uma tentativa de impressão no sistema. Existem vários fatores que podem causar este problema e um deles é a possibilidade de um software antivírus que esteja apagando o arquivo <Diretório do Engine>\htmlprinter\htmlprinter.exe.

Para diagnosticar se é o software antivírus o causador do problema, desabilite a proteção do antivírus, renomeie pasta <Diretório do Engine>\htmlprinter e tente imprimir novamente. Se a impressão for bem sucedida, fica claro que o antivírus é o causador do problema. Não se esqueça de desfazer a renomeação da pasta <Diretório do Engine>\htmlprinter após realizar o procedimento de diagnóstico.

Se o problema for causado pelo antivírus, realize o seguinte procedimento para resolvê-lo:

• Configure o antivírus para que ele ignore o htmlprinter.exe. Não temos como detalhar o procedimento de configuração porque não conhecemos o antivírus usado na estação que apresenta o defeito. A maioria dos antivírus possuem uma lista de softwares confiáveis na qual poderá ser adicionado o htmlprinter.exe. Não sabemos se o seu antivírus possui esta lista, talvez ele possua, mas com outro nome por exemplo Zona de Segurança, Área Segura, etc…
• Renomeie a pasta “<Diretório do Engine>\htmlprinter\job” para “<Diretório do Engine>\htmlprinter_job”. Este passo só é recomendável se você quiser que não sejam impressas as impressões que falharam anteriormente e por isso ficaram acumuladas na pasta “<Diretório do Engine>\htmlprinter\job”. Veja a quantidade de arquivos que esta pasta tem. Se tiver poucos arquivos e se você realmente deseja imprimí-los, então não renomeie esta pasta.
• Exclua o arquivo “htmlprinter.version”, presente em “<Diretório do Engine>\htmlprinter".

Pronto. Agora você poderá imprimir novamente.

A mensagem de erro “Internal Error: Wrong Ido Page Format” é motivada por uma corrupção do cache local de dados. A corrupção do cache local de dados pode ocorrer em situações em que o usuário fecha o engine de forma forçada, usando o gerenciador de tarefas do windows ou até mesmo quando falta energia durante uma transação.

Se o erro for no Engine, você deverá fazer:

• O backup das pastas: logs e dbCache;
• Em seguida deverá descartar o cache local.
• Enviar para o administrador do sistema o cache local de dados, o backup do cache local de dados e os logs.

Este problema pode ocorrer nas seguintes situações:

• A JRE não está instalada na máquina onde o possui uma instância do Engine tentando acessar a JVM. Solução: Basta instalar nesta máquina o último release da JRE 6.0. A instalação do JDK não é suficiente, embora ele já traga uma JRE.

• A versão da JRE instalada seja 32 bits e o Engine seja 64 bits (o mesmo ocorreria no caso contrário também). Solução: Se certificar que JVM e Engine estejam, ambos, com a mesma configuração (32 ou 64 bits).

Existe um comportamento, a partir do Windows Vista, que se a aplicação não está sendo executada com privilégios de administrador, a escrita para arquivos em diretórios considerados “sensíveis”, tais como o “C:/” ou “Arquivos de Programas” é bloqueada.

Se o engine está executando sem permissão de administrador e um arquivo é requisitado a ser gravado na Raiz, o usuário não achará o arquivo nesse diretório. Ele todavia será gravado em outro local. Essa técnica é chamada de UAC Virtualization.

Exemplo:

Usuário tenta gravar o arquivo.

var file = new File("C:\\teste.txt")

Tal arquivo não ficará nesse diretório, mas sim em.

C:\Users\Username\AppData\Local\VirtualStore\teste.txt

O Windows abstrai essa mudança de diretório. Caso o usuário queira ler o arquivo, considere o mesmo diretório que foi indicado na criação. O Windows redirecionará a requisição de leitura para o diretório em que o arquivo foi gravado. Portanto a aplicação rodará sem problemas. A única coisa que pode incomodar é que o usuário não verá o arquivo na Raiz.

Caso você queira forçar que o arquivo seja gravado nos diretórios que a Microsoft considera sensíveis, terá que dar permissão ao engine de que rode como administrador. Você pode fazer isso clicando com o botão direito do mouse e selecionando a opção “executar como administrador”.

Ao tentar carregar um cache do início, dependendo do tamanho das tabelas de cadastro, pode ser levado um tempo considerável na montagem do cache no disco. Esse tempo vai variar de acordo com o tamanho dessas tabelas, pois os dados serão capturados no banco e salvos no disco. Nessas tabelas estão os registros como: cadastro de cliente, preço, estabelecimentos, etc. Enquanto o Engine estiver carregando esse cache, ele não poderá ser utilizado. Por esse motivo, a recarga do cache só deve ser feita em casos de extrema necessidade, se tiver de ser feito em horário que o sistema esteja em uso. Alguns fatores influenciam nesse tempo de carga, como por exemplo: processador, memória RAM, velocidade do disco, conexão com o banco de dados e volume dos dados.

A maneira para se fazer uma nova carga do cache é parar a execução do Engine e depois excluir (se houver necessidade de guardar esse cache, as pastas poderão ser somente renomeadas, como por exemplo adicionar “_” ao final do nome de cada uma delas) as pastas dbCache, dbCacheBackup e dbCacheProvider, presentes dentro do diretório onde está o Engine. Quando o Engine for iniciado novamente, as pastas citadas acima serão recriadas e o cache montado novamente.

O cache também pode ser remontado a partir do backup existente no diretório do Engine. Para isso, somente a pasta dbCache deve ser excluída ou renomeada. Porém, é importante ressaltar que o backup só é feito quando o Engine é inicializado. Caso o Engine não seja iniciado diariamente, o backup pode ser muito antigo, e a sua atualização poderá ser muito demorada. A sugestão é que o Engine seja reiniciado em um determinado horário que não esteja em uso. Se estiver como serviço do Windows o interessante é configurar uma tarefa que, em determinado horário, reinicie o serviço. Isso fará com que o backup do cache seja atualizado e em casos onde é necessário recarregar o cache bastará excluir a pasta dbCache pois será utilizado o backup.

Vale ressaltar que em se tratando de gerência de riscos para casos de problema no Engine ou na máquina onde há o servidor principal, o mais indicado é utilizar técnicas de replicação, como por exemplo: ter um outro Engine como servidor de aplicação onde esse Engine não recebe nenhum tipo de requisição e só existe para que seja feito backup e mantenha um cache íntegro. É importante que esse Engine seja reiniciado toda noite, para que o backup do cache seja sempre realizado. Em casos de indisponibilidade do servidor principal, uma solução rápida seria só mudar o diretório do serviço, fazendo com que o servidor que era de backup passe a ser o principal.

Outro ponto é que mesmo utilizando a técnica acima, ainda há a possibilidade do próprio hardware, onde está o servidor, ter um problema. Para esse caso, seria interessante ter uma outra máquina com a mesma configuração e com o Engine já configurado e que estivesse sendo mantido o cache atualizado. Com a queda do servidor principal por problema de hardware, rapidamente o outro servidor poderia ser colocado no ar, lembrando apenas de alterar o IP.

Essas técnicas visam a robustez da arquitetura a ser utilizada na aplicação, tendo sempre um opção para qualquer problema que possa vir a ocorrer e fazendo com que a resposta seja rápida para esses problemas, minimizando o tempo offline da base.

Quando o modo DEBUG do dbCache.log está ativado, é possível que seja visto o erro: Erro: Key “xxxx” found, but field “xxxx” not found.

Esse erro ocorre porque se tentou acessar um campo de uma chave que está no cache local, porém esse campo não existe na tabela ao qual a chave pertence.

Exemplo: tentar capturar o campo NOME em um chave que pertence a tabela IGROUPUSER. Vai ser lançado o erro no dbCache.log pois não existe o campo NOME nessa tabela. session.userKey.nome

Esse erro será lançado para aplicação, ou seja, para o browser. A menos que seja tratado no processo, pelo desenvolvedor.

Não é possível o Engine saber se o erro é grave ou não, pois trata-se de uma implementação onde o desenvolvedor dos processos e relatórios faz uso do recurso de captura de campo através de chave do cache local. Somente quem desenvolveu o processo/relatório sabe o quão grave é não ter o valor do campo ou estar tentando pegar o valor de um campo através de uma chave que não possui o campo buscado.

Esse erro indica que a tabela de caracteres(Charset) do SGBD não é compatível com o Engine. O Engine, sendo servidor de base, verifica em sua inicialização se a tabela de caracteres do SGBD é compatível, registrando no log essa mensagem caso não seja.

Esse problema costuma ocorrer quando se utiliza no banco a tabela de caracteres ISO 8859-1, que é um subconjunto da Win1252, formato utilizado pelo SO Windows localizado para o Brasil. Quando se tenta gravar algum registro com caracteres que não estão presentes no CharSet ISO 8859-1, o registro não é gravado corretamente, ocasionando diversos problemas.

Solução:

Alterar o character set do banco para WIN1252 ou UTF8. Caso a base já tenha sido criada, deve-se criar um dump do banco atual, criar um novo esquema com um charset compatível, restaurar o dump para o novo esquema.

Este erro acontece porque uma chave negativa gerada no servidor já existia no banco de dados. A causa desse erro, geralmente, é a presença de um script custom trazido de outra base quando não deveria.

Para solucionar o problema, deve-se contactar o administrador.

Em casos específicos pode ser necessário descartar uma tabela do cache das instâncias dos Engines clientes de forma remota, sem que seja necessário descartar todo o cache. Neste caso ao ser reiniciado o Engine descartará a tabela e irá carregá-la novamente a partir do banco de dados.

O descarte da tabela somente acontece no iniciar do Engine. Se o Engine estiver em execução quando os registros forem deletados, a sincronização ocorrerá da forma atual, sem haver o descarte da tabela. Para haver o descarte, o Engine deve estar fechado, para que ele, ao iniciar, detecte que antes de sincronizar, a tabela deve ser descartada.

Atenção, o procedimento afeta todos os Engines clientes da base, que recarregarão a tabela ao serem reiniciados. Deve ser usado com bastante cuidado, pois a carga de uma tabela do cache pode ser demorado.

O procedimento é feito a partir da execução do script abaixo:

executeScript('ufs:engine/routines/system/discardTableOnCache.js', 'tableName', 'nomeDaTabela');

O Engine fica monitorando a hora da máquina, e registra em seus logs essa mensagem sempre que a hora da máquina é alterada. Essa mensagem também é gerada sempre que o sistema sincroniza automaticamente a sua hora.

Deve-se evitar alterar a hora da máquina com o sistema em funcionamento. Nas cidades que adotam o horário de verão, deve-se configurar o Sistema Operacional para fazer o ajuste da hora automaticamente.

Este erro é disparado quando uma consulta SQL ao servidor ultrapassa o tamanho máximo definido. Atualmente o tamanho máximo é de 1,5Mb.

Para resolver este problema o Administrador de Sistemas deve ser contactado e este deverá acionar o desenvolvedor responsável pela consulta para que ela seja corrigida.

Esse erro pode acontecer quando não há memória virtual contínua suficiente na máquina para alocar uma máquina virtual Java. Desta forma, é necessária que as seguintes medidas sejam tomadas para se evitar este erro:

1. Se a máquina em que o erro ocorreu tem apenas 2 GB de memória física, recomenda-se que seja executado juntamente com o engine, apenas programas que são essenciais, desta forma a fragmentação da memória é evitada, garantindo assim espaço contínuo para que a JVM seja alocada;
2. Se a máquina em que o erro ocorreu tem 3 GB ou mais, é possível aumentar a memória virtual para 3 GB, ou seja, a memória máxima que cada programa pode alocar. Para isso, bastar ligar o switch 3GB do windows. O passo a passo para se fazer isso está aqui. Se apenas esse passo não for suficiente, ele pode ser combinado com o passo 1 para uma melhor economia no consumo e menor fragmentação da memória.

Para que o navegador do caixa entre automaticamente no modo kiosk na inicialização do Windows será necessário que:

1. O atalho do engine esteja na pasta de inicialização do Windows.
2. O Chrome deve estar configurado da seguinte forma

• No navegador vá em menu > configuração > inicialização e selecione “Abrir a página Nova guia”.

Atualmente o sistema possui a seguinte limitação para o uso do HtmlPrinter. Quando o Engine está sendo executado como serviço do Windows, não é possível iniciar o programa HtmlPrinter, que realiza a impressão automática de páginas Html.

Com a versão mais atualizada do HtmlPrinter, é possível executá-lo como serviço utilizando programas especializados em executar aplicações como serviço do Windows. Nós usamos e testamos o seguinte programa: AlwaysUp

Usando esse programa é possível selecionar o executável do HtmlPrinter, localizado na pasta HtmlPrinter dentro da pasta de instalação do sistema, e iniciá-lo como serviço pelo próprio AlwaysUp. Devido o HtmlPrinter possuir um browser embarcado, a instalação como serviço deve ser feita semelhante ao tutorial do site http://www.coretechnologies.com/products/AlwaysUp/Apps/RunInternetExplorerAsAService.html

Após a inicialização, o HtmlPrinter estará sendo executado como serviço e a comunicação com o Engine ocorre normalmente, não precisando realizar configuração alguma.

Existem outras ferramentas similares ao AlwaysUp que podem ser testadas.

Para que um usuário do windows, que não possui permissões de administrador, tenha permissão sobre um determinado serviço que é executado no windows temos que executar os passos abaixo.

1. Para podermos realizar as configurações temos que acessar o windows através de uma conta de administrador.

2. Acessado o sistema como administrador precisamos pegar o valor do SID (Security Identifier) do usuário o qual pretendemos conceder a permissão.

   2.1. Podemos pegar o valor do SID da seguinte forma:

   2.2. Basta acessar o registro do sistema, na pesquisa do windows digite “regedit.exe” e execute.

   2.3. Para acessar o que queremos basta acessar a árvore do sistema que fica a esquerda no seguinte caminho HKEY_LOCAL_MACHINE>SOFTWARE>Microsoft>Windows NT>CurrentVersion>ProfileList

   2.4. Aqui teremos várias pastas sendo cada uma referente a um usuário do sistema, o nome de cada pasta é o SID referente a este usuário. Para sabermos de qual usuário se trata cada pasta basta clicarmos em cima da pasta e verificarmos no quadro a direita a coluna “Dado” no registro de nome “ProfileImagePath” possui o nome do usuário.

   2.5. Uma vez identificado o usuário desejado, copie o valor do SID, que será algo como S-1-5-21-2103278432-2794320136-1883075150-1000. Recomendamos que copie e cole em um arquivo de texto pois será usado posteriormente.

3. Agora precisamos pegar as permissões atribuídas ao serviço que queremos que o usuário tenha acesso.

   3.1. Acesse o prompt de comando do windows. Na pesquisa do windows digite “cmd”.

   3.2. Digite a linha de comando abaixo:

   sc sdshow <NOME DO SEU SERVIÇO>

   Ex: sc sdshow teste

   3.3. A execução desse comando retornará as permissões de cada grupo e usuário que este serviço possui. Será algo como

   D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

   3.4. Copie e cole junto ao SID.

4. De posse das permissões do serviço copie o trecho igual a esse “(A;;CCLCSWRPWPDTLOCRRC;;;SY)” sem as aspas e edite da seguinte forma:

   4.1. Substitua o valor entre os pontos e vírgula “CCLCSWRPWPDTLOCRRC” por “RPWPCR”.

   4.2. Substitua o valor “SY” pelo SID que foi obtido no passo 2.

   4.3. Ao final teremos algo como isso

   (A;;RPWPCR;;;S-1-5-21-2103278432-2794320136-1883075150-1000)

   4.4. Copie este novo trecho e cole imediatamente antes do trecho “S:(AU;…” no valor que tínhamos originalmente.

   4.5. O valor final será assim:

   D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;RPWPCR;;;S-1-5-21-2103278432-2794320136-1883075150-1000)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD

   É este o valor que iremos usar para reconfigurar as permissões do serviço. Atenção pois esse valor não possuem salto de linha, ele é uma linha só.

5. Agora iremos modificar as permissões do serviço.

   5.1. Abra o prompt de comando do windows novamente e digite o comando abaixo:

   sc sdset <NOME DO SEU SERVIÇO> <Valor das permissões que acabamos de alterar, deve ser entre aspas duplas>

   Exemplo:

   sc sdset teste "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;RPWPCR;;;S-1-5-21-2103278432-2794320136-1883075150-1000)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)"

   Atenção pois esse valor não possui salto de linha, ele é uma linha só.

   5.2. Execute o comando e aparecerá na tela a seguinte mensagem: [SC] SetServiceObjectSecurity SUCCESS ou [SC] SetServiceObjectSecurity ÊXITO

6. Agora basta trocar de usuário e conferir se as permissões foram concedidas com sucesso.

Caso você queira que todos os usuários tenham acesso a um determinado serviço basta trocar o SID do usuário por “NS”.

Exemplo: sc sdset teste "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;RPWPCR;;;NS)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)"

Essa mensagem ocorre quando não há mais memória disponível no sistema operacional Windows para criar um temporizador. Esse erro pode ocorrer por dois motivos:

1. Esgotamento de memória física ou do espaço em disco do servidor.
2. Esgotamento da reserva de memória de heap para interfaces do Windows, chamada de “Desktop Heap”.

Descartada a possibilidade de ter ocorrido um esgotamento da memória física disponível, que pode ser identificado via monitoramento do uso de memória do servidor ou pelas informações contidas no arquivo “supervisor.log”, deve-se suspeitar que possa ter ocorrido um esgotamento do “Desktop Heap”.

Apesar do nome, o “Desktop Heap” afeta todos os aplicativos do Windows, incluindo os serviços não interativos, pois esses podem criar internamente objetos que utilizam essa reserva de memória, como é o caso do Engine. Essa reserva de memória é compartilhada entre todos os processos, portanto, servidores com muitos serviços ou aplicativos podem atingir o limite padrão do sistema operacional.

Nas versões atuais do Windows não há uma forma eficaz de monitorar o uso do “Desktop Heap”. No entanto, há uma forma de aumentar esse limite por meio de uma configuração do registro do Windows. Antes de fazer qualquer alteração, é importante fazer um backup do servidor, pois alterações incorretas no registro podem causar instabilidade ou até impedir a inicialização do sistema operacional. Para realizar a alteração, siga os passos abaixo:

1. Inicie o editor de registro (Iniciar > Executar > regedt32).
2. Localize a chave de registro “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems”.
3. Clique com o botão direito do mouse na entrada “Windows” e selecione “Modificar”.
4. Incremente o terceiro valor da seção “SharedSection”. É recomendado que sejam feitos incrementos pequenos, não maiores que 256. Por exemplo, se o valor atual for SharedSection=1024,20480,768, altere para SharedSection=1024,20480,1024.
5. Reinicie o servidor.

A seção “SharedSection” do registro do Windows é composta por três valores separados por vírgulas. O primeiro valor é a quantidade de memória heap utilizada para armazenar a tabela de identificadores globais e configurações do sistema compartilhada com todos os processos e geralmente não precisa ser modificado. O segundo valor é o tamanho do heap para cada área de trabalho associada a uma estação de trabalho interativa. O terceiro valor é o tamanho do heap utilizado por estações de trabalho não interativas. Para Engines configurados como serviços não interativos, o terceiro valor é o que precisa ser modificado para aumentar o limite do “Desktop Heap”. Os valores são informados em kilobytes (KB). Mais detalhes em https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/desktop-heap-limitation-out-of-memory.

O alocador de memória padrão do Windows Server 2016 e 2019 é o “NT Heap” e ele possui problemas conhecidos de fragmentação de memória que podem levar a uma degradação significava de desempenho de aplicações que requerem alocações frequentes e sob concorrência de memória.

Para resolver essas questões, em 2020 a Microsoft disponibilizou um novo alocador de memória conhecido por “Segment Heap”, inicialmente introduzido no Windows 10 (build 19041) e Windows 11, sendo posteriormente incluído no Windows Server 2022 e sucessores. O novo alocador emprega estratégias mais sofisticadas que evitam a fragmentação de memória, melhorando significativamente o desempenho e consumo de memória das aplicações afetadas pelo comportamento do “NT Heap”.

A partir da versão 70, o Engine passa a indicar via manifesto de aplicação Windows que ele é compatível com o novo alocador, mas, que para essa configuração seja efetiva, é necessário que o Windows também disponibilize o novo alocador de memória, o que não ocorre nas versões 2016 e 2019 do Windows Server.

Por esse motivo, é recomendado que servidores que utilizem o Windows 2016 e 2019 sejam atualizados para versões mais recentes desse sistema operacional a fim de garantir um melhor funcionamento do sistema, em especial em ambientes com maior carga de trabalho e alocação de memória. Enquanto essa atualização não é realizada, é importante que o serviço do Engine seja reiniciado periodicamente, sendo recomendado ao menos um reinício por dia, diminuindo assim o impacto da fragmentação de memória no funcionamento do sistema.

Mais detalhes podem ser obtidos nos documentos abaixo:

• Application manifests
• Windows 10 Segment Heap Internals
• malloc/free performance slows down over time

A configuração incorreta de certificados digitais podem impedir o acesso ao sistema de forma segura pelos usuários e a integração com outros sistemas via API HTTPs. No acesso via navegadores, o usuário pode se deparar com mensagens de erro como “A conexão não é segura” ou “A conexão não é particular”. Na integração entre sistemas, o uso da API XMLHttpRequest pode falhar com mensagens de erro como “uma cadeia terminou em um certificado raiz que não é confiável para o provedor de confiabilidade (os error -2146762487)” ou “um certificado necessário não está no período de validade (os error -2146762495)”. Em Engines clientes, pode-se observar também a mensagem de erro “Failed calling WinHttpQueryHeaders. WinHTTP Error: (12175)” nos logs.

Para resolver esses erros, deve ser verificado se o certificado digital utilizado está válido e se a cadeia de certificados informadas pelo servidor está correta. Para isso, pode ser utilizado o site SSL Labs. Após informar o endereço HTTPS do servidor, o site apresentará uma nota que deve estar entre A e C, dependendo das configurações do servidor. Erros comuns que são observados:

1. Certificado expirado.
2. Cadeia de certificados incorreta ou incompleta na seção “Additional Certificates”.

Caso o certificado esteja expirado, ele deve ser renovado ou deve ser emitido um novo junto a uma certificadora. Dependendo da configuração do ambiente, ele deve ser instalado no balanceador de carga ou no Engine.

Em relação aos certificados intermediários, normalmente os certificados digitais atuais utilizam uma cadeia de 3 certificados. O primeiro é o certificado final que é aquele associado ao nome do servidor informado na URL. O segundo é um certificado intermediário da autoridade certificadora utilizado para assinar o certificado final. Esse certificado intermediário é fornecido pela autoridade certificadora no momento da emissão do certificado final e deve ser fornecido pelo servidor juntamente com o certificado final aos clientes HTTP. Por último, há o certificado raiz da autoridade certificadora que foi utilizado para assinar o certificado intermediário. A distribuição dos certificados raízes é feita automaticamente pelos sistemas operacionais e navegadores, não sendo necessário que eles sejam configurados ou fornecidos pelo servidor. Para que essa distribuição ocorra corretamente, é importante que os clientes utilizem sistemas operacionais e navegadores atualizados.

Um erro comum é o administrador configurar apenas o certificado final no servidor, sem informar o certificado intermediário. Caso o certificado esteja configurado no Engine, esse problema pode ser identificado abrindo o arquivo do certificado informado no Manage e verificando se há duas seções “—–BEGIN CERTIFICATE—–”. Se já houver duas, devem ser copiados os certificados para arquivos textos separados com os nomes “first.crt” e “second.crt”. Ao abrir o primeiro arquivo, deve-se verificar que ele é o certificado do nome do domínio da empresa. Ao abrir segundo, deve-se verificar se ele é o certificado utilizado para assinar o primeiro. Ambos os certificados não devem estar expirados.

Mais detalhes sobre a configuração de certificados no Engine podem ser encontrados na seção “Emissão manual via autoridades certificadoras” do manual Configuração do HTTPS no Engine.

Importante: durante uma renovação do certificado digital raiz do “Let’s Encrypt” houve um problema conhecido que afetou algumas instalações do Windows 10. Caso utilize certificados dessa autoridade certificadora e observe problemas de acesso em apenas alguns clientes, é importante verificar se o cliente não foi afetado por esse problema, discutido no fórum https://community.letsencrypt.org/t/isrg-root-lazy-loading-problem-missing-from-random-updated-windows-10-versions/141550. Uma solução possível é a instalação manual dos certificados raízes “ISRG Root X1” e “ISRG Root X2” do “Let’s Encrypt” disponíveis em https://letsencrypt.org/certificates/. Os certificados podem ser baixados nas seções “Certificate details (self-signed)”. No caso do Windows deve ser optado pelo arquivo no formato “der”. Apos o download, deve ser aberto o arquivo e em seguida deve ser utilizado o botão “Instalar certificado” e selecionada a opção “Máquina local”.

Para identificar se o desligamento do sistema foi feito de forma correta, é necessário olhar o log engine.log, que pode ser acessado através do link log no manage ou acessando a pasta logs na raiz do sistema.

Cada log possui um nome, e os logs de dias anteriores possuem o nome mais a data.

Exemplos:

• engine.log : Log referente ao dia corrente.
• engine.log.2015-09-18 : Log referente ao dia 18/09/2015.

O engine.log registra os dados da inicialização e finalização do sistema.

Existem duas palavras chave principais para identificação da inicialização e finalização do sistema, são elas, startup e shutdown respectivamente. A linha indicada no item 3 representa o encerramento completo.

1. A linha de log abaixo indica que o sistema está sendo iniciado: 17/09 17:14:15 [INFO] ngin.core.kernel - engine.exe version 79.0.0 startup
2. A linha de log abaixo indica que o desligamento do sistema foi iniciado: 17/09 17:13:14 [INFO] ngin.core.kernel - engine.exe version 79.0.0 shutdown.
3. A conclusão do encerramento é indicada na linha abaixo: 17/09 17:13:17 [INFO] ngin.dbcache.NGINSTACK - Database closed successfully.

Durante a finalização do sistema são feitas operações para guardar os dados que estavam sendo manipulados pelo sistema, garantindo a integridade do cache após o desligamento. Esses processos são logados entre as linhas 2 e 3. Segue abaixo o exemplo completo.

17/09 17:13:14 [INFO] ngin.core.kernel - engine.exe version 15.9.0.2 shutdown.
17/09 17:13:14 [INFO] ngin.core.kernel - Stop done.
17/09 17:13:15 [INFO] ngin.core.keycache - Finishing KeyCache. Next available key is 412224269
17/09 17:13:17 [INFO] ngin.dbcache.NGINSTACK - Table "iLob" closed 0 records.
17/09 17:13:17 [INFO] ngin.dbcache.NGINSTACK - Table "iSchedulerTask" closed 3 records.
17/09 17:13:17 [INFO] ngin.dbcache.NGINSTACK - Table "iSecurityPolicy" closed 10 records.
17/09 17:13:17 [INFO] ngin.dbcache.NGINSTACK - Closing database.
17/09 17:13:17 [INFO] ngin.dbcache.NGINSTACK - Database closed successfully.
17/09 17:14:15 [INFO] ngin.core.kernel - engine.exe version 79.0.0 startup as PID 11492 on Windows Server 2019 using command line 'C:\Engines\NGINSTACK\engine.exe -s -svc ENGINE_NGINSTACK

Esses logs mostram a verificação que é feita, tabela por tabela, para finalizar os registros corretamente. Quando o sistema é desligado abruptamente, seja por reinício forçado ou uma queda de energia, esses processos não são executados, logo a integridade dos dados não pode ser garantida. Segue abaixo um exemplo de log onde o sistema não foi desligado corretamente.

11/09 11:41:06 [INFO] ngin.core.kernel - engine.exe version 15.9.0.1 startup as PID 26456::45316 on Windows Server 2008 R2 SP1[NTFS] using command line 'C:\Engines\NGINSTACK\engine.exe -s -svc Unum_DESENVOLVE_8001 '
11/09 11:41:06 [INFO] ngin.sys - Registry(MemManage Info) selected value is 2, heuristic 4
11/09 11:41:06 [INFO] ngin.core.kernel - Computer name: FORMOSA(172.16.1.6). MacAddress: 001517A257E2
11/09 11:41:06 [INFO] ngin.core.kernel - Processor name: Intel(R) Xeon(R) CPU           X5650  @ 2.67GHz
11/09 11:41:06 [INFO] ngin.core.kernel - Physical memory is 32706MB; Virtual memory is 4095MB
11/09 11:41:06 [INFO] ngin.core.kernel - Free disk size is 43362MB
11/09 11:41:06 [INFO] ngin.core.kernel - IDO cache size is 255MB. SyncToDisk parameter is off. Memory Manager is FastMM4
11/09 11:41:06 [INFO] ngin.core.kernel - TimeZone Bias is -180
11/09 11:41:06 [INFO] ngin.core.kernel - IdbBackup required version is 12.6.0.1, current is 12.6.0.1
11/09 11:41:06 [INFO] ngin.net.listener - Successfully bound TCP/IP port 8901.
11/09 11:41:06 [INFO] ngin.net.listener - Successfully bound TCP/IP port 8001.
11/09 11:41:06 [INFO] ngin.net.listener - Successfully bound TCP/IP port 7999.
11/09 11:41:06 [INFO] ngin.dbms.NGINSTACK - DBConnectionPool configured with 10 max connections.
11/09 11:41:06 [INFO] ngin.dbcache.NGINSTACK - Preparing DBCacheEngine to start
11/09 11:41:06 [INFO] ngin.dbcache.NGINSTACK - Provider Storage Id is 91E00A66D28E4A53B07806B0F6566E8C
11/09 11:41:06 [INFO] ngin.dbcache.NGINSTACK - Opening database.
11/09 11:41:06 [INFO] ngin.ido.db.NGINSTACK - Original Ido library version is 100; Current version is 100
11/09 11:41:06 [INFO] ngin.ido.db.NGINSTACK - DB Format version is 0
11/09 11:41:20 [INFO] ngin.dbcache.NGINSTACK - Database opened.
11/09 11:41:20 [INFO] ngin.core.keycache - First available key from keycache: 0
11/09 11:41:57 [INFO] ngin.core.dispatcher - Waiting 0 HTTP handlers.
11/09 11:41:57 [INFO] ngin.core.kernel - SessionManager - aborting all session
11/09 11:41:57 [INFO] ngin.core.kernel - DBContextManager - stopping.
11/09 11:41:57 [INFO] ngin.core.ctx - Stopping DBContextManager.
11/09 11:41:57 [INFO] ngin.dbcache.NGINSTACK - Stopping DBCacheEngine
11/09 11:42:51 [INFO] ngin.core.kernel - engine.exe version 79.0.0 startup as PID 57648 on Windows Server 2019 using command line 'C:\Engines\NGINSTACK\engine.exe -s -svc ENGINE_NGINSTACK '

Neste exemplo notamos a ausência das linhas de log 2, 3 e consequentemente das linhas que mostram a verificação das tabelas do sistema. A falta dessas linhas deixa claro que o sistema não foi desligado da forma correta, logo a verificação se torna bem simples.

O coletor de memória funciona de forma indeterminística, de acordo com as necessidades do sistema. Este pode ser disparado durante a execução de um script, caso seja verificado que foi feita uma grande alocação de memória, em sessões que se tornaram inativas e quando uma sessão é destruída.

É possível aplicar uma configuração para que o coletor seja disparado após cada execução de uma requisição da sessão. Esta funcionalidade não deve ser utilizada em produção, mas apenas para auxiliar na análise e investigação de vazamentos de memória.

Esse comportamento é habilitado através do arquivo de configuração do Engine iengine.conf, podendo ser editado diretamente no disco, ou pela interface Manage do Engine, em configuration others.

<VFSRequestHandler>
  RunGCAfterHandleRequest on
</VFSRequestHandler>

É necessário o reinício do Engine após a configuração.