Durante anos, trabalhar com arquivos em Java foi muito trabalhoso. Precisávamos conhecer e interagir com diversas classes do pacote java.io a fim de realizar tarefas simples, como ler um arquivo ou simplesmente copiá-los de uma pasta para outra. Alguns projetos open source sugiram para facilitar essas tarefas, como o Commons-IO da Apache.

Conforme a linguagem foi evoluindo, estas tarefas foram se tornando mais fáceis de serem realizadas sem a necessidade de bibliotecas externas, graças aos recursos incorporados na API padrão. Vamos acompanhar como foi parte dessa evolução, usando o exemplo de copiar uma árvore de diretórios.

A seguir, vemos a árvore de diretórios que iremos copiar:

É uma arvore de arquivos comum. Antes de copiar a árvore inteira, vamos ver o código para copiar um arquivo sozinho:

// Arquivos que iremos copiar
File origem = new File("/home/caelum/Java/vraptor.zip");
File destino = new File("/home/caelum/Java/vraptor-copia.zip");

// abrimos os streams para leitura/escrita
FileInputStream fis = new FileInputStream(origem);
FileOutputStream fos = new FileOutputStream(destino);

// Obtém os canais por onde lemos/escrevemos nos arquivos
FileChannel inChannel = fis.getChannel();
FileChannel outChannel = fos.getChannel();

// copia todos o conteúdo do canal de entrada para o canal de saída
outChannel.transferFrom(inChannel, 0, inChannel.size());

// fecha os streams/channels usados...

Cada FileInputStream/FileOutputStream recebe um objeto do tipo File, que representa o local do arquivo no disco. Após isso criamos canais por onde copiaremos o conteudo do arquivo de origem para o de destino. Usar FileChannels para realizar a cópia pode ser bem mais eficiente do que se lessemos/escrevessemos utilizando os antigos streams diretamente. Essa API não-blocante foi adicionada ao Java 1.4, em 2001.

Para copiar a estrutura de diretórios é muito mais simples, basta chamar o método mkdirs da classe File, que cria o diretório e toda a árvore necessária:

File novoDiretorio = new File("/home/caelum-copia/Java");
novoDiretorio.mkdirs(); //cria o diretório "caelum-copia" e o diretório "Java" dentro da pasta /home/

Mas isso só cria o diretório vazio, sem nenhum arquivo dentro. Para copiar o conteúdo, primeiro precisamos saber o que há dentro dele, para isso usamos o método File.listFiles, que nos retorna um array com todas as entradas do diretório, tanto arquivos quanto subdiretórios:

File raiz = new File("/home/mario/Documents/caelum/Java");
File[] files = raiz.listFiles();

for (File file : files) {
  // copia os arquivos / subdiretórios
}

Precisamos repetir esta operação para cada subdiretório encontrado. A melhor solução neste caso é realizar uma invocação recursiva para copiar o conteúdo de cada subdiretório encontrado.

public void copiarArquivos(File origem, File destino) {
    // verifica se estamos tentando copiar um diretório
    if (origem.isDirectory()) {
      File[] files = origem.listFiles();

      for (File file : files) {
        // invocacao recursiva de cada item de dentro do diretorio
        copiaArquivos(file, destinoEquivalente);
      }
    } else {
      // copia o arquivo usando os streams/channels
    }
}

Juntando tudo que vimos até aqui, temos um método de cópia de diretórios. Não é um código simples, pois além de usar recursão para realizar a cópia dos subdiretórios, ainda envolve várias diferentes classes na cópia dos arquivos. Também deveria ser refatorado para 2 ou 3 métodos.

Existem diversos outros problemas com as antigas classes do java.io. Podemos pegar como exemplo a classe File, que tem alguns dos métodos para manipulação de arquivos, mas a maioria desses métodos não lança exceptions quando falham, e podem funcionar diferentemente em cada sistema operacional.

Vamos tentar deletar um diretório que possui arquivos dentro. O código segue abaixo:

File root = new File("/home/caelum");
boolean deletou = root.delete(); // retorna false...

Sabemos que o diretório não foi removido pelo retorno do método, mas é dificil saber o motivo, se é um problema de acesso, se o diretório que não está vazio, se não existe, etc., ficando para o programador a responsabilidade de descobrir o que aconteceu.

A partir do Java 7, foi introduzida uma nova API no pacote java.nio.file, visando reduzir a complexidade das operações realizadas em arquivos. A nova classe Files possui diversos métodos utilitários para manipular arquivos, lançando exceptions quando ocorre algum erro na operação, possibilitando ao desenvolvedor entender de forma rápida o motivo da falha. Os métodos de Files utilizam a classe Path, uma nova interface utilizada para representar entradas de arquivos/diretórios no sistema operacional.

O código para deletar o diretório ficaria da seguinte maneira:

Path rootPath = Paths.get("/home/caelum");
Files.delete(rootPath); // o que acontece aqui?

A classe Paths é uma fábrica de Path. O resultado desse código, é uma exception:

Exception in thread "main" java.nio.file.DirectoryNotEmptyException: /home/caelum

Vamos alterar nosso método copiaArquivos para utilizar as novas classes do Java 7:

public void copiarArquivos(Path origem, Path destino) throws IOException {
  // se é um diretório, tentamos criar. se já existir, não tem problema.
  if(Files.isDirectory(origem)){
    Files.createDirectories(destino);

    // listamos todas as entradas do diretório
    DirectoryStream entradas = Files.newDirectoryStream(origem);

    for (Path entrada : entradas) {
      // para cada entrada, achamos o arquivo equivalente dentro de cada arvore
      Path novaOrigem = origem.resolve(entrada.getFileName());
      Path novoDestino = destino.resolve(entrada.getFileName());

      // invoca o metodo de maneira recursiva
      copiarArquivos(novaOrigem, novoDestino);
    }
  } else {
    // copiamos o arquivo
    Files.copy(origem, destino);
  }
}

A estrutura do algoritmo é a mesma utilizada anteriormente, mas agora o número de classes envolvidas é muito menor. Para copiar um arquivo, apenas chamamos o método Files.copy, não precisando mais trabalhar com streams e channels nesses casos.

Ainda é trabalhoso percorrer um diretório inteiro dessa maneira, mas podemos utilizar a nova interface FileVisitor, uma implementação do pattern Visitor, para percorrer toda a árvore de diretórios de maneira mais simples. Os métodos dessa interface são

• preVisitDirectory Chamado antes de entrar em um diretório

• postVisitDirectory Chamado depois de passar por todos arquivos/subdiretórios de um diretótio

• visitFile Chamado para cada arquivo

• visitFileFailed Chamado se acontecer alguma exception em algum dos outros métodos

Todos os métodos retornam FileVisitResult, um enum com os as opções para continuar ou não percorendo a árvore de diretórios.

Vamos então implementar um FileVisitor para copiar nosso diretório. Nem sempre precisamos de todos os métodos da interface; neste caso, podemos estender a classe SimpleFileVisitor e apenas sobreescrever os métodos que realmente necessitamos:

public class CopiadorDeArquivos extends SimpleFileVisitor {
  private Path origem;
  private Path destino;

  public CopiadorDeArquivos(Path origem, Path destino) {
    this.origem = origem;
    this.destino = destino;
  }

  public FileVisitResult preVisitDirectory(Path dir, BasicFileAttributes attrs)
          throws IOException {
    copiaPath(dir);
    return FileVisitResult.CONTINUE;
  }

  public FileVisitResult visitFile(Path file, BasicFileAttributes attrs)
          throws IOException {
    copiaPath(file);
    return FileVisitResult.CONTINUE;
  }

  private void copiaPath(Path entrada) throws IOException {
    // encontra o caminho equivalente na árvore de cópia
    Path novoDiretorio = destino.resolve(origem.relativize(entrada));
    Files.copy(entrada, novoDiretorio);
  }
}

Na classe acima, usamos apenas dois métodos, o visitFile, chamado para copiar cada arquivo existente na árvore, e o preVisitDirectory, chamado para criar o diretório. Para executar a cópia, faríamos:

Path origem = Paths.get("/home/caelum");
Path destino = Paths.get("/home/caelum-copia");

Files.walkFileTree(origem, new CopiadorDeArquivos(origem, destino));

O método walkFileTree recebe o diretório que será percorido, e um FileVisitor, que irá passar por todos os arquivos.

Apesar de ter tornado alguma operações mais simples, essa nova API de arquivos possui mais métodos estáticos e a maioria recebe uma instância de Path, separando comportamento e dados. Talvez com o futuro Java 8, as closures e defender methods tornarão a interface Path mais amigável, sem depender tanto de métodos estáticos.

Além das classes apresentadas, ainda tivemos outros acréscimos na API de NIO, como leitura/escrita de streams de forma assíncrona, serviços para monitorar alterações em diretórios e métodos para ler metadados de arquivos de maneira simplificadas. Essas novidades são conhecidas como NIO2. Com o passar das versões, o Java traz cada vez mais para suas APIs internas ferramentas necessárias para o dia a dia.

Desenvolvedores de backend que precisam de muita escalabilidade já conhecem os truques de IO não-blocante há muito tempo: selector, poll e epoll no Linux, kqueue no MacOS e BSD e I/O Completion Ports no Windows. A palestra do Renato Lucindo no QConSP abordava questões e soluções que podiam ser implementadas com essas abordagens. Curiosamente são padrões e implementações já bastante antigos, e agora surgem novamente com força. Mas onde o IO não-blocante e estratégias de conexão podem nos ajudar numa aplicação web do dia a dia? No Ajax reverso.

Considerando o exemplo trivial de ter de atualizar o valor de um produto em leilão a cada alteração de preço, podemos fazer com que o browser dispare uma requisição Ajax a cada 5 segundos, e, caso haja alguma modificação no preço, o servidor vai responder o valor novo e via javascript atualizamos esse valor. Essa é a implementação mais básica de ajax reverso, o polling, dando a impressão para o usuário de que a aplicação está atualizada com o servidor. A desvantagem aqui é que num intervalo de cerca de 5 segundos, você pode estar vendo dados stale, o que é aceitável para grande maioria das aplicações.

Para algo mais sofisticado, precisamos realmente fazer um push do servidor: quando houver dados, mandamos para o cliente. Muitos se referem as técnicas de Ajax push como comet, e são duas as mais usadas: fazer um long polling, e o servidor segura a requisição aberta por alguns segundos ou até ter algum dado para enviar; ou fazer um verdade streaming, mantendo a conexão aberta por tempo indeterminado, e ir enviando os dados novos para o cliente na medida que houver. Em ambos os casos podemos facilmente implementar o cliente, mas como fazer no servidor?

No servidor, precisamos manter a socket aberta com o cliente. Em uma implementação ingênua, teremos, para cada HttpServletResponse, uma thread em waiting. Quando o evento que estamos esperando for disparado, fazemos o notify/notifyAll necessário (ou ainda usar BlockingQueues). Essa implementação de thread-per-request é bastante cara no Java, tanto pelo footprint de memória quanto por criar native threads. Quando o número de clientes aumentar, a grande quantidade de threads vai atrapalhar bastante o desempenho do sistema, mesmo se praticamente todas as conexões estiverem ociosas, que é um caso bastante frequente para o nosso cenário.

Em muitos casos o melhor será usar algumas poucas (muitas vezes apenas uma) threads que façam o event loop e verifiquem se algum SocketChannel daquele Selector está pronto para leitura/escrita, e realize a operação correspondente caso necessário. Implementar isso com java.nio não é difícil, e mais ainda, os servlet containers começaram a implementar essa estratégia e fornecer abstrações bem mais simples para não ter de trabalhar com event loops nem máquinas de estado. O Tomcat 6 já trazia uma abstração para Comet com diversos callbacks para o estado de cada socket, enquanto o Jetty 6 já fazia o mesmo através de uma implementação limitada de continuations, porém bastante simples. Em ambos a ideia era fornecer uma maneira de suspender e continuar o processamento daquela requisição, e que, enquanto o processamento estivesse suspenso, aquela thread não entrasse em estado blocked, podendo voltar a processar outras requisições que possuíssem sockets prontas para ler/escrever sem contenção.

Desde novembro de 2009 não precisamos mais adotar uma solução específica de servlet container: na Servlet 3 temos suporte ao que foi batizado de contexto assíncrono. Se precisamos fazer um push para todos os clientes conectados, basta avisarmos ao container que não queremos que a requisição termine ao fim do método service (e, portanto, do doGet, doPost, etc). Fazemos isso com um simples req.startAsync(). Depois adicionamos o contexto devolvido em uma coleção, para poder fazer o broadcast do evento que os clientes estão todos aguardando.

	private Queue<AsyncContext> clients = new ConcurrentLinkedQueue<AsyncContext>();

	protected void doGet(HttpServletRequest req, HttpServletResponse arg1)
			throws ServletException, IOException {
		AsyncContext ctx = req.startAsync();
		ctx.setTimeout(3000000);
		clients.add(ctx);
		System.out.println("novo cliente conectou." );
	}

Você já pode rodar esse teste com seu servlet container (Tomcat 7 e Jetty 8 possuem suporte). Para isso falta configurar a Servlet através de anotações para que ela tenha suporte a chamada assíncrona:

@WebServlet(urlPatterns = { "/subscribe" }, asyncSupported = true)
public class ChatServlet extends HttpServlet {

Se você fizer uma requisição para /subscribe do seu servidor, perceberá que o browser ficará em aguardo de uma resposta, já que o servidor não encerrou a requisição. Queremos disparar uma mensagem para todos os clientes que estiverem esperando nosso push (que tiver feito o “subscribe“). Para isso, vamos fazer com que o post em /subscribe envie uma mensagem. Por enquanto vamos adicionar essa mensagem no fim de nossa fila, com um id próprio:

	private BlockingQueue<String> messages = new LinkedBlockingQueue<String>();
	private AtomicInteger contador = new AtomicInteger();

	protected void doPost(HttpServletRequest req, HttpServletResponse arg1)
			throws ServletException, IOException {
		System.out.println("enviando mensagem para todos cliente");
		messages.add(String.format("mensagem número %d %n", contador.incrementAndGet()));
	}

Precisamos que alguém seja responsável por verificar se há mensagens novas na fila e, caso positivo, enviar essa mensagem a todos os clientes da nossa lista de AsyncContext. Faremos isso numa thread que será iniciada durante a criação de nossa servlet, e ficará esperando por mensagens novas no método blocante BlockingQueue.take:

public void run() {
	while (true) {
		final String message = messages.take();
		for (final AsyncContext ctx : clients) {
			public void run() {
				PrintWriter writer = ctx.getResponse().getWriter();
				writer.println(message);
				writer.flush();
			}
		}
	}
}

Removi o tratamento das checked exceptions por uma questão de legibilidade, e o código completo desta ChatServlet pode ser encontrada aqui.

E como realizar um teste com milhares de clientes? Isso pode ser um problema: caso você utilize alguma biblioteca que faça thread-per-request, não vai conseguir abrir muitos clientes simultaneamente, dado o número excessivo de threads criadas. Você vai precisar fazer um cliente usando java.nio puro, ou ainda em conjunto com alguma biblioteca http que utilize a API não-blocante. Esse é o caso das novas versões do Apache Http Core, e aqui há um pequeno teste de exemplo.

Você ficará bastante impressionado ao ver que uma máquina caseira pode suportar mais de 5 mil clientes simultâneos com o Jetty 8, e que só vai parar nesse número provavelmente pelo limite padrão de arquivos abertos no seu sistema operacional.

Economizar recursos caros, como threads, conexões e descritores de arquivos, é sempre uma preocupação. Na Servlet 3 conseguimos balancear esses recursos, minimizando o uso de memória e processamento, porém pagando um pouco mais alto no uso de descritores abertos, mas que ajudam muito nesse cenário de ajax reverso com push.

Expressivos agradecimentos ao Renato Lucindo e Gleicon Moraes pelo aprendizado, diversas explicações, conversas e correções.

Durante boa parte da vida do GUJ.com.br, na sua segunda versão (screenshot acima), o site sofreu diversas quedas e passou por muitos períodos de lentidão, mesmo depois de ter migrado para um servidor dedicado. A grande verdade é que por um bom tempo ficamos devendo a devida atenção ao deployment do GUJ. Sempre que um problema acontecia alguém simplesmente reiniciava o servidor, sem investigar as causas reais do problema com profundidade.

Dada a relação próxima que a Caelum sempre teve com o site, já que dois dos fundadores do GUJ são também os fundadores da Caelum, resolvemos assumir de vez a posição de criadores do GUJ. A Caelum agora é a patrocinadora e mantenedora oficial do GUJ. Recentemente andamos gastando algum tempo, tentando acabar de vez com estes problemas que o GUJ a tanto tempo sofre. Felizmente, a melhora já é bem perceptível!

Há algum tempo atrás, o GUJ ficava esporadicamente muito lento. Para resolver estes problemas de lentidão, o primeiro passo foi conseguir um servidor dedicado, pago pelos anúncios espalhados pelo site. Já faz tempo que o GUJ roda neste servidor dedicado e desde então a performance se tornou quase sempre aceitável.

Porém, o servidor dedicado não resolveu todos os problemas, já que java.lang.OutOfMemoryError sempre foi o principal problema enfrentado pelo GUJ. Sempre desconfiamos que o culpado poderia ser o código do próprio GUJ, ou até do JFórum, que deveriam conter algum vazamento de memória.

Alguns desenvolvedores da Caelum já tiveram ótimas experiências passadas com o Jetty, que é um excelente servidor web e servlet contêiner. Foi, inclusive, um dos servidores Java pioneiros a usar conectores NIO (java.nio). O Jetty foi desenhado para ser embutido em outras aplicações Java e portanto é extremamente leve. Consome bem menos memória que o Tomcat, seu concorrente mais conhecido, e não deixa nada a desejar nas outras características.

O servidor dedicado do GUJ tem 2GB de memória RAM e o Tomcat estava configurado inicialmente para ter um heap máximo de 768MB (-Xmx768M). A primeira tentativa foi aumentar o heap máximo (-Xmx1024M), mas mesmo assim o temível OutOfMemoryError insistia em aparecer.

Resolvemos então dar uma chance ao Jetty. Já que ele consome menos memória, acreditamos que os OutOfMemoryError demorariam mais a aparecer. Logo ao subir, o jetty ocupa 4% da memória do servidor. O impressionante é que em duas semanas no ar, o uso total de memória não passou de 12%. Na verdade, o uso de memória estabilizou em 9% do total, porém recentemente fizemos alguns testes de carga no servidor do guj, com mais do que o dobro do número de conexões que o guj recebe hoje nos períodos de pico. Isto fez com que o uso de memória do Jetty pulasse para 12%. Uma diferença enorme da quantidade usada pelo Tomcat, que chegava facilmente a 80%.

Já temos algum tempo rodando, sem problemas de memória e com o jetty estável usando 9-12% do total da memória do servidor. Já estamos até pensando em descartar a possibilidade de existir um vazamento de memória no código do GUJ ou do JForum. Isto tornaria o Tomcat culpado pelos problemas de memória!

A possibilidade de vazamentos de memória no Tomcat (estávamos com a versão 6.0.14, sem o APR e com Linux Kernel 2.6.22) deste tamanho é um pouco assustadora. Com a base de usuários que o Tomcat tem, muito possivelmente alguém já teria pego este problema muito antes de nós. Provavelmente o problema é de alguma configuração mal feita no Tomcat do GUJ.

Fato é que o Jetty foi uma tentativa que deu certo e o problema está aparentemente resolvido. O Jetty mostrou um uso mais alto de CPU que o Tomcat, chegando a picos de 60% da capacidade total de processamento do servidor, que possui 2 processadores. Através dos testes de carga que fizemos, temos percebido que o Jetty usa bastante CPU para responder diversas requisições simultâneas. Isso não chega a ser um problema, já que os dois processadores que o servidor possui são mais do que suficientes para atender a quantidade de requisições por segundo que o GUJ recebe hoje.

Apesar de termos algumas suspeitas, ainda não investigamos a razão do alto uso de CPU. Este é um ponto a ser abordado, caso o GUJ tenha problemas com disponibilidade de processamento algum dia.

Mesmo não representando um problema hoje, esta situação preocupa já que o MySQL rodando na mesma máquina também costuma usar bastante CPU. Isto pode se tornar um problema em algum dia que tenha um pouco mais de requisições por segundo do que o comum, já que o uso de CPU chegava as vezes perto do limite. Felizmente, grande parte das requisições ao servidor do GUJ são para conteúdo estático: imagens, JavaScripts, arquivos CSS, download de pdfs (dos artigos), entre outros. Todo esse conteúdo estático era servido pelo Jetty, contribuindo para o alto uso de CPU. Resolvemos então tentar um proxy reverso na frente do Jetty, especificamente para servir este conteúdo estático.

Existem diversas alternativas de proxy reverso e a primeira a ser considerada quase sempre é o conhecido servidor web Apache Httpd, com a adição do mod_proxy. É uma excelente solução e existe bastante documentação para fazer tudo funcionar. No entanto, faz um tempo que eu já estava querendo testar o servidor russo Nginx, tão falado pelo pessoal da Engine Yard.

A desvantagem do Nginx para o Apache Httpd é a documentação não tão extensa. Esse é um grande problema para a comunidade do Nginx, que tem se esforçado em traduzir grande parte do que está escrito em russo. Apesar disso, o Nginx é impressionante e superou todas as nossas expectativas. Além de ser extremamente rápido, consome pouquíssimos recursos. Cada um dos processos (1 master + 5 workers) consome na maior parte do tempo apenas 1% de CPU e 0.2% da memória disponível do nosso servidor. Incrível!

O conteúdo estático do GUJ agora é todo servido pelo Nginx; as requisições nem chegam ao Jetty. Além disso, o Nginx, como um bom proxy reverso, oferece diversas otimizações. Uma essencial para o GUJ é o preenchimento automático dos cabeçalhos HTTP de cache, sugerindo aos browsers que façam cache do conteúdo estático. Agora o consumo de CPU diminuiu consideravalmente.

Não fizemos nenhum comparativo científico de performance, mas a melhora dos tempos de resposta do GUJ está visível. Frequentemente tenho a sensação de que o site está “voando”.

Configuramos também no Nginx a exibição de algumas estatísticas de acesso; tão valiosas ao GUJ. É assustador como o padrão de acesso se repete a cada dia, e a cada semana. Repare como o gráfico de requisições por segundo é praticamente idêntico para cada dia (com exceção do sábado e domingo, que são parecidos entre si).

Temos também o interesante gráfico de conexões por segundo, que mostra relação média aproximada de 3 requisições por conexão.

Note que a legenda do gráfico está errada, já que deveria mostrar “connections/sec”. O pequeno pico que dá para ver no gráfico aparece por causa de alguns testes de carga que fizemos neste dia. Pode ser desconsiderado.

Fizemos ainda algumas experiências com múltiplos servidores Jetty por trás do Nginx, funcionando também como balanceador de carga. Espero em breve postar sobre nossa experiência em geral com balanceamento de carga e alguns outros truques que pudemos testar nesta experiência do GUJ e em alguns clientes.

Aproveitando o post, o GUJ recentemente comemorou a marca de meio milhão de mensagens. É um orgulho poder fazer parte desta comunidade, e mais ainda por poder torná-la cada vez melhor.