Skip to end of metadata
Go to start of metadata

               Esta página tem o objetivo de documentar (assim ajudando a organizar) o processo de testes sendo realizado a fim de simplificar o processo de Build e empacotamento do SGA do CSGrid BGCSGRID-45 - Getting issue details... STATUS e unificar esse processo independente do sistema operacional utilizado. Cada subpágina conterá um teste realizado, que terá nela descritos seu contexto, suas premissas e seus resultados. Torna-se necessário nesta página dar o contexto geral em que se encontravam os testes antes da realização do primeiro teste aqui documentado.

                O processo de Build e empacotamento do SGA ocorre por meio de um conjunto de scripts shell que nos foi dado pelo LabLua, que consiste em um script para instalação do CSGrid, e outros três, que servem para executar Servidor, Cliente e SGA individualmente (tudo no mundo CSGrid). Eles utilizam sintaxe de terminais Unix, e requerem Cygwin para uso em SO Windows.

                Os testes a ser realizados envolvem testar por diferentes sistemas operacionais, em diferentes máquinas, com combinações diferentes de máquina host de Servidor,  Cliente e SGA (por exemplo, pode-se executar todos os três na mesma máquina, como se pode também deixar somente o SGA em uma e Servidor e Cliente em outra, cada uma com seu sistema operacional distinto etc.) tanto instalação quanto execução do CSGrid via os scripts. Eu (Bernardo Alkmim) testo em duas máquinas esse processo:

Meu Notebook pessoal

Sistema Operacional: dual boot Windows 8.1/Ubuntu 14.04, ambos 64 bits

Plataforma do arquivo de configuração do SGA sgad-cnf.lua: Linux26g4_64

Versão do Cygwin: 2.871 (64 bits)

 

O Desktop no Tecgraf (máquina Ingleses)

Sistema Operacional: dual boot Windows 7/Ubuntu 14.04, ambos 64 bits

Plataforma do arquivo de configuração do SGA sgad-cnf.lua: Linux26g4_64

Versão do Cygwin: 2.871 (64 bits)

                Vale notar que ambos se encontram na rede Tecgraf (o Desktop via cabo Ethernet e o Notebook via Wi-fi) quando os testes são realizados e conseguem acessar um ao outro via ping.

                Do script utilizado, Servidor pode rodar tanto em Linux quanto em Windows (sem-pre que Windows for mencionado para esse problema, será via Cygwin) sem problemas. Já o Cliente encontra problemas para ser executado em Windows, apesar de funcionar corretamente em Linux, mas como o Cliente é secundário ante o SGA, ele foi deixado de lado. Assim, tanto Servidor quanto Cliente são utilizados, para fins de teste do script do SGA, como sempre foram normalmente: utilizando os executáveis disponíveis internamente no EngDist, sem utilizar os scripts. Isso diminuiu um pouco a amplitude do problema: agora o objeto a ser testado é o script de execução do SGA. Também foi visto que o script do SGA funcionava corretamente em Linux (ele se conectava corretamente, se registrava no Servidor, e executava um Algoritmo que o Cliente pedia sem problemas). Há somente um erro, mas que não impede a execução do SGA em si, portanto optamos por ignorá-lo por enquanto (pelo menos a nível dos testes de execução): ele ocorre por utilizarmos o comando top para leitura dos processos de uma máquina (procedimento realizado periodicamente pelo SGA na máquina onde ele está executando), o que faz com que o parser das informações dos processos nem sempre funcione, posto que versões diferentes de Linux apresentam os processos via top em ordem diferente  (no LabLua, estão procurando mudar essa parte para verificar processos no diretório /proc/, que se mantém o mesmo independentemente da versão do SO).

                Com isso, o foco se direcionou para o script do SGA em Windows, que ainda apresenta diferentes erros, o principal sendo uma falha de registro do SGA no Servidor que só ocorre em ambiente Cygwin (debugamos várias vezes os logs de execução do SGA e encontramos erros de CORBA, alertando de não indicação de canal bidirecional de comunicação entre Servidor e SGA). Decidiu-se que esse erro deveria ser ignorado (e a parte do código que o gera devidamente comentada) para que o teste prosseguisse e focássemos em outras partes da execução desse script. Ele está agora nas mãos dos responsáveis por outros projetos do grupo, que têm mais contato com esses erros de comunicação de CORBA. Segue o log do Servidor quando ocorre o erro:

SEVERE: 07/10/2015 13:53:07 csbase.server.services.sgaservice.SGAService.registerSGA(SGAService.java:1762) 
--- Falha de registro de SGA: SGABernardo. class csbase.server.ServerException: Falha na comunicação com o SGA: SGABernardo
Exceção: csbase.server.ServerException - Falha na comunicação com o SGA: SGABernardo
  em csbase.server.services.sgaservice.SGA.<init>(SGA.java:1221)
  em csbase.server.services.sgaservice.SGAService.registerSGA(SGAService.java:1718)
  em csbase.server.services.sgaservice.SGAHandler.registerSGA(SGAHandler.java:100)
  em sgaidl.SGAManagerPOA._invoke(SGAManagerPOA.java:107)
  em org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:402)
  em org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:726)
  em org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:884)
  em org.jacorb.orb.giop.ReplyPlaceholder.getInputStream(ReplyPlaceholder.java:127)
  em org.jacorb.orb.ReplyReceiver.getReply(ReplyReceiver.java:388)
  em org.jacorb.orb.Delegate._invoke_internal(Delegate.java:1403)
  em org.jacorb.orb.Delegate.invoke_internal(Delegate.java:1171)
  em org.jacorb.orb.Delegate.invoke(Delegate.java:1159)
  em org.omg.CORBA.portable.ObjectImpl._invoke(null:-1)
  em sgaidl._SGADaemonStub.ping(_SGADaemonStub.java:234)
  em csbase.server.services.sgaservice.SGA.<init>(SGA.java:1217)
  em csbase.server.services.sgaservice.SGAService.registerSGA(SGAService.java:1718)
  em csbase.server.services.sgaservice.SGAHandler.registerSGA(SGAHandler.java:100)
  em sgaidl.SGAManagerPOA._invoke(SGAManagerPOA.java:107)
  em org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:402)
  em org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:726)
  em org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:884)
Causada por: org.omg.CORBA.COMM_FAILURE -
  em org.jacorb.orb.giop.ReplyPlaceholder.getInputStream(ReplyPlaceholder.java:127)
  em org.jacorb.orb.ReplyReceiver.getReply(ReplyReceiver.java:388)
  em org.jacorb.orb.Delegate._invoke_internal(Delegate.java:1403)
  em org.jacorb.orb.Delegate.invoke_internal(Delegate.java:1171)
  em org.jacorb.orb.Delegate.invoke(Delegate.java:1159)
  em org.omg.CORBA.portable.ObjectImpl._invoke(null:-1)
  em sgaidl._SGADaemonStub.ping(_SGADaemonStub.java:234)
  em csbase.server.services.sgaservice.SGA.<init>(SGA.java:1217)
  em csbase.server.services.sgaservice.SGAService.registerSGA(SGAService.java:1718)
  em csbase.server.services.sgaservice.SGAHandler.registerSGA(SGAHandler.java:100)
  em sgaidl.SGAManagerPOA._invoke(SGAManagerPOA.java:107)
  em org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:402)
  em org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:726)
  em org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:884)

 

                O outro erro que ocorre apenas no Desktop, mas não no Notebook (ainda no Windows apenas) é um que alerta que o SGA não consegue obter informações da máquina em que se encontra, e isso trava o teste. O objetivo agora é ver quais direfenças existem entre os pacotes e ambientes tanto do Notebook quanto do Desktop que geram tal diferença. O mais provável é que tenha sido feita alguma mudança em algum dos arquivos de configuração do SGA do Notebook (para consertar algum bug de execução anterior) e não foi documentada. Segue parte do log do SGA que menciona a falha na obtenção:

07/10/15 13:55:21 [error]     ERRO (ingleses): Error while retriving configuration for the following keys :
 [csbase_load_perc, csbase_memory_ram_free, csbase_memory_swap_free].
07/10/15 13:55:21 [error]     ERRO (ingleses): Erro ao obter o percentual de carga do processador.
07/10/15 13:55:21 [error]     ERRO (ingleses): Erro ao obter a quantidade de mem▒ria livre.
07/10/15 13:55:21 [error]     ERRO (ingleses): Erro ao obter a quantidade de mem▒ria virtual livre.

 

                Tendo em vista as falhas existentes em arquivos fonte do Build do SGA, nos foi enviada uma nova versão do pacote dos scripts para retomarmos os testes a partir daí.

  • No labels