Histórico da Página
| Pagetitle | ||||
|---|---|---|---|---|
|
Correções
...
| Expandir | ||
|---|---|---|
| ||
Incidente: Função FCreate quando utilizada com um caminho do client, está retornando um handle sempre válido, mesmo quando a pasta não existe, causando erro depois. Solução: Problema só ocorre no binário Onça, devido a uma melhoria no controle de arquivos para webapp/web-agent, faltava verificar se a pasta de destino existia antes de criar o arquivo. |
| Expandir | ||
|---|---|---|
| ||
Incidente: Em uma GRID, ao pressionar seta para baixo para criar uma nova linha, a linha atual é "apagada" Solução: Correção feita para tratar corretamente a criação de uma nova linha sem perder a anterior. |
| Expandir | ||
|---|---|---|
| ||
Incidente: Ao imprimir e selecionar um diretório que não existe no client, o mesmo não está verificando isso e no final da geração do arquivo gera um error.log porque o diretório não existe. Solução: Primeiro é verificado se foi possível criar o arquivo do lado do client, se negativo já retorna erro e o ADVPL consegue tratar corretamente a criação de diretório se for o caso. |
| Expandir | ||
|---|---|---|
| ||
Incidente: Ao utilizar a função tFileDialog, usar o retorno diretamente na função CpyT2S não funciona. Solução: Como a função tFileDialog joga o arquivo na pasta do usuário do webapp, foi necessário alterar a função CpyT2S para considerar essa pasta como sendo do lado do servidor para conseguir realizar a cópia. |
| Expandir | ||
|---|---|---|
| ||
Incidente: Foi observada uma intermitência no encerramento dos processos durante uma compilação de fonte ou aplicação de patch que em certas situações gerava queda do Appserver. Solução: Foi criada uma proteção na finalização dos recursos REST para evitar essa intermitência. |
| Expandir | ||
|---|---|---|
| ||
Incidente: Ao aplicar um filtro com a expressão OR em uma tabela aberta via RDD SQLite, a navegação com DBSkip(-1) apresentava falha: a aplicação não conseguia identificar corretamente o BOF (begin of file) durante a emulação ISAM. Solução: Fizemos um ajuste no AppServer para evitar a falha na identificação do BOF, o que trazia um falso entendimento de que a aplicação estava retrocedendo na navegação dos registros. |
| Expandir | ||
|---|---|---|
| ||
Incidente: função GetUserInfoArray apresentando diferença de comportamento via linha de comando do AppServer. No array de retorno da função não estava vindo os dados de nome da máquina e do usuário logado, diferente de quando executado via Smartclient. Solução: foram realizados ajustes na camada de criação de jobs. |
| Expandir | ||
|---|---|---|
| ||
Incidente: Erro 404 ao acessar o Protheus via WebApp quando a chave App_Environment está ativa e a chave RootPath utiliza um caminho relativo. O erro ocorria devido a uma restrição que bloqueia o uso de ".." na URL. Como o caminho relativo incluía "..", a requisição era barrada. Solução: Quando RootPath for configurado como relativo, ele passará a ser convertido internamente para um caminho absoluto. |
| Expandir | ||
|---|---|---|
| ||
Incidente: Queda do AppServer durante o gerenciamento de licenças web. Uma exceção lançada pelo gerenciador de licenças, ao tentar adicionar novamente uma licença já marcada como em uso, não era tratada, ocasionando a queda do AppServer. Solução: Adicionado tratamento para a possível exceção lançada pelo gerenciador de licenças, prevenindo a queda do AppServer. |
| Expandir | ||
|---|---|---|
| ||
Incidente: Parâmetros nomeados não estavam funcionando ao chamar o construtor New. Solução: Foi realizado o tratamento na linguagem TLPP para sanar esse débito técnico. |
| Expandir | ||
|---|---|---|
| ||
Incidente: Inconsistência durante o debug multithread de APIs REST via VSCode que em determinadas situações ocasionava a queda do server REST. Solução: Foi inserida uma proteção no código para evitar a inconsistência observada. |
| Expandir | ||
|---|---|---|
| ||
Incidente: HTTPQuote apresenta falha enviando Content-Length=0 incorretamente na requisição HTTP DELETE. Solução: Revisado a função HTTPQuote para tratar corretamente a requisição do tipo HTTP DELETE. |
| Expandir | ||
|---|---|---|
| ||
Proteção de uso de contextos na camada de comunicação para evitar falhas que resultavam na geração de arquivos de depuração (*.dmp) |
| Expandir | ||
|---|---|---|
| ||
Incidente: Inconsistências observáveis na integração com SQLite. Solução: Atualizações realizadas nas APIs dos componentes envolvendo o SQLite |
| Expandir | ||
|---|---|---|
| ||
Incidente: No momento de uso da autenticação via SAML é apresentada a mensagem de erro: Error with IDP metadata file: IDP metadata URI error: Couldn't resolve host name. Solução: Implementação de correção na mensagem de erro e documentação de como proceder no caso da ocorrência do erro. Documentação: https://tdn.totvs.com/display/tec/SAML+-+Error+with+IDP+metadata+file |
| Expandir | ||
|---|---|---|
| ||
Incidente: Broker Agent não estava fazendo scale-in na versão 24.3.0.11. Solução: Correção no processo de Scale-in executado pelo Broker Agent. |
| Expandir | ||
|---|---|---|
| ||
Proteção de uso de contextos na camada de comunicação para evitar falhas que resultavam na geração de arquivos de depuração (*.dmp) |
| Expandir | ||
|---|---|---|
| ||
Proteção de uso de contextos na camada de comunicação para evitar falhas que resultavam na geração de arquivos de depuração (*.dmp) |
| Expandir | ||
|---|---|---|
| ||
Proteção de uso de contextos na camada de comunicação para evitar falhas que resultavam na geração de arquivos de depuração (*.dmp) |
| Expandir | ||
|---|---|---|
| ||
Incidente: Access Violation em serviço Rest ou Broker. Solução: Foi realizado um tratamento interno para proteger o serviço, finalizando graciosamente a conexão afetada, porém mantendo as demais conexões com o fluxo esperado. |
| Expandir | ||
|---|---|---|
| ||
Incidente: Access violation gerado em um json durante uma exceção tratável, especialmente se for json inline. Solução: O servidor de aplicação fez o tratamento para que um comportamento inesperado do objeto json não gere uma inoperância do servidor. Referente ao chamado: DTAPPSRV-9178 |
| Expandir | ||
|---|---|---|
| ||
Incidente: Em um fonte PRW, declarar duas variáveis como char / character, e tentar somá-las , sendo que AMBAS as variáveis possuem valor nulo (NIL), causava o término anormal do Serviço do TOTVS Application Server, com a ocorrência crítica "Access Violation". Correção: O comportamento do operador de soma tipado já considerava variáveis com conteúdo NIL como uma string em branco. Desse modo, a soma de duas variáveis tipadas como string com conteúdo NIL retornará uma string em branco. |
| Expandir | ||
|---|---|---|
| ||
Incidente: Problemas durante aplicação de patch e desfragmentação do RPO. Solução: Foi ajustado um tratamento de validação de duplicidade de recursos que estava mantendo o rpo aberto. |
| Expandir | ||
|---|---|---|
| ||
Incidente: Inconsistência no comportamento do ErrorBlock ao tratar erros de utilização do método SET da classe tHashMap Solução: Foi inserida uma correção no código para que erros envolvendo a utilização dos métodos SET, GET, DEL e LIST da classe tHashMap sejam tratados conforme esperado pelo ErrorBlock. |
| Expandir | ||
|---|---|---|
| ||
Ocorrência: Mensagem "FATALSERVER Cannot update a constant string" gerada no console.log do Application Server, com uma pilha de chamadas interna indicando a chamada TOP_LITE_TCSetParam. Correção: Foi realizado o tratamento adequado do parâmetro recebido na função TCSetParam (https://tdn.totvs.com/x/4bclE |
Melhorias
...
| Expandir | ||
|---|---|---|
| ||
Incidente: Configurar o protocolo máximo suportado pelo servidor REST, devido à restrição de comunicação com alguns servidores. Solução: Criada a chave SSLMaxMethod para o REST, que aceita os mesmos valores da chave SSLMethod. |
| Expandir | ||
|---|---|---|
| ||
Incidente: Implementar suporte ao protocolo IPv6 nos serviços portal multiprotocolo, REST 2.0 Solução: Criada a possibilidade de ativar o protocolo IPv6 nos serviços de REST 2.0 e portal multiprotocolo (MPP). Vide documentação: https://tdn.totvs.com/x/wwmeCQ |
| Expandir | ||
|---|---|---|
| ||
Incidente: Se dois ou mais fontes definissem, via annotation, um endpoint Rest com a mesma URL, isso poderia causar uma subida parcial dos serviços de Rest. Por exemplo, um fonte x.tlpp definia @Get("/test/resource") e um fonte y.tlpp também poderia definir o mesmo @Get("/test/resource"). Solução: Foi realizado um tratamento em tempo de compilação, que sempre observa se alguma URL de Rest, definida via annotation, já existe. Se já existir, a compilação desse fonte causa erro, alertando sobre a duplicidade. Com isso, se no repositório já existir um endpoint @Get("/test/resource") e um novo fonte tentar definir o mesmo @Get("/test/resource"), isso causará erro de compilação. Referente ao chamado: DTAPPSRV-8463 |
| Expandir | ||
|---|---|---|
| ||
Solicitação: Existir na classe TXMLManager uma forma de retornar quantos elementos existem em um certo grupo. Solução: Criado o método XPathElementCount, que retorna a quantidade de nós com o mesmo nome apontado por uma expressão XPath. |
| Expandir | ||
|---|---|---|
| ||
Solicitação: Foi solicitado a criação de métodos na classe TXMLManager para navegação baseado numa expressão XPath. Solução: Criado o metodo XPathSetPostion na classe TXMLManager, que posiciona o objeto de acordo com a expressão XPath. Referente ao chamado: DTAPPSRV-8724 |
| Expandir | ||
|---|---|---|
| ||
Solicitação: ocorrência de "efeito manada" se muitos usuários se conectassem ao mesmo tempo (num intervalo de 5 segundos ou pouco mais) no ERP via broker, causando sobrecarga de memória no servidor que estivesse mais disponível para balanceamento Solução: foi adicionado um "peso" a cada nova conexão a um servidor, de modo que mesmo se muitos usuários se conectam "ao mesmo tempo" ao ERP via broker não ocorrem mais distorções no balanceamento. |
| Expandir | ||
|---|---|---|
| ||
Solicitação: O arquivo de diagnostics.json não estava salvando as informações sobre o tipo da build utilizada. Solução: Foi inserido no arquivo diagnostics.json as informações sobre o tipo da build utilizada (RELEASE, REL WITH DEBUG ou DEBUG). |
| Expandir | ||
|---|---|---|
| ||
Solicitação: Visualizar informação de inicialização do Application Server secundário na tela de status do Broker. Solução: Foi alterada a apresentação de dados da tela de status do Broker e foram incluídas as informações de horário em que o serviço foi ativado (uptime) e a informação do identificador do processo do serviço (pid) para facilitar na identificação de múltiplos serviços ativados no mesmo host físico. |
| Expandir | ||
|---|---|---|
| ||
Solicitação: Exibir data e hora na qual o serviço (Application Server) entrou em quarentena. Solução: Foi alterada a apresentação de dados da tela de status |
...
Correções
Melhorias
...
do Broker e foi removida a informação de próximo horário de monitoria de serviço em quarenta e no lugar foi incluída uma coluna que informa o horário de início de detecção de falha do serviço ("horário de entrada em quarentena"). |
| Expandir | ||
|---|---|---|
| ||
Incidente: Usuários perdem conexão com ERP em caso de queda do Broker HTTP. Solução: Implementada uma funcionalidade opcional no Broker HTTP, que em caso de queda reinicia automaticamente o broker, de modo que os usuários não perdem conexão com o ERP. Vai aparecer uma janelinha popup amarela de reconexão (nativa do Smartclient Webapp), mas rapidamente o browser se reconecta na nova instância de broker que foi iniciada, e o usuário pode voltar a trabalhar normalmente. |
| Expandir | ||
|---|---|---|
| ||
Solicitação: Dificuldade de identificar rollback de transações nas aplicações do AppServer em AdvPL, principalmente quando a aplicação largou equivocadamente uma transação aberta, e é realizado um rollback implícito no final da thread. Solução: Criado mecanismo de rastreio de transações, habilitado pela configuração TRACETRANSACTION no environment desejado no appserver.ini. Para maiores informações, consulte a documentação da configuração TRACETRANSACTION no TDN |
| Expandir | ||
|---|---|---|
| ||
Solicitação: Incluir mais informações no nome do arquivo de dump gerado pelo AppServer, seja configurado como Broker ou como AppServer. Solução: Padronizado o nome do arquivo de dump para PREFIX_VERSION_BUILDTYPE_YYYYMMDD_hhmmss_THREADID_PID, onde PREFIX pode ser "core" ou "broker" e BUILDTYPE pode ser "dbg", "relwithdbg", "rel". |
| Expandir | ||
|---|---|---|
| ||
Solicitação: Após sinalizar a finalização do appserver, seja com control+c ( console ) ou stop ( service manager ), se ocorrer um access violation durante a parada do serviço, era gerado um core dump completo no disco, ocupando relevante espaço e dando a falsa impressão que o serviço estaria caindo enquanto estava em uso. Solução: Para evitar isso, não será mais gerado core dump após o serviço ser finalizado. Caso ocorra um Access Violation durante a finalização do serviço, será apenas mostrando no log de console a mensagem "*** THREAD <nnnnnn> - CRASH DURING APPSERVER SHUTDOWN ***" |
| Expandir | ||
|---|---|---|
| ||
Solicitação: Aplicações e rotinas AdvPL usando XMLPARSER e/ou XMLPARSERFILE, sem chamar a função DelClassintf() ao final da execução, geram aumento de memória da thread. Solução: Criada a configuração TRACEXMLPARSER=1, para ser colocada no appserver.ini, no environment em uso, para rastrear a criação de objetos XML com as funções acima, e informar se esses objetos não foram limpos no final da aplicação. Para maiores detalhes, consulte no TDN a documentação da configuração TRACEXMLPARSER. |
| Expandir | ||
|---|---|---|
| ||
Solicitação: Descontinuação do driver CTREE Server e CTREE BoundServer Solução: Remoção das bibliotecas CTREE do pacote do Application Server. Detalhes em: https://tdn.totvs.com/x/BtwNOw |
| Expandir | ||
|---|---|---|
| ||
Solicitação: As informações registradas em console com a configuração ServerMemoryInfo=1 eram mostradas em KB, com 3 dígitos decimais, induzindo a erros de leitura. Solução: As informações passam a ser mostradas em MegaBytes (MB), com 2 dígitos decimais, para todos os contadores de memória. |
| Expandir | ||
|---|---|---|
| ||
Ocorrência: O kernel UEK do Oracle Linux não é homologado/suportado pelo AppServer e pode causar diversos problemas, por exemplo, quedas, lentidão, entre outros. Referente ao chamado: DTAPPSRV-9251 |
| Expandir | ||
|---|---|---|
| ||
Solicitação: Implementar mensagem de descontinuidade do CTREE SERVER e BOUND SERVER no uso das chaves CTREEMODE Solução: No momento da leitura das chaves CTreeMode (Seção General) e as seções ctreeServer, ctreeMaster, será exibida mensagem de descontinuidade desta funcionalidade, conforme documentação: https://tdn.totvs.com/x/BtwNOw |
| Expandir | ||
|---|---|---|
| ||
Solicitação: Remover a limitação do tamanho das listas retornadas pela TCGetInfo(). Solução: Fizemos um ajuste no DBAccess 24.1.1.0 (https://tdn.totvs.com/x/Qf4gO |
| Expandir | ||
|---|---|---|
| ||
Incidente: Implementar uma forma de indicar quais tipos de conexões a TCQuit deve encerrar Solução: Fizemos uma mudança na TCQuit que agora pode receber um novo parâmetro numérico para determinar seu comportamento. Ajuste na TCQuit... Agora ela pode receber uma parâmetro numérico para determinar o comportamento de desconexão das threads! 0 = encerra todas as conexões Essa implementação depende do uso do DBAccess 24.1.1.0 ou superior. |
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas