Posts Tagged ‘java’

Os três principais problemas da Concorrência

Wednesday, September 21st, 2011

Ultimamente se tornou inevitável desenvolver programas que funcionam de maneira concorrente, já que os processadores com multiplos cores já estão em todo lugar, até mesmo nos celulares. E ao mesmo tempo que é extremamente prazeroso ver o seu software muito mais rápido graças a concorrência, também se pode perder muitas noites de sono com os problemas causados por erros no desenvolvimento de software concorrente. Neste post eu pretendo falar de maneira breve dos três principais problemas que podem surgir quando se desenvolve software concorrente. São eles: Starvation, Deadlocks e Race Conditions.

Starvation

Starvation ocorre quando uma thread fica esperando uma resposta pra prosseguir e essa resposta nunca chega, logo, a thread permanece viva, ocupando recursos, mas não produzindo nada de útil para o software. Uma boa forma de tratar esse problema é sempre trabalhar com timeout e fluxo de exceção, para que caso a resposta não chegue em um determinado tempo seja seguido o fluxo de exceção e a thread possa finalizar o seu trabalho.

Deadlocks

Deadlock ocorre se duas ou mais threads ficam aguardando uma a outra para realizar alguma ação ou liberar algum recurso, por exemplo, a thread A ficar aguardando a thread B liberar algum recurso e B ficar aguardando A terminar alguma ação pra liberar esse recurso, logo, ambas vão permanecer eternamente esperando. Não existe uma solução simples pra resolver esse problema como o timeout para o problema de Starvation, mas se a aplicação não possuir locks explicitos e estados mutáveis então ela estará a salvo de deadlocks, então esse pode ser um bom caminho a se seguir.

Race Conditions

Race Condition ocorre se duas threads concorrem para usar o mesmo recurso ou dado. É um problema bem difícil de tratar pois o comportamento da aplicação se torna imprevisível e uma Race Condition pode ocorrer depois de meses do software em produção. Pra piorar, este problema não ocorre apenas quando duas threads tentam modificar o mesmo dado, ele pode correr quando uma thread tenta gravar um dado e a outra está tentando apenas ler este mesmo dado. Pra piorar ainda mais, existem casos aonde se o código não é otimizado com O JIT(Just In Time) Compiler a Race Condition não aparece, mas se o código é elegível ao JIT e é compilado então a Race Condition surge, basicamente porque a JVM passa a usar cache para acessar algumas variáveis e se outra thread muda o valor da variável, esse valor não é replicado para o cache. Neste caso citado a solução seria usar volatile e/ou synchronized.

Novamente não usar objetos mutáveis evitaria o problema de Race Conditions, por isso que imutabilidade tem sido um tema tão comentado ultimamente, e linguagens que pregam essa técnica tem ganhado cada vez mais força.

Para se aprofundar mais no assunto, inclusive com um código de exemplo que mostra uma Race Condition causada pelo JIT, recomendo a leitura do livro “Programming Concurrency on the JVM”.

Tags: ,
Posted in java, programação | No Comments »

O que esperar das linguagens de programação para o futuro?

Saturday, July 24th, 2010

Dizem que os melhores perfumes são aqueles que estão nos menores frascos. Ao menos pelo show que o Rod Pike do Google deu quando falou no OSCON 2010, parece que isso vale para palestras também. Foram doze minutos e meio de um conteúdo riquissímo pra fazer qualquer programador refletir.

Nesta palestra, o Rod tentou mostrar como as principais linguagens que dominam o mercado hoje são burocráticas e chatas de trabalhar. Ele deixa claro que são linguagens robustas e de qualidade, isso é um fato inquestionável, mas elas podiam ser mais amigáveis.

O Rod usou a conhecida do frase do Norvig que diz “patterns are a a demonstration of weakness in a language” para embassar seus argumentos, e também não deixou de mostrar muitos códigos para comprovar o quão verboso é fazer algumas coisas em linguagens como o Java por exemplo. Além disso, também foi falado que o hardware evoluiu muito esses últimos anos, hoje em dia qualquer um tem um computador com dois cores no mínimo, mas nas linguagens de programação tradicionais por assim dizer, não é nada trivial fazer uso deste poder.

Após mostrar todos esses pontos, o Rod expõe quais são os objetivos das linguagens de programação para o futuro. Ou seja, o que precisa ser feito para que elas se tornem melhores, e no final, puxa um pouquinho a sardinha pro lado dele, falando um pouco da Go, a linguagem de programação do Google.

Um fato importante é que para conseguir ver tudo isso que o Rod viu e falou, é preciso pensar fora da caixa como dizem por aí, e aprender novas linguagens de programação. Eu atualmente tenho dado uma olhada mais profunda em duas: Python e Haskell, e não estou me arrependendo. O pessoal pode falar: “Mas aonde você vai usar Haskell profissionalmente?”. Bom, talvez eu nunca use Haskell profissionalmente, mas com certeza seja qual for a linguagem que eu trabalhar, aprender Haskell e programação funcional me tornará um programador melhor.

Enfim, para quem ainda não viu, não deixe de ver essa palestra. E viva a internet, aonde você consegue ter acesso a uma palestra de um evento de fora do país quase que no mesmo dia em que a palestra foi dada.

Tags: , , ,
Posted in programação | No Comments »

Scheduler do JBoss rodando uma hora depois do configurado

Friday, June 12th, 2009

Nós passamos por um problema curioso no projeto que eu estou trabalhando aqui no UOL. Nós tinhamos
um processo batch que estava configurado para rodar todos os dias as 3:00 da manhã. Esse processo
batch era iniciado via scheduler do Jboss. O problema é que surpreendentemente o processo ao invez
de rodar as 3:00 da manhã, começpi a rodar as 4:00 da manhã sem nenhum motivo aparente.

A configuração estava feita da seguinte forma:

<mbean code="org.jboss.varia.scheduler.Scheduler"
name="jboss.docs:service=MyScheduler">
<attribute name="TimerName">jboss:service=MyTimer</attribute>
<attribute name="SchedulableClass">br.com.uol.MyScheduler</attribute>
<attribute name="StartAtStartup">true</attribute>
<attribute name="DateFormat">dd/MM/yyyy HH:mm</attribute>
<attribute name="InitialStartDate">01/01/2006 03:00</attribute>
<attribute name="SchedulePeriod">86400000</attribute><!-- Roda uma vez por dia -->
<attribute name="InitialRepetitions">-1</attribute>
<depends>administration:custom=MyJMX</depends>
<depends>
<mbean code="javax.management.timer.Timer"
name="jboss:service=MyTimer"/>
</depends>

</mbean>

Foram levantadas hipóteses que o horário da máquina estava configurado errado, que o timezone estava errado, que
o horário de verão estava configurado errado etc. A gente investigou uma por uma e tudo estava OK.

Até que começou a fase do desespero, de começar a etapa de tentar resolver o problema por tentativa e erro, e dessa
forma, descobrimos o problema.

Por uma razão desconhecida, se o campo “InitialStartDate” é configurado para alguma data dentro do horário de verão,
ele só inicia no horário correto quando estamos no horário de verão. Para resolver esse problema, nós apelamos
e mudamos este campo para 01/09/2006, e finalmente o scheduler começou a rodar conforme esperado, as 3:00 da manhã.

Fica aí a dica para caso alguém também passe por este problema. A versão do JBoss usada é 4.0.4_GA.

É impressionante como horário de verão sempre traz problemas, mesmo a cada ano a gente cercando cada vez mais, sempre
tem algum efeito colateral!

[]‘s e até a próxima.

Tags: ,
Posted in java, jboss | 1 Comment »

Mensagens JMS agendadas Just-In-Time

Monday, August 25th, 2008

Uma feature muito legal de mensagens JMS é a possibilidade de poder agendar quando uma mensagem deverá ser recebida pelo MDB. Eu não sei se isso faz parte da especificação, ou se apenas o JBoss possui isso. O exemplo que eu vou demonstrar funciona apenas para o JBoss.

Primeiro vamos a um cenário onde este agendamento é útil.

Vamos supor que a seguinte regra é solicitada: Ao tentarmos cobrar o cartão do cliente, se a operadora retornar transação negada, o sistema deve re-tentar cobrar este cartão por mais 2 dias, sendo que cada tentativa deve ser feita após 24hs.

É possível resolver este requisito usando banco de dados e as famosas flags, mas essa definitivamente não é uma solução elegante. Imagina que você precisaria ficar fazendo pooling no banco para ver quais cobranças já passaram de 24 horas para processa-las novamente. Ou seja, horrível.

Com JMS dá pra fazer algo muito melhor. Se quando a compra é feita, retornar negado, basta enviar uma mensagem JMS pra fila, agendando essa mensagem para ser processada apenas após 24 horas. Quando der essas 24hhs, o MDB lê a mensagem e chama novamente o módulo de cobrança.

Muito simples e elegante. Sem pooling, sem ficar controlando status manualmente, nem nada desse tipo.

O código para fazer isso é extremamente simples:

[sourcecode language='java']
ObjectMessage message = session.createObjectMessage();

message.setLongProperty("JMS_JBOSS_SCHEDULED_DELIVERY", (new Date().getTime() + (1000 * 60 * 60 * 24)));[/sourcecode]

Pronto, você acabou de agendar a entrega da sua mensagem para daqui a 24 horas. Essa conta maluca aí é porque a data precisa ser passada em milisegundos. :-)

Eu sou um grande fã de JMS, e essa é mais uma das caracteristicas que me fazem gostar dessa tecnologia.

[]'s

Tags: , ,
Posted in java, jboss | 3 Comments »

Contendo falhas de forma elegante com auxílio de JMS

Wednesday, July 2nd, 2008

JMS é uma API do Java para lidar com troca de mensagens em aplicações. Devido a popularização da integração de sistemas por meio de mensagens, seu uso tem aumentado muito nos últimos tempos, principalmente pelo fato de ser extremamente simples integrar dois sistemas usando JMS. Porém, neste post, pretendo falar de uma outra utilidade muito interessante de JMS, a qual adotamos no último projeto que participei e que deu um resultado muito positivo para o sistema aumentando significativamente a sua robustez.

Tinhamos o seguinte cenário:

“É tentado cobrar um determinado valor do cartão de crédito do cliente, caso a operadora retorne OK, ou seja, a compra foi executada com sucesso, deve ser chamada uma API aqui da empresa que autoriza o cliente a usar o nosso sistema”

Agora pense na seguinte situação: O cliente é cobrado, debita o valor do seu cartão de crédito, mas quando
a API de autorização é chamada, acontece um erro e o cliente não é liberado para usar o sistema. O que fazer neste caso? Rollback da transação??? ahmmmm…não existe rollback na operadora de cartão de crédito! :-( Mas mesmo se tivesse, ao meu ver essa não seria a solução ideal, afinal de contas, você perderia uma “venda”.

É aí que entra JMS e o título do post: “Contendo falhas de forma elegante”.

Nós adotamos a seguinte solução para este caso: Quando a operadora cobra o cliente, não há mais como voltar atrás, então, até esse ponto é fluxo é sincrono e, a autorização se tornou um fluxo assincrono. Com isso, foi criada uma  fila JMS e o cliente é colocado nesta fila para ser autorizado. A grande vantagem disso é que, em caso de um problema, a API do JMS possui uma propriedade configurável que faz com que ele retente processar de tempos em tempos. Com isso, caso o sistema não consiga autorizar o cliente na primeira vez, ele vai tentar novamente após 30 minutos, até 10 tentativas. Tempo suficiente para, se for um problema de banco por exemplo, o problema ser corrigido.

Mas não acaba aí, no JMS existe um conceito chamado “fila morta”. Caso após as 10 tentativas, o sistema não consiga processar aquela tarefa, ela será enviada para está fila. No nosso sistema, foi criada uma monitoração nesta fila. Caso algum registro caia na famigerada “fila morta”, o sistema irá alarmar e uma equipe responsável entrará em ação para solucionar o problema e após isso, reprocessar o registro.

Com isso, é possível uma ação totalmente pró-ativa, evitando assim chamadas na “Central de Atendimento” de clientes que pagaram e não receberam autorização para acessar o sistema.

Na nossa experiência aqui na empresa, JMS tem se mostrado uma excelente solução, tanto pela sua facilidade de uso com o auxílio de um servidor de aplicação, como o Jboss por exemplo, como também pela elegância e robustez que ele prove no seu uso.

Recomendo a todos os programadores Java a se aprofundarem neste assunto!

Um abraço!

Tags: ,
Posted in java | 3 Comments »

Cuidados com o uso de enum no Java

Thursday, June 26th, 2008

É preciso tomar cuidado quando você está usando uma enum como retorno de um Session Bean. Tanto o servidor quanto o cliente precisam estar sempre com a mesma versão da enum. Caso você altere a enum do lado do servidor, mas não mudar a versão que está no cliente, se por um acaso a constante que você adicionou no enum for a retornada pelo Session Bean, subirá uma exceção no cliente. Não existe nada parecido com o conceito de serialVersionUid com o uso de enums.

Por um lado, essa característica é boa, pois força o seu cliente a sempre estar com a mesma versão da que está rodando no servidor. Mas, por outro lado, as vezes você quer adicionar uma constante ao seu enum, que em nada interfirá na maioria dos sistemas que estão usando o seu. Por exemplo:

-Um determinado sistema trata retornos com status PAGO e NÂO_PAGO.

Você quer adicionar um novo status de ANALISE na sua enum. Em tese, esse status não interessa para o sistema descrito acima, então, caso ele receba esse status ele poderia simplesmente ignora-lo. Mas com enum isso não é possível. Ou seja, se você tem 50 sistemas usuários do seu, e quer adicionar um novo status que só interessa para um deles, você é obrigado a forçar os 50 sistemas a atualizarem a versão “client” que receberam do seu.

Tags:
Posted in java | No Comments »