Неблокирующая очередь запросов HTTP POST с сохранением

Ответ 1

По моему скромному мнению, хорошим и простым решением было бы разработать свой собственный слой (который не должен быть настолько сложным), используя сложную структуру для обработки соединений, такую ​​как Netty https://netty.io/ вместе со сложной структурой для асинхронной обработки, например Akka http://akka.io/

Сначала загляните внутрь Netty для http на http://static.netty.io/3.5/guide/#architecture.8:

4,3. Выполнение HTTP

HTTP - это, безусловно, самый популярный протокол в Интернете. Уже существует ряд реализаций HTTP, таких как контейнер Servlet. Тогда почему Netty имеет HTTP поверх своего ядра?

Поддержка Netty HTTP очень отличается от существующих HTTP-библиотек. Это дает вам полный контроль над тем, как HTTP-сообщения обмениваются на низком уровне. Поскольку это в основном комбинация классов HTTP-кодеков и HTTP-сообщений, нет никаких ограничений, таких как модель принудительного потока. То есть вы можете написать собственный HTTP-клиент или сервер, который работает именно так, как вы хотите. Вы полностью контролируете все, что указано в спецификации HTTP, включая модель потока, жизненный цикл соединения и закодированное кодирование.

А теперь отпустите внутри Akka. Akka - это основа, которая обеспечивает превосходную абстракцию в верхней части Java-совместимого API, и поставляется с API на Java или Scala.

• Он предоставляет вам четкий способ структурировать ваше приложение как иерархию участников:
  • Актеры обмениваются сообщениями, используя неизменяемое сообщение, чтобы вы не заботились о безопасности потоков
  • Сообщения участников хранятся в ящиках сообщений, которые могут быть долговечными
  • Актеры отвечают за надзор за своими детьми.
  • Актеры могут запускаться на одной или нескольких JVM и могут взаимодействовать с использованием большого количества протоколов.
• Он обеспечивает легкую абстракцию для асинхронной обработки, Будущее, которое проще использовать тогда Java Futures.
• Он предоставляет другие интересные вещи, такие как Event Bus, адаптер ZeroMQ, поддержка Remoting, Dataflow concurrency, планировщик

Как только вы познакомитесь с двумя фреймворками, выяснится, что то, что вам нужно, легко может быть закодировано через них.

Фактически, вам нужен HTTP-прокси, закодированный в Netty, который после получения запроса немедленно отправляет сообщение Акку Акка типа FSM (http://doc.akka.io/docs/akka/2.0.2/java/fsm.html), который использует долговечный почтовый ящик (http://doc.akka.io/docs/akka/2.0.2/modules/durable-mailbox.html)

Ответ 2

Здесь - ссылка на библиотеку с открытым исходным кодом, которая была магистерской диссертацией в Чешском техническом университете в Праге. Это очень большая и мощная библиотека и в основном фокусируется на местоположении. Хорошая вещь об этом, однако, заключается в том, что она опускала заголовки и другие, - что у REST есть.

Это последняя версия, и, надеюсь, это даст вам хотя бы вдохновение для "собственного" решения.

Ответ 3

как насчет этих параллельных коллекций:

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

Я надеюсь, что лицензия в порядке.

Ответ 4

Вы хотите посмотреть на них на сообщения. (добавлено в конце документа)

В основном подход, который работает для меня, - это отделить запросы от очереди и исполнителя. Запросы выполняются как Runnables или Callables. Наследовать от них, чтобы создавать разные запросы к вашему API или сервису. Установите их там, добавляя заголовки и или тело до их выполнения.

Завершите эти запросы в очереди (выберите, который лучше подходит для вас - я бы сказал, LinkedBlockingQueue сделает работу) связанной с исполнителя из связанной службы и вызова их из вашей деятельности или любой другой области. Если вам не нужны ответы и обратные вызовы, вы можете избежать использования Guava для прослушивания фьючерсов или создания собственных обратных вызовов.

Я останусь настроенным. Если вам нужна дополнительная глубина, я могу опубликовать некоторые конкретные фрагменты кода. Там источник основного примера в первой ссылке, хотя.

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/

Update:

Вы можете создать очередную очередь для тех запросов, которые невозможно выполнить. Один из подходов, который приходит мне на ум, заключается в том, чтобы добавить все неудавшиеся запросы в очередь повторов. В очереди повторных попыток повторите запуск этих задач, пока телефон по-прежнему считает, что существует какое-либо доступное интернет-соединение. В объекте запроса вы можете установить максимальное количество повторных попыток и сравнить его с номером currentRetry, увеличивающим его при каждом повторном просмотре. Ммм, это может быть интересно. Я обязательно подумаю о том, чтобы включить это в мою библиотеку.