Akka programação concorrente

1

Akka: Programação concorrente

Fique por dentro

Este artigo irá apresentar um modelo de concorrência baseado em troca de mensagens e uma implementação

deste modelo, o framework Akka. O desenvolvimento de aplicações que demandam alto volume de

requisições e alta disponibilidade é um grande desafio para quem adota o modelo convencional com threads

e locks.

Neste cenário, o Akka é uma opção interessante que usa um paradigma diferente de concorrência que

possibilita uma escalabilidade muito grande.

Criar aplicações que suportam alta concorrência sempre foi um desafio, independente da tecnologia adotada.

O crescimento da capacidade de processamento dos computadores, resultado do aumento do número de

núcleos, memória, disco, etc. permitiu a criação de aplicações com mais poder computacional e com suporte

a um maior número de requisições.

E quando o número de requisições extrapola a capacidade de um servidor, podemos ainda estruturar a

aplicação para funcionar em um cluster de máquinas, aumentando mais a capacidade de concorrência.

Nos primórdios do Java, quando precisávamos lidar com concorrência, criávamos uma ou várias threads e

administrávamos manualmente esse volume necessário para a execução eficiente de determinada tarefa.

Na versão 5, o Java trouxe uma API de concorrência de alto nível, a java.util.concurrent [1], nos livrando

da gestão manual das threads através da utilização de Executors. Algum tempo depois, no Java 7, foi

introduzido o Fork/Join framework [2], otimizando a utilização de threads e elevando ainda mais a

capacidade de concorrência.

Contudo, mesmo com estas evoluções na API de concorrência do Java, esta ainda se trata de algo de baixo

nível quando desejamos criar aplicações com alta concorrência sem nos preocuparmos com detalhes de

threads, pool de threads, etc. Neste contexto, o Akka [3] é um framework que nos oferece esta desejada

abstração.

Escrito em Scala e com API para Scala e Java, o Akka foi desenvolvido sobre a API de concorrência do Java

e que possibilita ao desenvolvedor utilizar um modelo de concorrência baseado em atores. Com o Akka,

todas as buzzwords de concorrência, como threads, pools, locks, etc., deixam de fazer sentido.

Assim, nos concentramos apenas na estruturação da nossa aplicação em atores e na lógica de negócio de

cada ator. Porém, antes de começarmos a falar de atores, vamos entender em que modelo de concorrência os

atores se encaixam, para compreendê-los melhor.

Modelos de concorrência

De maneira generalista, podemos dividir os modelos de concorrência em dois paradigmas: concorrência

usando estado compartilhado e concorrência usando troca de mensagens. O modelo de estado compartilhado

tem sido largamente adotado no campo, mas em aplicações maiores ou com maior concorrência, o modelo

de troca de mensagens é preferido, pois sua característica assíncrona facilita a distribuição do

processamento, reduzindo gargalos.

Estado compartilhado x troca de mensagens

O modelo de estado compartilhado é o modelo que adotamos normalmente em nossas aplicações. Neste

modelo o código a ser paralelizado é executado simultaneamente através da criação de processos ou threads.

2

A complexidade aumenta quando estas threads precisam acessar a mesma informação (estado

compartilhado).

Para resolver este problema usamos blocos synchronized, que acabam gerando um gargalo na aplicação,

pois as instruções protegidas por synchronized são executadas apenas por uma thread por vez. Com o

crescimento da aplicação, consequentemente a quantidade de blocos synchronized cresce, eventualmente

causando lentidão e casualmente um dead-lock.

Derek Wyatt, engenheiro de software atuante na comunidade Akka/Scala, no seu livro “Akka Concurrency”

[4], nos brinda com uma definição perfeita sobre este modelo: “Em concorrência com estado compartilhado

tendemos a criar os problemas primeiro, então resolvê-los usando primitivas de sincronização.”

. A Figura 1 ilustra o modelo de estado compartilhado e seus gargalos.

Figura 1. Representação gráfica do modelo de concorrência baseado em estado compartilhado.

No modelo de troca de mensagens (ver Figura 2) não temos o problema de locks encontrado no modelo de

estado compartilhado, pois os componentes não compartilham estado e se comunicam através de mensagens

predominantemente assíncronas. O envio das mensagens normalmente é feito por algum outro software que

atua como intermediário entre os componentes.

Este “desconhecimento” entre os componentes garante um bom nível de desacoplamento e favorece a

distribuição, pois permite a troca de mensagens entre componentes que estejam em servidores diferentes ou

até em outras redes. O modelo de atores é uma derivação do modelo de troca de mensagens, e falaremos

sobre ele agora.

3

Figura 2. Representação gráfica do modelo de concorrência baseado em troca de mensagens.

Modelo de Atores

Em 1973, Carl Hewitt, Peter Bishop e Richard Steiger, introduziram pela primeira vez o modelo de atores,

no paper “A Universal Modular Actor Formalism for Artificial Intelligence”. Nos anos seguintes, diversas

intervenções foram feitas neste modelo e diversos papers foram publicados, o que culminou na definição da

teoria do modelo de atores.

Fundamentalmente, o modelo de atores prega que “tudo são atores”. Os atores são definidos como entidades

capazes de realizar um processamento computacional e que se comunicam entre si através do envio e

recebimento de mensagens.

Além disso, podem criar outros atores, estabelecendo assim uma hierarquia entre eles. Como a comunicação

entre atores deve ser feita estritamente pela troca de mensagens, o estado interno de um ator não é acessível

por outros, mas somente por ele mesmo.

Aliando isso ao fato do processamento das mensagens ser sequencial, isto é, um ator poder ter várias

mensagens pendentes, mas apenas uma ser processada por vez, os problemas com locks simplesmente

deixam de existir. A Figura 3 mostra uma visão simplificada do modelo de atores.

4

Figura 3. Representação gráfica do modelo de concorrência baseado em atores

Com estas características, este tipo de solução vem sendo adotado para aplicações que processam grandes

volumes de dados, pois para atender esse tipo de demanda usando o modelo convencional de threads e o

processamento síncrono, ficamos limitados pela capacidade individual dos servidores.

Por sua vez, o modelo de atores permite uma distribuição mais fácil dos componentes da aplicação devido a

sua natureza assíncrona e baseada em mensagens. O Erlang [5], linguagem originada na Ericsson com o

propósito de suportar aplicações distribuídas altamente concorrentes, possui em seu core uma

implementação deste modelo.

Contudo, apesar do Erlang ser uma linguagem de uso geral, não conquistou grande adoção. Em razão disso,

faltava ao mercado uma solução para alta concorrência baseada em atores. Assim surgiu o Akka.

Akka

O Akka foi desenvolvido em 2009 por Jonas Bonér, inspirado pelo modelo de atores do Erlang. Seu

primeiro release público, o Akka 0.5, foi anunciado em Janeiro de 2010. Atualmente esta solução é mantida

pela Typesafe Inc., a mesma empresa que mantém o Scala e o Play Framework. Recentemente, o Akka

passou a fazer parte da API padrão do Scala, substituindo o modelo de atores original desta linguagem, e

apesar de ser escrito em Scala, possui uma API oficial também para Java.

De acordo com a definição da equipe, o Akka é um “toolkit e um runtime para construir aplicações

altamente concorrentes, distribuídas e tolerantes a falhas na JVM”. Assim, aplicações criadas usando o Akka

já nascem prontas para operar de maneira distribuída, pois esta característica está na essência do framework.

5

Criado com o foco em aplicações distribuídas e otimizado para operar de maneira standalone, o Akka provê:

· Atores: conforme explicado anteriormente, a base do Akka é sua implementação do modelo de atores;

· Futures: apesar de podermos utilizar atores para resolver praticamente todos os problemas, às vezes pode

ser mais conveniente utilizar Futures. Os futures do Akka são muito parecidos com a implementação padrão

do java.util.concurrent, porém possui integração com atores;

· Scheduler: integrado ao contexto de atores, o Akka permite o agendamento de tarefas usando vários tipos

de schedulers.

Devido a estas características e recursos, o Akka vem sendo adotado por várias empresas de porte. Dentre

elas, podemos citar a Amazon, Autodesk, Blizzard, VMware, dentre outros.

Hello World – Primeiros passos

Uma forma de desenvolver aplicações com o Akka é fazer com que o framework seja uma dependência do

projeto e usar a própria aplicação para iniciar o sistema de atores. Além dessa, existe outra opção para

desenvolver tais aplicações: usando o Typesafe Activator, que é um software que depois de instalado pode

ser utilizado para criar e executar aplicações diversas baseadas em templates.

O Activator na verdade oferece muito mais, como por exemplo, uma IDE totalmente web para manutenção

dos projetos gerados por ele. Tanto o Activator quanto as dependências do Akka podem ser obtidos na

página de downloads do site do próprio Akka [6]. Neste artigo, adotaremos a primeira opção, pois esta

permite uma compreensão melhor do funcionamento do framework.

Para criar uma aplicação usando o Akka podemos usar uma ferramenta de build como o Maven ou o SBT.

Aqui optaremos pelo Maven, por ele ser mais empregado pela comunidade. Antes de criar a aplicação, você

deve ter o Eclipse com o plugin do Maven (m2e) instalado, ou apenas o Maven, caso você prefira realizar o

build pela linha de comando.

Dito isso, crie um diretório para hospedar o código da aplicação, e depois crie o pom.xml com a dependência

do Akka, conforme indica a Listagem 1.

Listagem 1. pom.xml base de uma aplicação com Akka.

<project>

<modelVersion>4.0.0</modelVersion>

<groupId>com.devmedia.akka</groupId>

<artifactId>hello</artifactId>

<version>0.0.1-SNAPSHOT</version>

<build>

<pluginManagement>

<plugins>

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-compiler-plugin</artifactId>

<configuration>

<source>1.7</source>

<target>1.7</target>

</configuration>

</plugin>

</plugins>

</pluginManagement>

</build>

6

<dependencies>

<dependency>

<groupId>com.typesafe.akka</groupId>

<artifactId>akka-actor_2.10</artifactId>

<version>2.2.3</version>

</dependency>

</dependencies>

</project>

Em seguida, crie uma classe no diretório src/main/java chamada Start. Esta classe será responsável por

iniciar a aplicação e o sistema de atores do Akka. Inicialmente ela deve estar vazia, conforme a Listagem 2.

Listagem 2. Classe que irá iniciar o sistema de atores do Akka.

public class Start {

public static void main(String[] args) {

// aqui inicializaremos o Akka

}

}

Agora, antes de pormos as mãos na massa, vamos analisar o conceito de sistema de atores do Akka.

Actor System – O container de atores

Como principal característica, o Akka implementa um modelo de atores. De modo simples, este modelo diz

que tudo são atores. Sendo assim, a lógica da aplicação que normalmente é programada em classes que

costumamos chamar de “o modelo da aplicação” ou os “componentes de negócio”, deve ser estruturada em

um ou vários atores que se comunicam de maneira assíncrona através da troca de mensagens, todos sob a

gestão do actor system.

Veremos adiante que para criar um ator basta estender uma determinada classe do Akka e usar a sua API

para solicitar a instanciação. Contudo, para dar vida aos atores, precisamos antes inicializar o container

Akka, ou seja, iniciar o actor system.

O actor system é o ponto de partida de toda aplicação, por isso, deve ser criado assim que ela iniciar. Em

relação ao número de actor systems, uma aplicação pode iniciar vários deles, porém este tipo de design não é

indicado por questões de organização.

Para criar um actor system devemos usar a classe akka.actor.ActorSystem, como demonstra a Listagem 3.

Listagem 3. Criação do actor system.

import akka.actor.ActorSystem;



// Criação de um Actor System, container Akka.

ActorSystem system = ActorSystem.create("HelloSystem");

}

}

Podemos observar que o construtor do actor system recebe um texto como parâmetro para definir o seu

nome. Este nome deve ser único por aplicação e também deve ser único por container, caso a aplicação seja

instalada em um microcontainer Akka. Como veremos adiante, o nome do actor system também irá compor

o path de localização do ator.

7

Atores em todos os lugares

De acordo com a explicação anterior, no modelo de atores um ator é um objeto capaz de receber e enviar

mensagens, além de criar outros atores. No processamento das mensagens recebidas está a lógica de negócio

do ator. No exemplo que estamos desenvolvendo, iremos criar um ator que recebe uma mensagem e exibe

esta mensagem no console.

No Akka, para criarmos a classe de um ator, devemos estender a classe abstrata akka.actor.UntypedActor

e implementar o método void onReceive(Object msg). Este método é responsável pelo processamento das

mensagens. Deste modo, crie a classe EcoActor em src/main/java contendo o código da Listagem 4.

Listagem 4. Um ator que exibe no console a mensagem recebida.

import akka.actor.UntypedActor;

import akka.event.LoggingAdapter;

import akka.event.Logging;

public class EcoActor extends UntypedActor {

LoggingAdapter log = Logging.getLogger(getContext().system(), this);

@Override

public void onReceive(Object msg) throws Exception {

log.info("Mensagem recebida: " + msg);

}

}

Deixando os detalhes de criação do logger para depois, podemos reparar que a classe de um ator é simples.

É importante notar que a mensagem pode ser qualquer objeto Java, porém é razoável que este implemente

Serializable (apesar do Akka não obrigar) para não termos problemas em um ambiente distribuído, onde

mensagens são serializadas para trafegar pela rede.

Voltando para a classe Start, agora que temos um ator implementado, podemos usar o actor system para

efetivamente dar vida a este ator. Assim, usamos o método actorOf() de actor system para criar o ator. Este

método recebe como parâmetro uma instância de akka.actor.Props e uma String com o nome que o ator

terá no actor system. Props é uma classe que define um objeto de configuração, usado apenas para criar

atores.

Para a construção do objeto Props, usamos o método estático Props.create(), passando como parâmetro a

classe do ator. Existem muitas maneiras de construir Props, mas para o nosso exemplo, usaremos a forma

mais simples. A Listagem 5 mostra a classe Start alterada, com a criação do ator.

Listagem 5. Criando o ator EcoActor.


import akka.actor.ActorRef;

import akka.actor.Props;



// Criação de um Actor System, que é o container Akka.


// Criando o ator EcoActor

ActorRef actor = system.actorOf(Props.create(EcoActor.class), "eco");

}

}

8

É importante perceber que o que obtemos ao criar um ator é um ActorRef e não um objeto com a classe do

ator propriamente dita (EcoActor). Nesta informação reside um grande conceito do Akka e do modelo de

atores: os detalhes do ator não são expostos para quem envia a mensagem, pois o estado interno deste deve

ser visível apenas para ele mesmo. Isso fica bem claro na implementação do ator.

Basta percebermos que o código processado por ele (sua lógica de negócio) se restringe ao método

onReceive(), que é chamado pelo Akka para processar as mensagens. Como as mensagens são processadas

uma por vez (ou seja, apenas uma thread por vez), não existe nenhuma necessidade de blocos synchronized.

Com isso, locks e deadlocks não existem neste modelo.

ActorRef é a interface para comunicação com o ator criado e o método ActorRef.tell() é utilizado para

enviar uma mensagem para este ator. Este método recebe como parâmetro a mensagem e o ator que a está

enviando. Como estamos enviando a mensagem do método main() da casse Start (isto é, não é um ator que

está enviando a mensagem), usaremos ActorRef.noSender(), que é um método auxiliar que retorna uma

constante para identificar ao actor system que não existe nenhum ator origem. A Listagem 6 mostra o envio

dessa mensagem ao ator.

Listagem 6. Enviando uma mensagem para EcoActor.


import akka.actor.ActorRef;

import akka.actor.Props;



// Criação de um Actor System, que é o container Akka.


// Criando o ator EcoActor

ActorRef ecoActor = system.actorOf(Props.create(EcoActor.class), "eco");

// Enviando a mensagem ao ator

ecoActor.tell("Alô Mundo com Atores", ActorRef.noSender());

}

}

Com essas duas classes já é possível ver o Akka em ação, mas antes, precisamos compilar a aplicação. Para

isso, usaremos o Maven através do comando mvn clean install. Em seguida, executaremos a aplicação

também pelo Maven, com o plugin exec:java, como indica a Listagem 7.

Listagem 7. Executando a aplicação.

$ mvn clean install exec:java -Dexec.mainClass=Start

.

. (detalhes do build omitidos)

.

[INFO] [01/01/2014 19:00:00.384] [HelloSystem-akka.actor.default-dispatcher-3]

[akka://HelloSystem/user/eco] Mensagem recebida: Alô Mundo com Atores

Note que a mensagem enviada (“Alô Mundo com Atores”) foi processada pelo ator e impressa no console

conforme esperado. O log do actor system ainda informa o timestamp, o nome da thread e o nome do ator

que está logando.

Falaremos destes detalhes adiante. Para interromper a execução, digite Ctrl+c, caso contrário o actor system

continuará executando.

9

Antes de partir para a modelagem de uma aplicação mais próxima do real, vamos apresentar algumas

funcionalidades do Akka usando o tradicional “Hello, World!”.

Atores criando atores

Conforme descrito anteriormente, um ator pode iniciar (ou criar) outros atores, estabelecendo uma

hierarquia entre eles. Esta hierarquia é definida de acordo com a modelagem da aplicação. Contudo, nada

impede de modelarmos uma aplicação usando o Akka e criar todos os atores na raiz do actor system, como

fizemos com EcoActor.

Apesar dessa possibilidade, por questões de organização e de gestão de exceções, é importante definir uma

estrutura coesa de atores e normalmente isso implica em vários níveis.

Para criar um ator a partir de outro, é indicado fazê-lo dentro do método preStart() de UntypedActor,

apesar de nada impedir de fazermos isso sob demanda, ou seja, na primeira vez que o ator for utilizar o ator

filho.

O actor system executa o prestar() (dentre outros que ainda analisaremos do ciclo de vida dos atores) antes

de completar a inicialização de um ator. Sendo assim, este é um excelente lugar para inicializar eventuais

estados internos do ator, como por exemplo, dependência de outros atores ou atributos privados utilizados

por ele.

Tendo em vista estas informações, vamos alterar o código da aplicação exemplo para que o EcoActor crie

um ator na sua inicialização e repasse toda mensagem recebida por ele para este ator “filho”.

Para isso, declare uma classe chamada ChildActor com o mesmo código de EcoActor (ver Listagem 4).

Agora, devemos alterar EcoActor, sobrescrever o método preStart() e instanciar o ator “filho”, do tipo

ChildActor. Assim como a criação de um ator via actor system, para instanciar um ator dentro de outro

usamos o método actorOf() do contexto do ator.

Este contexto é obtido através do método getContext(). A Listagem 8 mostra a implementação do método

preStart() e a criação do ator filho, bem como o repasse das mensagens recebidas em onReceive().

Listagem 8. Criando um ator filho via getContext().

public class EcoActor extends UntypedActor {

LoggingAdapter log = Logging.getLogger(getContext().system(), this);

//Declaramos o ator filho como atributo de EcoActor

private ActorRef childActor;

@Override

public void preStart() throws Exception {

super.preStart();

//Na inicialização do ator, instanciamos o ator filho

childActor = getContext().actorOf(Props.create(ChildActor.class), "childOfEco");

}

@Override



//Repassamos a mensagem recebida para o ator filho

childActor.tell(msg, getSelf());

}

10

}

Para ver os resultados destas alterações, devemos repetir os comandos de compilação e execução via Maven,

como mostra a Listagem 9.

Listagem 9. Executando a aplicação.


.


.


[akka://HelloSystem/user/eco] Mensagem recebida: Alô Mundo com Atores


[akka://HelloSystem/user/eco/childOfEco] Mensagem recebida: Alô Mundo com Atores

O log exibido no resultado mostra claramente a hierarquia dos atores, exposta pelo path do ator. Repare que

a mensagem foi recebida por EcoActor, que tem o path akka://HelloSystem/user/eco, e repassada ao ator

filho, que tem o path akka://HelloSystem/user/eco/childOfEco.

O path de um ator é uma URI única que o identifica. Ela é composta pelo protocolo (akka://), o identificador

do actor system (HelloSystem), pela raiz dos atores criados pela aplicação (user), o identificador do ator pai

(caso exista) e o identificador do próprio ator. Sendo assim, na estrutura de atores criada pela aplicação

exemplo, temos dois atores identificáveis por dois paths:

akka://HelloSystem/user/eco

akka://HelloSystem/user/eco/childOfEco

O identificador do actor system (HelloSystem) é definido no start da aplicação, e o identificador de cada ator

é definido no momento de sua criação. Apenas o prefixo user é algo imposto pelo Akka, pois ele define a

raiz da hierarquia dos atores. Na prática, todos os atores criados pelas aplicações desenvolvidas com Akka

ficarão sob o guardião chamado user. Existem guardiões disponíveis para diversas finalidades, a saber:

/user: É o guardião de todos os atores criados pelo código da aplicação desenvolvida usando Akka;

· /system: Este é o guardião de atores criados pelo próprio Akka, para manter o funcionamento do

framework;

· /deadLetters: É um ator que recebe as mensagens enviadas para atores inexistentes, ou atores que não

estão em funcionamento;

· /temp: É o guardião de atores criados para necessidades temporárias, isto é, são atores de vida curta;

· /remote: Este é um guardião para paths virtuais, que representam atores remotos, ou seja, que estejam

instanciados em outras JVMs.

Mensagens tipadas

É muito comum no desenvolvimento de aplicações Akka um determinado ator ser programado para receber

vários tipos de mensagens e realizar processamentos distintos de acordo com a mensagem. Neste caso o

padrão adotado é utilizar classes diferentes para representar os diferentes tipos de mensagens.

A vantagem de usar este padrão é que ele deixa claro e visível os tipos de mensagens que um ator processa e

principalmente os que ele não processa. Para exemplificar, vamos refatorar nosso código para enviar uma

11

mensagem tipada para nossos atores e refutar qualquer outra mensagem. Para isto, criaremos uma classe

chamada HelloMessage, conforme a Listagem 10.

Listagem 10. Classe que representará a mensagem.

public class HelloMessage {

}

Como pode ser observado, esta classe não contém nenhum estado interno, pois o seu propósito é apenas

identificar um tipo de mensagem. Dito isso, depois de criá-la, devemos alterar os nossos atores, para deixar

claro que eles recebem e processam apenas esse tipo de mensagem. Sendo assim, o método receive() de

EcoActor deve ficar como exposto na Listagem 11.

Listagem 11. Alteração do método onReceive() de EcoActor.

@Override


if (msg instanceof HelloMessage) {


// repassamos a mensagem recebida para o ator filho

childActor.tell(msg, getSelf());

}

else {

// informa ao actor system que este ator não processa esta mensagem

unhandled(msg);

}

}

Repare que usamos instanceof para filtrar as mensagens processadas de acordo com o tipo destas. Neste

código é importante ressaltar a chamada ao método unhandled(), que deixa claro ao actor system que esta

mensagem não foi processada pelo ator. Deste modo, ela será considerada pelo actor system para eventuais

tratamentos futuros.

Se o método unhandled() não for chamado, o actor system não tem como saber que a mensagem não foi

processada. Para dar continuidade ao exemplo, devemos alterar também ChildActor, para receber apenas

mensagens do tipo HelloMessage. Veja a Listagem 12.

Listagem 12. Alteração do método onReceive() de ChildActor.

@Override


if (msg instanceof HelloMessage) {


}

else {

unhandled(msg);

}

}

Ao executarmos a aplicação (Listagem 9) após essas alterações, será possível notar que nenhum log será

exibido. Isso é facilmente explicado pelo fato de nossos atores agora apenas processarem mensagens do tipo

HelloMessage e a mensagem enviada pela classe Start ser do tipo String. Para corrigir isso, devemos

alterar a classe Start de acordo com a Listagem 13.

Listagem 13. Alterando o envio da mensagem em Start.

12

// Enviando a mensagem ao ator

ecoActor.tell(new HelloMessage(), ActorRef.noSender());

Com essa simples mudança, ao reexecutar a aplicação teremos o resultado apresentado na Listagem 14.

Listagem 14. Resultado da reexecução após as alterações.


.


.


[akka://HelloSystem/user/eco] Mensagem recebida: HelloMessage@7ee14288


[akka://HelloSystem/user/eco/childOfEco] Mensagem recebida: HelloMessage@7ee14288

Supervisores e estratégia de recuperação

Todos sabem o que acontece quando uma exceção é lançada em um sistema convencional. A exceção é

lançada a camadas superiores de serviços até que uma dessas camadas tenha a capacidade de lidar com ela.

No modelo de atores o que acontece é um pouco diferente, evidentemente por conta do desacoplamento

entre os componentes e pela característica assíncrona das chamadas.

Quando uma exceção é lançada no processamento de uma mensagem, o supervisor do ator que lançou a

exceção deve decidir o que vai acontecer com o ator. O supervisor de um ator é o ator que o criou, ou seja, o

seu pai.

Caso o ator tenha sido criado diretamente pelo actor system (como os atores criados na classe Start nos

exemplos), o ator não tem um pai conhecido ou explícito. Neste caso, o supervisor passa a ser o ator

guardião, ou seja, /user.

Antes de vermos o que pode acontecer com um ator que lança uma exceção, vamos entender um pouco mais

a respeito do ciclo de vida dos atores.

Ciclo de vida de um ator

É importante ressaltar que no Akka a(s) vida(s) dos atores é(são) representada(s) por encarnações (ver

Figura 4). Isso significa que um ator pode “nascer”, “morrer” e “reencarnar” (nascer novamente) e assim

sucessivamente. O termo encarnação é de fato utilizado na documentação do Akka e traz à luz alguns

conceitos interessantes da vida do ator, a saber:

1. Inicialmente um ator simplesmente não existe até o ponto em que alguma chamada por actorOf() é

executada, seja no actor system (raiz) ou pelo contexto de outro ator;

2. Após a chamada de actorOf() o ator ainda não está encarnado, ou seja, ainda não responde por

mensagens, porém tem: o path reservado; um identificador único (UID); a instância do objeto criada; o

método preStart() executado.

3. Após a execução do preStart() o ator está encarnado e recebendo/processando as mensagens destinadas a

ele;

4. Neste ponto algo errado pode acontecer e o ator pode lançar uma exceção. Assim, o ator passa para um

estado temporário que chamaremos de doente. Neste momento o supervisor do ator deve decidir o que fazer

com o ator doente, tendo três opções:

13

a. Continuar. Simplesmente ignorar que a exceção aconteceu e continuar com a vida do ator, processando

as mensagens normalmente;

b. Reiniciar o ator. O método preRestart() é executado na instância em execução, uma nova instância é

criada e o método postRestart() é executado na nova instância. O path do ator se mantém, assim como o

UID, caracterizando uma mesma encarnação;

c. Encerrar o ator (morte). O ator pode ser terminado pelo seu supervisor ou pelo envio de uma mensagem

que o finalize (existe uma mensagem no Akka do tipo akka.actor.PoisonPill, que ao ser consumida por um

ator causa sua interrupção). Neste ponto, o método postStop() é executado. Caso o ator seja iniciado

novamente, uma nova encarnação será criada, tendo o mesmo path, porém com um novo UID.

Figura 4. Ciclo de vida dos atores no container do Akka.

A definição da estratégia de recuperação é feita no supervisor, ou seja, no ator pai, e vale para todos os seus

filhos. Caso o supervisor de um ator não defina a estratégia de recuperação dos seus filhos, se o ator em

questão lançar uma exceção, o Akka tenta usar a estratégia definida pelo pai do pai e assim sucessivamente

até a raiz, isto é, o ator guardião /user.

Para definir uma estratégia de recuperação em um ator, devemos sobrescrever o método

supervisorStrategy() de UntypedActor. Este método deve retornar uma instância de

akka.actor.SupervisorStrategy, que pode ser de dois tipos:

· OneForOneStrategy: Se o retorno do método supervisorStrategy() for uma instância de

OneForOneStrategy, significa que a ação tomada irá afetar apenas o ator que lançou a exceção, ou seja, o

ator doente;

14

· AllForOneStrategy: Se o retorno do método supervisorStrategy() for uma instância de

AllForOneStrategy, a ação tomada será aplicada a todos os atores filhos do supervisor que está definindo a

estratégia.

O trecho de código da Listagem 15 mostra a criação de uma estratégia de recuperação implementada em um

ator.

Listagem 15. Implementação de uma estratégia de recuperação.

@Override

public SupervisorStrategy supervisorStrategy() {

return new OneForOneStrategy(-1, Duration.Inf(), new Function<Throwable,

Directive>() {

public Directive apply(Throwable t) throws Exception {

return OneForOneStrategy.resume();

}

});

}

Para implementar uma estratégia de recuperação em um supervisor (um ator com filhos), devemos

sobrescrever o método supervisorStrategy(), que por sua vez, deve retornar uma instância de

SupervisorStrategy. No caso do código exemplo, foi escolhida a opção akka.actor.OneForOneStrategy.

Isso significa que a estratégia de recuperação será aplicada apenas no ator que lançou a exceção.

Para construir um objeto do tipo OneForOneStrategy devemos informar três parâmetros no construtor:

maxNrOfRetries (número máximo de tentativas de reinício do ator), withinTimeRange (intervalo entre a

primeira e a última tentativa de reinício) e decider.

Deixando de lado os dois primeiros parâmetros, o decider, ou decisor, deve ser uma implementação da

interface akka.japi.Function e possuir apenas o método chamado apply(), que recebe como parâmetro um

Throwable e retorna um akka.actor.SupervisorStrategy.Directive (explicado adiante).

Quando a aplicação estiver em execução e um determinado ator lançar uma exceção no processamento de

uma mensagem, o Akka irá executar o método apply() do objeto decider definido na estratégia do ator pai

passando como parâmetro a exceção lançada e obtendo como retorno uma diretiva a ser utilizada para tomar

a devida ação.

As diretivas podem ser do tipo:

· resume: Ignora a exceção atirada pelo ator supervisionado (filho). A mensagem simplesmente deixa de ser

processada e o ator continua processando normalmente outras mensagens;

restart: Reinicia o ator, conforme explicado anteriormente, na descrição do ciclo de vida do ator;

escalate: Repassa a decisão do que deve ser feito para o supervisor diretamente acima;

stop: Finaliza (mata) o ator.

Voltando a falar dos dois primeiros parâmetros da construção de OneForOneStrategy, são aplicáveis

somente à ação de restart. O primeiro parâmetro diz quantas vezes o ator pode ser reiniciado e o segundo

parâmetro diz em qual intervalo esta quantidade de reinícios pode acontecer.

Este tipo de estratégia faz sentido em situações de erros intermitentes, por exemplo, uma dependência de

uma conexão com o banco de dados. Caso este número seja ultrapassado no intervalo definido, o ator é

finalizado (morto) e as mensagens enviadas para ele são perdidas.

Modelando atores

15

Assim como qualquer paradigma de desenvolvimento, o modelo de atores tem as suas peculiaridades. Ao

desenvolver uma aplicação usando este modelo, devemos estruturar a aplicação em atores, considerando que

a comunicação entre eles é assíncrona e realizada através troca de mensagens. Depois de uma vida inteira

desenvolvendo aplicações com o modelo tradicional de concorrência, inicialmente este paradigma poderá

parecer um pouco confuso.

Para facilitar o aprendizado a respeito, existe uma grande quantidade de material na internet relacionada à

modelagem de atores, mas para ficar apenas no universo do Akka, uma boa referência é o site Let It Crash

[7], mantido pela comunidade. Este site possui trechos de código, artigos, discussões e outros conteúdos

relacionados ao desenvolvimento com Akka.

Próximos passos

Este artigo procurou introduzir os princípios básicos do paradigma de concorrência baseado em atores e o

framework Akka. Por esse motivo, ainda existe muito a ser explorado.

Pensando em facilitar os próximos passos, e direcionando nosso foco para o Akka, a seguir listamos os

tópicos mais importantes que o leitor pode se aprofundar:

· Mailbox: Apesar do Akka abstrair a existência deles, cada instância de ator possui uma caixa de

mensagens, ou mailbox. Existem vários tipos de customizações que podem ser feitas com este recurso, como

por exemplo, podemos criar uma caixa de mensagens para vários atores, balanceando o consumo, realizando

uma espécie de load balancing de processamento de mensagens;

· Dispatchers: São implementações de ExecutionContext que regem a criação das threads de

processamento de mensagens, schedulers e todo o funcionamento do framework. Também possui um alto

grau de customização;

· Persistência: É possível configurar o Akka para persistir o estado interno de um ator, inclusive o seu

mailbox. Sendo assim, caso a aplicação caia ou seja desligada indevidamente, no restart do container este

estado é recuperado. Este módulo ainda é experimental no Akka e foi introduzido na versão 2.3.0 do

framework;

· Extensões: O Akka oferece um mecanismo padrão para criar extensões. Com ele podemos atuar sobre

elementos centrais do framework, como o Actor system, para modificar o seu comportamento.

O modelo de concorrência baseado em threads e estado compartilhado tem atendido razoavelmente as

necessidades do mercado, porém, quando nos deparamos com o desafio de construir uma aplicação que

suporte alta concorrência e alta disponibilidade, é importante considerarmos um modelo baseado em

mensagens assíncronas.

No ecossistema do Java, o Akka é a ferramenta ideal para esta finalidade e tem se tornado mais completo a

cada release. Além de suas qualidades técnicas, é seguro apostar no Akka não apenas por tratar-se de uma

tecnologia suportada e mantida por uma empresa do porte da Typesafe, mas também por ser um excelente

framework, leve, bem estruturado, modular e muito fácil de escalar.

Links

[1] Página da API de concorrência do Java.

http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/package-

summary.html

http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/package-summary.html

http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/package-summary.html

16

[2] Documentação do Fork/Join framework.

http://docs.oracle.com/javase/tutorial/essential/concurrency/forkjoin.html

[3] Página principal do Akka.

http://akka.io

[4] Página da Amazon do livro Akka Concurrency, de Derek Wyatt.

http://www.amazon.com/Akka-Concurrency-Derek-Wyatt/dp/0981531660

[5] Página da linguagem de programação Erlang.

http://www.erlang.se

[6] Página de downloads do Akka.

http://akka.io/downloads/

[7] Página de um grupo de desenvolvedores da comunidade Akka.

http://letitcrash.com

http://docs.oracle.com/javase/tutorial/essential/concurrency/forkjoin.html

http://akka.io/

http://www.amazon.com/Akka-Concurrency-Derek-Wyatt/dp/0981531660

http://www.erlang.se/

http://akka.io/downloads/

http://letitcrash.com/

Documents

Akka programação concorrente