Script para iniciar o tomcat

O tomcat costuma apresentar um problema chamado PermGen space Exception quando fazemos muitos undeploys e deploys sem reiniciar o processo do tomcat. Isso acontece por uma característica da jvm da Sun. Não chega a ser propriamente um bug.

Quando executamos uma aplicação java uma instância da jvm é criada exclusivamente para aquela aplicação. Na jvm existe um espaço de memória que nunca é reutilizado. Se chama espaço de memória permanente (PermGen space) e serve para guardar objetos do tipo Class. Quando se carrega uma aplicação, cada casse do jar ou war é instanciado como um objeto que fica alocado neste espaço de memória permanente. Se a aplicação tiver muitíssimas classes a jvm vai lançar uma mensagem de erro indicando que esse espaço está repleto e não é possível carregar a aplicação. Mas se as suas classes se encaixarem neste espaço (e em geral cabe) sua aplicação vai rodar sem problemas. Existem dois tipos de casos onde existe um consumo indevido do espaço de memória permanente:

  1. Programas que geram tipos de classe dinamicamente. O hibernate chega a criar algumas classes em tempo de execução, mas não chega a ser um número tão grande a ponto de gerar problemas. Para encher o espaço de memória permanente seria necessário criar centenas ou milhares de classes dinamicamente. Provavelmente um sistema que roda por muitos dias seguidos e criando classes novas possa chegar preencher todo este espaço. Mas seria um sistema mau escrito.
  2. Programas que carregam muitos tipos de classes dinamicamente. É o caso do tomcat que aceita deploy e undeploy de aplicações. Quando um desenvolvedor faz undeploy todos os objetos das classes da aplicação continuam lá no espaço de memória permanente e quando é feito o deploy da nova versão do context outros tantos objetos do tipo classe vão para a memória permanente. Em algum momento a memória acaba.

É por isso que no ambiente de desenvolvimento é comum ter de reiniciar o tomcat várias vezes ao longo do dia de trabalho. Como meu ambiente é para testes, eu limpo logs e o diretório work antes de rodar o tomcat, e coloco o tomcat.log que é o arquivo do log4j que eu configurei para exibir as mensagens do tomcat. Segue abaixo o meu script para iniciar o tomcat:

#!/bin/sh
TOMCAT_HOME="/opt/tomcat"
TOMCAT_LOGFILE="$TOMCAT_HOME/logs/tomcat.log"

cd $TOMCAT_HOME
rm logs/* -rf
rm work/Catalina/localhost/* -rf
bin/catalina.sh jpda start
ps aux|grep tomcat
echo "tomcat iniciado..."

sleep 5

while [ ! -f "$TOMCAT_LOGFILE" ]; do
sleep 1
echo "arquivo de log ainda não foi criado..."
done

echo "log do tomcat existe e será exibido a seguir:"
tail -f logs/tomcat.log

Quando a distribuição sugere pacotes incompatíveis

Distribuições linux trazem um conjunto de coeso de componentes de sistema operacional e assessórios que juntos funcionam sem que haja conflitos. Ou pelo menos na teoria é assim.

Por acaso passei pelo mesmo problema duas vezes em menos de 24h. Primeiro ao instalar o tomcat no ubuntu 6.10 que opero na Assembléia, e hoje ao instalar o mesmo tomcat em um servidor Suse.

Ambas distribuições sugerem o uso do tomcat 5.0.30, mas quando se instala as ferramentas de administração do tomcat, o admin simplesmente não roda devido a uma incompatibilidade entre o struts da distribuição e os arquivos de configuração do admin. Em outras palavras: o sistema recomenda um struts incompatível com a recomendação do admin do tomcat.

Solução? Fazer como qualquer mortal faria, baixando o tomcat estável (5.0.28) do site da apache, que vem com o strutus adequado, processo relativamente tranquilo e rápido, apesar de não manter o santo padrão das distribuições (diretórios, autorizações…).

Agora, quando me argumentarem que tomcat só se instala em servidor com os YaSTs e apt-gets, posso dizer por experiência própria que nem sempre é o melhor.

Por último, para quem ainda não se convenceu: quando vou instalar o tomcat no SUSE o YaST sugere que se instale o java open source. Resultado: incompatibilidade com vários códigos java. Solução: instalar outro pacote do SUSE com o java da sun…

E se você só usa a tal distribuição só porque lhe garantiram que era a distribuição mais estável e que usar outra distribuição vai contra a política da empresa? Bem, daí só resta ficar resmungando nos blogs afora :-/

Kubuntu Linux

Kubuntu é uma variação da distribuição Ubuntu do sistema operacional Linux. Assim como o Kurumin, o Kubuntu se baseia na distribuição Debin, que apesar de ter um esquema de atualização de programas excelentes pelo apt-get, é muito difícil de ser utilizado por um leigo – a instalação é impossível de ser executada por um usuário normal.

O Kubuntu surge como uma proposta de Debian para todos, independentemente do skill. A diferença entre o Ubuntu e o seu irmão, o Kubuntu, é a interface. O Ubuntu utiliza o Gnome, enquanto o Kubuntu o Kde.

Ambos vêm em versão live CD, que prescinde instalação, e a versão para instalar no disco rígido.

Há ventagens e desvantagens em relação ao brasileiro Kurumin. A desvantagem é que no Kubuntu – e também no Ubuntu – a instalação deve ser feita em modo texto – no Kurumin a instalação é gráfica, a partir do Live CD. E como o Kubuntu é internacional, é necessário informar seu idioma, país e layout de teclado, opções que o Kurumin já vem “de fábrica”. A vantagem, que ao meu ver foi decisiva em favor do Kubuntu, é que o Kubuntu é feito sobre a versão em teste do Debian, e não sobre a versão instável, como o Kurumin faz. Isso significa que o Kurumin a longo prazo tende a ser mais instável que o Kubuntu. Além do mais o Kubuntu também faz uma distinção entre os programas testados pelo Kubunutu, e supostamente mais estáveis que os demais, e os demais programas que não passaram por uma bateria de testes.

Para quem usa linux enquanto SO de estação de trabalho e para servidor de homologação de sistemas, eu recomendo o Kubuntu, por aliar a versatilidade do Debian e a facilidade de uso.