Estoy trabajando en una aplicación Django que permite a un usuario cargar archivos. Necesito realizar algún procesamiento del lado del servidor en estos archivos antes de enviarlos al Amazon S3. Después de leer las respuestas a this question y this blog post decidí que la mejor manera de manejar esto es hacer que mi controlador de vista invoque un método en el objeto remoto Pyro para realizar el proceso de forma asincrónica y luego devolver inmediatamente una Http 200 al cliente. Tengo este prototipo y parece funcionar bien, sin embargo, también me gustaría almacenar el estado del procesamiento para que el cliente pueda sondear la aplicación para ver si el archivo se ha procesado y cargado en S3.¿Cómo debo almacenar el estado de un proceso de larga ejecución invocado desde Django?
Puedo manejar el sondeo con la suficiente facilidad, pero no estoy seguro de dónde está la ubicación adecuada para almacenar el estado del proceso. Tiene que ser editable por el proceso Pyro y legible por mi vista de votación.
- Tengo dudas en agregar columnas a la base de datos para datos que realmente solo deberían durar de 30 a 60 segundos.
- He considerado utilizar low-level cache API de Django y usar una identificación de archivo como la clave, sin embargo, no creo que esto sea realmente para lo que está diseñado el marco de caché y no estoy seguro de qué problemas imprevistos podría haber con ir este ruta.
- Por último, he considerado almacenar estado en el objeto Pyro que realiza el procesamiento, pero aún parece que necesitaría agregar una columna de base de datos "processing_complete" booleana para que la vista sepa si consultar o no estado desde el Pyro objeto.
Por supuesto, también hay algunos problemas de integridad de datos con desacoplamiento de estado de la base de datos (lo que ocurre si el servidor se cae y todos estos datos es en memoria?). Voy a escuchar cómo los desarrolladores de aplicaciones web más experimentados podrían manejar este tipo de procesamiento con estado.
Después de pensar en esto de la noche a la mañana, he decidido que tienes toda la razón. Simplemente no tiene sentido no usar la base de datos. También he decidido que Pyro no encaja bien aquí y que debería hacer lo que hace la gente normal y usar un trabajo cron con un archivo de bloqueo. – bouvard
No usamos cron. Tenemos nuestro sistema por lotes como un pequeño servidor WSGI y hacemos una solicitud HTTP con urllib2 para reactivarlo. Obtiene el ID de solicitud de la solicitud de WSGI; obtiene los detalles con ordinario Django ORM. –
Esto es algo así como lo que planeé hacer con Pyro, pero el problema que preveo es que una interrupción repentina del servidor podría dejar los documentos medio procesados y no habría un nuevo mensaje de solicitud para reiniciar el procesamiento. Si utilizo un trabajo cron, sé que puedo simplemente elegir los 10 trabajos sin terminar de la tabla de Solicitud y retiraré los que hayan sido cortados durante la interrupción. – bouvard