Здравствуйте, eao197, Вы писали:
E>А предоставляет Erlang такую штуку, как возможность оформить какую-либо автономную операцию в виде самостоятельного процесса. И наплодить таких процессов сотни тысяч. И не иметь с этим делом большого геморроя, прибивая за просто так любой процесс и очень дешево порождая новый процесс. И все это в террариуме, в котором копошатся тысячи и тысячи процессов.
Если опустить слово "убивать", то executor-ы в Яве эти самые АВТОНОМНЫЕ операции выполняют не хуже.
Если надо убивать, то см конец поста.
E>А вот альтернативные решения требуют несколько больших усилий. Самый простой вариант -- рескан с каким-то периодом базы в поиске пар сообщение/абонент, которым нужно произвести доставку. Но для того, чтобы протестировать его под нагрузкой придется сильно попотеть, набивая тестовую БД и имитируя различные исходы доставки сообщения. А так же верификации результатов тестирования.
Опять не вижу проблемы (в Яве). Используем ScheduledThreadPoolExecutor. Если сообщение не отправили, ставим себя же с новым увеличенным delay-ем в executor, удаляя оттуда же свой текущий экзмепляр. Имхо, должно работать.
E>Чуть более сложный вариант -- организация каждой пары сообщение/абонент в виде объекта. Этот объект ставится в очередь. Когда какая-то из нитей рабочего пула извлекает такой объект, она выполняет очередную попытку доставки, затем анализирует разультат доставки и принимает решение о том, что делать дальше. Здесь нужно придумывать, как ставить в очереди "отложенные" объекты, время повторной доставки которых далеко "в будущем" -- ведь вытащив такую заявку из вершины очереди рабочая нить должна понять, что еще рано, вернуть объект обратно и заснуть "до лучших" времен. Нужно самим делать механизм "прибивания" рабочих нитей которые из-за каких-то сбоев в функции try_deliver не возвращаются из обрабоки очередного сообщения.
Эммм... try_deliver вызывает внешний код в обоих случаях (Erlang и C#/Java) или же пользуется внутренним кодом?
Для внешнего кода убивать поток одинаково невесело и там и там.
Во внутреннем коде при желании код отправки сообщений можно оснастить вызовами аналогичными Явовскому Thread.currentThread.isInterrupted()
Так что ниточки при желании прибивать можно и там и там.
