Cola sin bloqueo de solicitudes HTTP POST con persistencia

En mi humilde opinión, una solución buena y directa sería desarrollar su propia capa (que no debería ser tan complicada) utilizando un sofisticado marco para el manejo de conexiones, como Netty https://netty.io/ , junto con un sofisticado Marco para el procesamiento asincrónico, como Akka http://akka.io/

Veamos primero el soporte de Netty para http en http://static.netty.io/3.5/guide/#architecture.8 :

4.3. Implementación de HTTP

HTTP es definitivamente el protocolo más popular en Internet. Ya hay varias implementaciones HTTP como un contenedor Servlet. Entonces, ¿por qué Netty tiene HTTP en la parte superior de su núcleo?

El soporte HTTP de Netty es muy diferente de las bibliotecas HTTP existentes. Le da un control completo sobre cómo los mensajes HTTP se intercambian a un nivel bajo. Debido a que es básicamente la combinación de un codec HTTP y clases de mensajes HTTP, no hay ninguna restricción, como un modelo de hilo forzado. Es decir, puede escribir su propio cliente HTTP o servidor que funciona exactamente de la manera que desea. Tiene control total sobre todo lo que está en la especificación HTTP, incluido el modelo de subprocesos, el ciclo de vida de la conexión y la codificación en trozos.

Y ahora vamos a cavar dentro de Akka . Akka es un framework que proporciona una excelente abstracción en la parte superior de Java API concurrente, y viene con API en Java o Scala.

• Proporciona una manera clara de estructurar su aplicación como una jerarquía de actores :
  • Los actores se comunican a través del paso del mensaje, usando el mensaje inmutable para que usted no tenga que preocuparse por la seguridad del hilo
  • Los mensajes de actores se almacenan en cuadros de mensaje, que pueden ser duraderos
  • Los actores son responsables de supervisar a sus hijos
  • Los actores pueden ejecutarse en una o más JVM y pueden comunicarse utilizando un gran número de protocolos
• Proporciona una abstracción ligera para el procesamiento asíncrono, Future , que es más fácil de usar que Java Futures.
• Proporciona otras cosas de lujo como Bus de Eventos, Adaptador ZeroMQ, Soporte Remoting, Concurrencia Dataflow, Scheduler

Una vez que te familiarices con los dos marcos, resulta que lo que necesitas se puede codificar fácilmente a través de ellos.

De hecho, lo que necesitas es un proxy http codificado en Netty, que tras una petición receival envía inmediatamente un mensaje a un Akka Actor de tipo FSM (http://doc.akka.io/docs/akka/2.0.2/java /fsm.html) que utiliza un buzón duradero (http://doc.akka.io/docs/akka/2.0.2/modules/durable-mailbox.html)

Aquí hay un enlace a la biblioteca de código abierto que era una tesis de maestro de un estudiante en la Universidad Técnica Checa en Praga. Es una biblioteca muy grande y poderosa y se centra principalmente en la ubicación. Lo bueno de esto, sin embargo, es que omitió los encabezados y otros – que REST tiene.

Es el último tenedor y con suerte le dará al menos inspiración para la solución "propia".

Cómo sobre esas colecciones concurrentes:

http://mcg.cs.tau.ac.il/projects/concurrent-data-structures

Espero que la licencia esté bien.

Usted querrá tener un vistazo a estos a los mensajes. (Añadido al final del documento)

Muy básicamente, un enfoque que funciona de manera proficiente para mí es separar las solicitudes de la cola y el ejecutor. Las solicitudes se ejecutan como Runnables o Callables. Heredar de ellos para crear diferentes tipos de solicitudes a su API o servicio. Configurarlos allí agregando encabezados y / o cuerpo antes de ejecutarlos.

Enqueue esas peticiones en una cola (elija cuál encaja mejor para usted – diría que LinkedBlockingQueue hará el trabajo) vinculado a un ejecutor desde dentro de un servicio enlazado y llamándolos desde su actividad o cualquier otro ámbito. Si no necesita obtener respuestas y devoluciones de llamada, puede evitar usar Guava para escuchar futuros o crear sus propias devoluciones de llamada.

Me quedaré atento. Si necesita más profundidad puedo publicar algunas piezas específicas de código. No es la fuente de un ejemplo básico en el primer enlace sin embargo.

http://ugiagonzalez.com/2012/08/03/using-runnables-queues-and-executors-to-perform-tasks-in-background-threads-in-android/

http://ugiagonzalez.com/2012/07/02/theres-life-after-asynctasks-in-android/

Actualizar:

Puede crear otra cola para las solicitudes que eran imposibles de ejecutar. Un acercamiento que viene a mi mente sería agregar todas sus peticiones falladas a la cola del retry. La cola de reintentos estaría tratando de volver a ejecutar estas tareas mientras el teléfono todavía piensa que hay cualquier tipo de conexión a Internet disponible. En el objeto de la petición usted puede fijar un número máximo de retrials y compararlo a un número currentRetry que lo aumenta en cada nuevo ensayo. Mmm esto podría ser interesante. Definitivamente pienso en incluir eso en mi biblioteca.