Русскоязычный

https://en.wikipedia.org/wiki/InterPlanetary_File_System
этот ipfs ?

Ага

В райдер чуть-чуть поддержки пакета насыпят
https://youtrack.jetbrains.com/issue/RIDER-552#focus=Comments-27-4376905.0-0

Возник сценарий, в котором требуется at-least-one-delivery, пообщался с Аароном на этот счет в гиттере Акки (https://gitter.im/akkadotnet/akka.net), но остался осадочек от использования event store для таких временных вещей как посылаемое сообщение. Да, технически нет проблем бросать его в event journal с возможностью последующей очистки журнала от того, что ушло. Но осадочек остается от того, что чистим event store, который по идее не должен мутировать никогда. Вот сижу и думаю, может вообще этот сценарий из акки вынести, но тоже некрасиво получается.

Я такое делал на акке. Была задача во что бы то ни стало получать инфу с машин на сервер.

Был локальный сторадж (sqllite) на клиенте, куда данные сливались в шифрованном виде. При появлении интернета (могло случиться раз в неделю) актор, который постоянно пинговал сервер, просыпался и начинал засылать на сервер по кусочкам.
После получения акноледжа от сервера, кусочек удалялся из локального стораджа и мы посылали следующий.

На таймауте или ошибке ретрай до упора

Ну то есть в sqlite не журнал событий акки хранился, а просто временное состояние?

Ага.

Если интернет был стабильный, то sqllite даже не наполнялся

Ну вот я и разрываюсь сейчас между тем, чтобы использовать EJ акки или просто в лоб совать в таблицу SQL (ну или еще куда), а потом удалять.

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

Я уже даже сделал все на акке (точнее на акклинге) с персистентым актором, кода немного. Но выглядит это все типичной иллюстрацией "если у вас из инструментов только молоток, то все вокруг кажется гвоздями". Если у нас из хранилищ только event journal, мы начинаем из всего нарезать персистентные акторы. И вот это смущает

Да я уже натянул 😊 Вот и рефлексирую

А, ну тогда... Если работает то ок)

Но я и контраргумент тоже понимаю, слишком много работал в проектах, где на любой чих создавали таблицу, куда что-то писали. Вот у нас сейчас такая база с более сотней таблиц, половину уже никто не помнит когда и зачем завели

Работает все, кроме очистки журнала от записей посланных сообщений. Это никогда не поздно добавить, но этот шаг особенно раздражает, поскольку демонстрирует несоответствие хранилища целям. Вот durable RabbitMQ никто же не чистит вручную, сказано - временно хранить, они и хранят временно

Понимаю, отрасль такая. На любой чих микросервис со своей бд.

В акке же, емнип, можно настроить ручное удаление евентов по офсету N-1 на акноледже снепшота N

Чот такое точно было

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

Я думал удалять ненужные записи при пассивации корневого агрегата.

Разумеется, при условии, что записи ненужные