Так вот попробуй установить в http -> port правильный порт

Это странно

там 4000, на него и пытался коннектиться

закомментил указанную строку и все заработало

на линуксе такой проблемы не наблюдал...

Возвращение блудного сына

соскучился

Есть ли какое-нибудь решение для моей задачи или какая-нибудь алгоритмическая база? Собственно задача.

1 Общее описание
1.1 Есть источники производители тасков (имеется виду задания, которые едят некоторые ресурсы системы и хорошо бы их выполнить)
1.2 Есть процессы исполнители тасков
1.3 И прослойка между производителями и исполнителями, которая хранит данные, до востребования

2 Дополнительные условия
2.1 Известно, что все таски приоритезированы и число приоритетов не константа (то есть приоритет представлен действительным числом и соответственно их может быть бесконечно много)
2.2 Известно, что производители приносят в сотни раз больше, чем могут выполнить потребители
2.3 Известно, что таски имеют id и могут обновляться (то есть, от производителя может прилететь таск с тем же id, но с большим приоритетом, старый вариант следует удалить а новый записать)
2.4 Все задания восполнимы и рано или поздно производитель их снова пришлёт (а если и не пришлёт, то не страшно)

3 Что хочется сделать
3.1 Написать прослойку из пункта 1.3
3.2 Оптимизировать для записи по причине изложенной в 2.2
3.3 Предусмотреть вытеснение задач (я так вижу, что это приоритезированная очередь с заданной размерностью и если элемент вылетает за пределы, то он просто должен быть удалён)
3.4 Предусмотреть обновления из пункта 2.3

А что будет если выполнить таску с id = 1,  а потом создастся обновление таски с id = 1?
Обновления вообще меняют суть задачи, или только метаданные типа приоритета?

нет обновления только приоритет меняют, а саму задачу нет. Если задача выполнилась а потом прилетело обновление, то оно будет воспринято как новый таск. Я не конкретизировал этот момент, нет отдельного метода update производители не знают что падало на выполнение, а что нет

Для конечных множеств с линейным порядком есть структура данных как бинарная куча
В ней доступ к самому большому элементу за O(1), а запись нового элемента за O(log N)
Вытащить самый большой элемент тоже будет за O(log N)
Но вот доступ к произвольному элементу будет за O(N), но его можно распараллелить map reduce-ом простым

А так, вообще можно просто поддерживать дерево поиска
Тогда операции добавления/обновления/удаления будут за O(log N), а доступ к самому большому будет за O(N), но его можно распараллелить на все ядра

Так что смотри по количеству элементов и частоте обновлений. Если мало элементов и много обновлений, то лучше дерево. Если много элементов, но мало обновлений, то лучше кучу

И вопрос: зачем нужна такая очередь тасок, если они создаются чаще чем исполняются?

Для производителей не основная задача производить эти таски это скорее побочный эффект, они их создают просто потому что это ничего не стоит и таким образом максимизируют профит от "дорогих" задач, выполняются только самые приоритетные задачи найденные системой

Если оставить идею с вещественными числами, тогда точно нужно простое дерево поиска. Можно будет его даже как-нибудь экзотически балансировать, чтобы оптимизировать поиск, потому что основной доступ, как я понял, будет на запись тасок с низким приоритетом

Я так понял, что ещё будет просто куча задач до которых приоритет практически никогда не дойдёт, а они просто будут ждать обновления

Ну я бы тогда посоветовал разделить задачи на группы, а не от балды расставлять приоритеты вещественными числами
Создать группу приоритетных задач и её держать кучей
И создать группу неприоритетных задач, до которых если приоритет и дойдёт, то будет не важно в каком приоритете их исполнять, и держать её с быстрым доступом по ключу (дерево или хэшмапа), чтобы точечно вытаскивать некоторые в приоритетную кучу

хорошая идея, попробую так реализовать, спасибо

Кому нужен мануал рабочая темка с гифт картами

Я бы сделал два GenStage один консьюмил бы таски и складывал/обновлял в пг(монгу), второй выгребал и считал оттуда

@Virviil может ты уже совершишь экзекуцию?

Походу если можно спрогнозировать какие чиселки будут стоять в поле приоритет - все будет сильно проще

#вакансия #vacancy #elixir #office #remote #Москва #fulltime #developer  #разработчик
Международная социальная сеть                                                Город и адрес офиса: Москва, м. Парк Культуры
Формат работы: офис или удаленка
Занятость: полная
Зп: до 250 000 на руки
Команда: 4 Elixir, 4 Android, 4 IOS, 4 тестировщика                                                                                            👉Задачи:
• разработка микросервисов приложения
• работа с гео данными
• интеграция со сторонними сервисами
                                                                                                                                                                    👉Мы ожидаем от тебя:
• опыт работы с Elixir/OTP или Ruby от 2ух лет
• опыт работы с Phoenix framework
• опыт работы с No-SQL системами (Mongo и т.д), key-value(Redis и т.п.);
• опыт работы с брокером сообщений RabbitMQ
• опыт работы с контейнеризацией приложений Docker, Kubernetes
                                                                                                                                                                    👉Будет плюсом:
• способность максимально быстро и качественно решать поставленные задачи, ориентированность на результат;
• самостоятельность, ответственность, инициатива и внимание к деталям;
• гибкий и системный подход к решению сложных задач;
                                                                                                                                                                    👉 Условия:
• Офис в пешей доступности от Метро “Парк     Культуры“;
• Гибкий график. Начало работы с 8 до 11;
• Все необходимое для продуктивной работы: кофе, чай, и др.;
• Молодой, дружный коллектив;
• График работы: 5/2;
• Оформление по ТК РФ.                                                                   @Tatia_B