Configurações no Magic xpi 4 (agora com GigaSpace)

Configurações no Magic xpi 4 (agora com GigaSpace) – Revisado

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:

Imagem_001

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):

Imagem_002

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:

Imagem_003

Se além disso também alterarmos o atributo “number-of-backups” para 0:

Imagem_004

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:

Imagem_006

Ao iniciarmos o GigaSpace o IMDG será montado com 1 SPACE (1 principal e nenhum backup) apenas:

Imagem_007

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’:

Imagem_008

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):

Imagem_009

Neste caso, nenhum projeto Magic xpi iniciará a sua execução. Os projeto só iniciam quando o status final estiver definido como ‘Intact’ (intacto):

Imagem_010

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’:

Imagem_011

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:

Imagem_012

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):

Imagem_013

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]’:

Imagem_014

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:

Imagem_015

Manoel Frederico - Gerente de Produto e Magic Evangelista

Manoel Frederico – Gerente de Produto e Magic Evangelista

Novo Comentário