Scheduler do Web2py rodando no Apache

[Gustavo Souza]

Pessoal, estou precisando de uma ajudinha.

Estou querendo utilizar a funcionalidade scheduler do Web2py rodando no Apache. Eu sei que é uma funcionalidade experimental, mas gostaria de testar em minha aplicação para fazer uma rotina ao invés de usar o CRON do Linux. E a minha dúvida é como fazer isso juntamente com o Apache.

Alguém tem alguma dica para compartilhar?

Abração!

--
Gustavo de Souza Lima

Web Developer Agência X4
@dodilei
tech4noobs.x4ids.com.br/

Ubuntu --> Fedora --> ArchLinux :)

[Bruno Rocha]

O scheduler roda independente do webserver, ele não utiliza o apache pois roda direto no shell, você só precisa ter acesso ao shell do servidor (e tem que ser linux)

Além do scheduller é possivel criar uma queue simples com python puro, mas o scheduler é a melhor solução.

Dá uma olhada na documentação que está na propria classe do scheduler que dá para entender direitinho como rodar.

Mas roda-lo no apache não acredito ser possivel, mas o uWSGI tem uma queue propria, se você estiver utilizando uWSGI poderá agendar tarefas direto nele.

2012/2/15 Gustavo Souza <gus...@agenciax4.com.br>

--
Você recebeu essa mensagem por estar inscrito no grupo web2py-users-brazil.
Para enviar uma mensagem ao grupo, envie email a: web2py-us...@googlegroups.com
Para se desinscrever, envie email a: web2py-users-br...@googlegroups.com
Para mais opções, visite o site do grupo em: http://groups.google.com/group/web2py-users-brazil?hl=en

--

Bruno Rocha

[http://rochacbruno.com.br]

[Gustavo Souza]

Oie Bruno... valeu pela resposta!

Eu uso o WSGI sim rodando no Apache.

Mas corrija-me se me confundi, então quer dizer que eu posso agendar uma tarefa de 3 formas?

1 - Através de código python puro.

2 - Através do Scheduler.

3 - Queue do WSGI

Se é assim acredito que o Scheduler é a melhor forma mesmo. Posso criar um script pra startar no boot do Linux e ficar sempre ativo.

Obrigado!

[Bruno Rocha]

A vantagem do scheduler é o tratamento de erros, fallback e status que ficam no banco de dados, basta ter acesso ao shell da maquina e executar o scheduler em um terminal ou colocar para rodar em background.

Outra possibilidade é usar uma queue em Python e ai vc mesmo a controla. tipo isso:

Sending messages using a background task

The operation of sending an email message can take up to several seconds because of the need to log into and communicate with a potentially remote SMTP server. To keep the user from having to wait for the send operation to complete, it is sometimes desirable to queue the email to be sent at a later time via a background task. As described in Chapter 4, this can be done by setting up a homemade task queue or using the web2py scheduler. Here we provide an example using a homemade task queue.

First, in a model file within our application, we set up a database model to store our email queue:

1. 2. 3. 4. 5.

db.define_table('queue', Field('status'), Field('email'), Field('subject'), Field('message'))

From a controller, we can then enqueue messages to be sent by:

1. 2. 3. 4.

db.queue.insert(status='pending', email='y...@example.com', subject='test', message='test')

Next, we need a background processing script that reads the queue and sends the emails:

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

## in file /app/private/mail_queue.py import time while True: rows = db(db.queue.status=='pending').select() for row in rows: if mail.send(to=row.email, subject=row.subject, message=row.message): row.update_record(status='sent') else: row.update_record(status='failed') db.commit() time.sleep(60) # check every minute

Finally, as described in Chapter 4, we need to run the mail_queue.py script as if it were inside a controller in our app:

1.	python web2py.py -S app -M -N -R applications/app/private/mail_queue.py

where -S app tells web2py to run "mail_queue.py" as "app", -M tells web2py to execute models, and -N tells web2py not to run cron.

[Vinicius Assef]

Bruno, no caso de usar o SQLite para essa solução, teríamos problemas de lock de arquivo, certo?

Haveriam 2 processos:

1) o site, engordando a fila de emails a serem enviados.

2) o processo em background esvaziando-a.

Caso haja coincidência de concorrência no momento da atualização, o SQLite retornaria um erro de database locked, ou algo do tipo. Não lembro de cabeça a exceção.

Portanto, o scheduler não seria recomendado para usar com o SQLite?

--

Vinicius Assef

[Bruno Rocha]

atualmente uso o queue via Python puro no Movu.ca

Os emails de notificação estão bem rápidos e sem problemas.

Estou para implementar uma versão do motor de notificações com o scheduler.

O sqlite está aguentando muito bem!

O sql3 foi otimizado para concorrência, mas de qualquer modo existe o lock. Porém o que ocorre é que muitos podem ler e escrever ao mesmo tempo (porém em registros diferentes)

O sqlite3 agora cria uns arquivos .shadow que são ocultos, é como um buffer temporário, por transaction, quando vc escreve na verdade tá operando neste arquivo e ai no commit ele tenta jogar isso pra dentro do banco, se estiver com lock ele tenta de novo depois. (mas tem uma inteligência extra ai para checar timestamp etc...)

http://movu.ca/demo - 100% sqlite, 2 bancos.

http://miaudota.com.br - sqlite

http://cursodeputhon.com.br (tem o campus onde os alunos interagem) -  sqlite

rodo sqlite em mais duas apps de intranet em um cliente.

O sqlite tem me surpreendido por ainda não ter dado nenhum problema com concorrência.

Mas claro que indico o uso do Postgres, mas o sqlite não é tão ruim assim. :)

http://zerp.ly/rochacbruno

[Vinicius Assef]

Pois é. Eu tenho conseguido ótimos resultados com SQLite num banco com cerca de 100k registros em uma tabela e 50k em outra, rodando o servidor do webp2y, num servidor Windows.

Mas isso com apenas uma instância atualizando.

O problema do SQLite não é a concorrência de usuários, mas de processos. Daí vem o lock. Quando falamos em app web, só há um processo atualizando. Então tudo fica tranquilo.

Não estou certo que vários usuários podem escrever ao mesmo tempo num BD SQLite. Conforme esse FAQ[1], somente um processo pode fazer isso, num dado momento.

[1] http://sqlite.org/faq.html#q5

Abraço.

--

Vinicius Assef

2012/2/16 Bruno Rocha <rocha...@gmail.com>

[Bruno Rocha]

2012/2/16 Vinicius Assef <vinic...@gmail.com>

O problema do SQLite não é a concorrência de usuários, mas de processos. Daí vem o lock. Quando falamos em app web, só há um processo atualizando. Então tudo fica tranquilo.

Na verdade vc pode ter mais de um processo, no NGINX e especialmente em servers como cherokee, tornado... no caso do nginx + uwsgi ele levanta 4 processos por default se não me engano.

no caso do queue além dos processos do webserver ainda tem o processo separado que está rodando o queue.

mesmo assim o sistema de lock + tempfile do sqlite parecem dar um jeito.

Obvio que não vou rodar sqlite quando colocar o sistema em produção, mas mesmo assim surpreende.