MySphere Posts

O tamanho do log de um servidor pode crescer muito dependendo do processamento que a máquina tem. Logs de roteamento, sessões e outros eventos.
O log muito grande pode impactar a performance e também ficar difícil de fazer análise.  O TN 1366598 mostra como filtrar um tipo de evento mas podemos usar o mesmo processo para filtrar diversos eventos. Em um servidor que estou trabalhando eram gerados 4 documendos de log por segundo.
Depois de configurar alguns filtros agora temos um documento de log a cada 10s.

Encontramos um problema quando executamos a tarefa de transferir bancos de dados no Portal Express. O problema é relacionado ao serviço do Windows.
A solução é desabilitar o serviço que inicia tanto o server1 quanto o WebSphere Portal e executar a transferência.

O trace do erro segue abaixo:

action-stop-server:
   [logmsg] 2009.07.28 10:05:52.645 action-stop-server      
   [logmsg]   EJPCA3166I: Stopping Server “server1”

Tue Jul 28 10:05:53 BRT 2009
Target started: iseries-switch-back

iseries-switch-back:
Target finished: iseries-switch-back
     [exec] ADMU7702I: Because server1 is registered to run as a Windows Service, the
     [exec]            request to stop this server will be completed by stopping the
     [exec]            associated Windows Service.
     [exec] ADMU0116I: Tool information is being logged in file
     [exec]            D:ibmWebSphereprofileswp_profilelogsserver1stopServer.log
     [exec] ADMU0128I: Starting tool with the wp_profile profile
     [exec] ADMU3100I: Reading configuration for server: server1
     [exec] java.lang.reflect.InvocationTargetException
     [exec]         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     [exec]         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
     [exec]         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
     [exec]         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
     [exec]         at java.lang.reflect.Method.invoke(Method.java:391)
     [exec]         at com.ibm.ws.bootstrap.WSLauncher.run(WSLauncher.java:219)
     [exec]         at java.lang.Thread.run(Thread.java:570)
     [exec] Caused by: com.ibm.websphere.management.exception.AdminException: ADMU7705E: Failed while trying to stop the Windows Service associated with server: server1;
     [exec] probable error executing WASService.exe: com.ibm.ws.management.tools.ProblemInWASServiceException: ADMU7711E: Unexpected exception associated with WASService.exe: exitCode = -1 during processing of server with name: server1
     

Hoje novamente o desafio é descobrir porquê dois servidores Domino 8.5 estão corrompendo bancos de dados. Os servidores estão em cluster e aleatóriamente estão corrompendo bancos de dados. Abrimos um suporte na IBM para ajudar a investigar o caso. Algumas hipóteses foram levantadas pelo suporte e uma delas foi sobre fragmentação de disco.
Em servidores Windows isto sempre foi problema devido ao sistema de arquivos NSF e uma desfragmentação de vez em quando é sempre boa.
Mas no ambiente Linux/Unix acho que não é um grande problema, visto que não achei uma ferramenta de defrag para Linux. Procurando no Google achei este artigo que explica porquê o Linux/Unix não fragmenta arquivos tão facilmente.

Achei no youtube muito legal é uma propaganda mas é bem legal

http://www.youtube.com/watch?v=m9Et7UQh1tg

Recentemente tenho enfrentado alguns problemas com recepção de correio de outras empresas. As causas são diversas desde correio com endereço errado, hosts encontrados em black lists e problemas de DNS.
O maior problema que tenho visto é a má configuração de DNS por parte dos “remetentes” ou seja DNS MAL CONFIGURADO.
No primeiro momento fico indignado em saber e sofrer com a pressão de uma grande empresa não conseguir enviar e-mail para nosso domínio. O problema é sempre MEU nunca do “remetente”. Fica sempre a briga entre Meus usuários, eu e o grande cliente, traduzindo a briga entre O ROCHEO E O MAR, quem sai perdendo? O MARISCO no caso eu.
Depois de pensar sobre o assunto fiz uma pesquisa sobre estas questões de DNS  e fiquei espantado com o que andei encontrando.
Lendo alguns artigos descobri que o registro PTR para servidores de correio não é OBRIGATÓRIO e que 80% dos DNS’s na internet tem algum problema de configuração, então descobri  o motivo de vários hosts não conseguirem transmitir correio para o meu domínio. Resolvi então retirar a verificação do PRT (resolução de nome reversa).
Estarei observando o comportamento dos  usuários a medida que reclamações devem diminuir
Achei este artigo interessante http://www.saas.nsw.edu.au/solutions/dns.html e que explica como tudo funciona.

Fazer um tema para o WebSphere Portal é um desafio dependendo dos requisitos, normalmente do pessoal do marketing. São menus dinâmicos, um monte de CSS imagens etc. Outro problema é fazer o tema funcionar em vários browsers (nada de diferente para aplicativos comuns em ambiente web).
O difícil é ficar contornando bugs principalmente do nosso amigo IE7. Um bug conhecido é a forma como o IE7 interpreta o CSS quando queremos um layout centralizado, muito comum hoje. Desde o meu primeiro projeto com Portal 6 tive de implementar um layout assim só que os browsers onde testei o código eram IE6 e Firefox 2.0.
Novamente nosso time teve de fazer um tema com layout centralizado e tudo estava indo bem até os testes com IE7. O tema ficava correto no IE6,IE8,Firefox 2.x ,3.0 e 3.5 mas no IE7 ele ficava sempre a esquerda.

Solução:

1 – Editar o default.jsp do tema utilizado e colocar uma tag DIV após o BODY e antes da DIV id=FLYParent> como exemplo DIV CLASS=”NOME DA CLASSE”
e fechar esta DIV após o /BODY. O que isto faz é colocar a página do portal dentro de uma DIV

2 – Criar a referência desta DIV no styles-theme.jspf da forma como está abaixo

.NOME DA CLASSE {
background-color:#FFFFFF;
height:100%;
margin:0 auto;
padding:0;
width:940px;
}

3 -Formatar a id FLYParent com os seguintes itens, no mesmo arquivo:
#FLYParent {
background-color:#FFFFFF;
float:left;
width:940px;
}

Até aqui tudo certo conforme achei pesquisando na Web este contorno para o bug, mas somente centralizou no portal depois que foi feito o seguinte:

Acrescentar uma imagem (veja abaixo (neste caso ela está em branco pq o fundo é branco) na pasta do tema em colors/default/

Referenciar esta imagem no styles-theme.jspf da seguinte forma e acrescentar os itens caso não tenha:
body {
background:#FFFFFF url(./colors/default/fullBackground.jpg) repeat-y scroll center top;
color:#FFFFFF;
margin:0;
padding:0;
}

Editar body, html também da seguinte forma no mesmo styles-theme.jspf:
body, html {
height:100%;
margin:0;
padding:0;
width:100%;
}

Pronto!! Créditos para o Vinicius Afonso que trabalhou comigo para contornar este problema.