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

Прежде чем мы разработаем наше собственное решение, я ищу какую-то библиотеку, которая обеспечивает:

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

С этими атрибутами:

  • Сохранение запросов, чтобы избежать его потери в случае:
    • Прерывание подключения к сети
    • Приложение quit, принудительное использование GC в фоновом приложении
    • и т.д..
  • Возможность выпускать все эти поля:
    • Адрес
    • Заголовки
    • Данные POST

Так что, пожалуйста, есть ли что-нибудь полезное, знаете ли, что может спасти нас целый день на этом?

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

Solutions Collecting From Web of "Неблокирующая очередь HTTP-запросов POST с сохранением"

По моему скромному мнению, хорошим и простым решением было бы разработать собственный слой (который не должен быть настолько сложным), используя сложную структуру для обработки соединений, такую ​​как 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 поверх своего ядра?

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

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

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

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

Фактически, вам нужен 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)

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

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

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

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

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

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

В основном подход, который работает для меня опытным образом – это отделить запросы от очереди и исполнителя. Запросы выполняются как 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/

Обновить:

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