Guax

A alguns dias atrás me debati com um problema na compilação do asterisk nas versões 13.1+ do Slackware Linux. Esse problema era causado por um negligência dos desenvolvedores ao linkar os módulos que fazem uso da libcap que causava o seguinte erro ao carrega-los:

[Nov 14 14:05:16] WARNING[3840]: loader.c:433 load_dynamic_module: Error loading module 'res_agi.so': /usr/lib/asterisk/modules/res_agi.so: undefined symbol: cap_set_proc

Apesar da compilação ser feita com sucesso por conta do link ser feito no binário “asterisk” os módulos não são carregados com sucesso. Com o slackware manteve a biblioteca estática no sistema em /usr/lib/libcap.a e este diretório é procurado antes que o /lib pelo GCC na hora de linkar o problema acaba por ocorrer. O certo seria que na compilação dos módulos que fazem uso da libcap estes fossem linkado com o parâmetro -lcap.

A correção mais rápida, fácil e inelegante desse problema é mover a libcap.a para um diretório temporário fora do caminho do linker, compilar o asterisk e devolver ao seu diretório. Para conferir se o seu binário do asterisk foi linkado corretamente com a biblioteca dinâmica da libcap basta usar o comando ldd /usr/sbin/asterisk, o retorno deverá ser semelhante a:

        linux-gate.so.1 =>  (0xffffe000)
        libdl.so.2 => /lib/libdl.so.2 (0xb76f2000)
        libcap.so.2 => /lib/libcap.so.2 (0xb76ed000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb76d4000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0xb76d0000)
        libm.so.6 => /lib/libm.so.6 (0xb76a9000)
        libresolv.so.2 => /lib/libresolv.so.2 (0xb7692000)
        libc.so.6 => /lib/libc.so.6 (0xb752f000)
        /lib/ld-linux.so.2 (0xb7724000)
        libattr.so.1 => /lib/libattr.so.1 (0xb752a000)

Caso não tenha dado certo o resultado será semelhante a:

        linux-gate.so.1 =>  (0xffffe000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7797000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb777e000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0xb777a000)
        libm.so.6 => /lib/libm.so.6 (0xb7754000)
        libresolv.so.2 => /lib/libresolv.so.2 (0xb773c000)
        libc.so.6 => /lib/libc.so.6 (0xb75d9000)
        /lib/ld-linux.so.2 (0xb77b0000)

Uma anedota de como o Asterisk se transformou de nossa melhor solução para nosso maior problema num período de menos de 2 anos.

No começo tudo eram flores, as centrais eram instaladas na mão e configuradas com carinho e atenção digno de um artista brincando com uma tela. Esse foi o primeiro grande problema quando estávamos tentando crescer a base instalada e aumentar a estabilidade ao longo de todos os sistemas, o erro aqui não era do Asterisk, mas nosso em acreditar que ele era um pbx. Não é, o asterisk não é mais do que uma plataforma para a construção de soluções de telefonia. Ele é a base dos PBX e não este em si.

Após criarmos uma visão de produto e implementar tudo aquilo que nos faltava, conseguimos maior estabilidade e sincronismo entre as centrais. Nos batemos então com um problema básico e que já foi fonte de reclamações nesse blog a alguns meses atrás. CDR e Transferências. A arquitetura interna do asterisk não possui uma thread para cada canal de ligação, isso faz com que uma “magia negra”, como descrito pelos desenvolvedores, seja necessária para que as transferências sejam possíveis: o maskerading. O fato do plano de discagem do asterisk ser baseado em contexto e não em eventos faz com que as aplicações só possam ser executadas no canal que é dono do fluxo atual da ligação. Isso impede por exemplo que uma gravação seja feita em sua totalidade caso haja uma transferência feita pelo originador da chamada e também impede que o log das ligações seja registrados corretamente no banco de dados.

Nesse ponto, nossa especialidade estava em trabalhar com o Asterisk vanilla usando suas APIs públicas para implementar nossas soluções. Com isso se tornou comum as famigeradas “gambiarras” no código e na configuração do Asterisk para que esses problemas fossem contornados. A solução de software que nos permitiu criar toda uma familia de produtos se tornou agora nosso calcanhar de Aquiles pois as limitações delas agora estão se sobressaindo sobre as nossas próprias.

Esse é o ponto onde estou no momento em que escrevi o texto. Agora começa a batalha para correção desses problemas no próprio Asterisk ou na substituição do mesmo por softwares com outra abordagem como o FreeSWITCH.

Tudo que tenho a dizer sobre o Visual Web JSF está representado nesta imagem:

Sabe das coisas esse capitão.

Python Threads

Certo dia estava eu a pensar sobre a vida o universo e tudo mais e antes que 42 viesse a minha mente foi pedido que eu implementasse um disparador de SMS’s. Para isso eu precisava fazer disparos simultâneos em X canais gsm. Requisito óbvio: preciso de threads. PHP, a linguagem que usamos para quase tudo na aplicação não tem um suporte bom a threads então fui atrás de outra linguagem para o fazer.

Python atravessou meu caminho e nas minhas brincadeiras com a cobra (ui!) eu apanhei, jesus sabe que eu apanhei dessa pseudo-linguagem medonha e caracu (eu xinguei de coisa pior enquanto era humilhado pela até então ignorância na linguagem). Eu apanhei por que o mau costume de só ter usado Java (pausa para uivos e pedras….) para trabalhar com threads me deixou preguiçoso e mau acostumado a uma declaração bem mais simples de sincronismo entre métodos, bastava um synchronized e tudo estava funcionando.

Python ao contrário de Java não é nada thread-safe. Todas as chamadas simples podem ser desastrosas se mexem com recursos compartilhados entre as threads.

Sincronizando

Já que a python não é thread-safe temos que assumir essa responsabilidade no lugar da linguagem e sincronizar as chamadas com Locks, Semáforos e afins. Não é o fim do mundo, mas que é chato, é. Se quizermos por exemplo fazer a inserção de dados no banco de dados e ter o resultado disso logo após cada insert devemos sincronizar os inserts e commits já que o componente MySQLdb não faz esse controle para nós.

class Inserter(object):
    def __init__(self, lck,db):
        self.lock = lck;
        self.db = db

    def insert(self, insert):
        cursor = self.db.cursor()
        try:
            self.lock.acquire()
            cursor.execute(insert)
            cursor.execute("commit")
        finally:
            self.lock.release()

Queue

Outro componente muito útil quando se utiliza threads são as Filas. Filas são fifos (first-in first-out) que enfileiram ações que você gostaria que fossem executadas em paralelo por threads ou que simplesmente sejam executadas em determinada ordem.

# Importamos o módulo
from Queue import Queue

def run(self):
        while True:
            try:
                self.lock.acquire();
                if self.fila.empty():
                    break
                item = self.fila.get()
            finally:
                self.lock.release()

            self.printer.imprime(item)

Uma nota sobre Filas é que não se deve usar um if not queue.empty() e depois tentar dar um queue.get() já que no tempo entre esses dois acessos aos métodos outra thread pode pegar o ultimo elemento. É necessário que você simplesmente pegue o elemento e trate a exceção ou use Lock nessa parte do método.

ps. estranho, mas python implementa LIFO (pilha) no modulo Queue.