Dede a chegada do Magic xpi versão 4, agora integrado ao GigaSpace (XAP 9.1.2) – uma plataforma ‘cloud ready’ para aplicações (In-Memory DataGrid, Big Data, Clusters, etc…) – algumas novidades relativas a configurações passaram a exigir nossa atenção.
( veja este post sobre o Magic xpi 4 )
Estas novidades ficam principalmente por conta do IMDG (In-Memory Data Grid) do GigaSpace.
Leiaute do IMDG
O IMDG do GigaSpace é formado por unidades chamadas SPACE.
Quando instalamos o Magic xpi versão 4, um novo monitor (GigaSpaces UI) está disponível exclusivamente para o GigaSpace:
Com ele veremos (entre outras coisas) que o default da instalação são 4 SPACEs: 2 primários (verdes) e 2 de backup (azuis):
Estas configurações podem ser alteradas. Em ambientes de desenvolvimento, por exemplo, podemos querer uma quantidade menor de SPACEs para economizar recursos (memória basicamente). Por exemplo:
Se editarmos o arquivo ‘magicxpi_sla.xml’ que fica na pasta ‘%xpi_home%\config’, e mudarmos o atributo “number-of-instances” para 1:
Se além disso também alterarmos o atributo “number-of-backups” para 0:
E editarmos o arquivo ‘magicxpi-gs-agent.bat’ que fica na pasta ‘%xpi_home%\GigaSpaces\bin’, diminuindo o número de contêiners GSA para 1:
Ao iniciarmos o GigaSpace o IMDG será montado com 1 SPACE (1 principal e nenhum backup) apenas:
Além disso, podemos ajustar a quantidade de memória RAM requerida por cada elemento dos SPACEs, através do arquivo ‘magicxpi-gs-agent.bat’:
Mas ATENÇÃO:
Os valores configurados no arquivo ‘magicxpi-gs-agent.bat’ e no arquivo ‘magicxpi_sla.xml’ são relacionados entre si. Se eles forem definidos de forma inconsistente, o status final da PU Magic será definido como ‘Compromised’ (comprometido):
Neste caso, nenhum projeto Magic xpi iniciará a sua execução. Os projeto só iniciam quando o status final estiver definido como ‘Intact’ (intacto):
Veja Exemplo:
Time-Out de Início Automático
Como vimos na apresentação do novo Magic xpi ( veja este post sobre o Magic xpi 4 ), o arquivo ’projectsStartup.xml’ que fica na pasta ‘%xpi_home%\config‘ define a lista de projetos que deverão iniciar automaticamente sempre que o serviço do GigaSpace (Magic xpi 4.0 GSA) for iniciado. Este arquivo substitui a função do arquivo ‘mgrb.ini’ na antiga arquitetura do Magic Broker (xpi 3 e anteriores). Contudo, os projetos Magic xpi só podem iniciar após o IMDG do GigaSpace estar totalmente montado. Isso pode demorar alguns minutos, especialmente em hardwares com menos recursos (RAM & processador).
Por isso existe uma configuração de Time-Out representando o tempo máximo que a PU Magic vai aguardar pela disponibilidade do IMDG. Esta configuração fica no arquivo ‘mgdeploy.xml’, na pasta ‘%xpi_home%\GigaSpaces\config\gsa’:
O valor default da instação é 120s, o que significa que a PU Magic aguardará até 2 minutos pela disponibilidade completa do IMDG, no momento em que está iniciando os projetos de forma automática:
Este valor pode precisar ser aumentado, especialmente em máquinas com hardware mais limitado.
Time-Out de Requisições HTTP
O requester do Magic xpi versão 4 é agora uma aplicação .NET (MgWebRequester.dll):
O Time-Out para as chamadas externas HTTP, aquelas para invocar fluxos que possuem trigger HTTP, está agora localizado no arquivo ‘mgreq.ini’ na pasta ‘%xpi_home% \scripts\config’, com o nome de ‘RequesterTimeoutSec’ na seção ‘[REQUESTER_ENV]’:
O valor default da instação é 30s. No Magic xpi versão 4, se o fluxo demorar mais para retornar a resposta, do que o tempo configurado aqui, o retorno será um erro HTTP 500.0:
