Почему я заинтересовался IMDG.

Десятилетие 2005-2015 - это десятилетие (в том числе) The Concurrency Revolution.
Но текущая ситуация такова, что ядра то лепят (уже десятками), ноды объединяют в кластеры (уже сотнями), а новых подходов все нет.
Threads, Actors - это не выход: 1) слишком низкоуровнево, 2) количество сущностей thread/actor должно расти с колвом ядер.
Fork/Join как попытка уйти от явного указания кол-ва потоков - применима если мы сами параллелим задачу. Колво потоков задает framework, но правило разбиения задачи - задаем мы.

Моя идея такова, что чем более масштабируема система/задача, тем более слабой моделью памати она обладает. На уровне процессора(x86 mem model) или языка (New Java Mem Model) модель памяти уже задана, и мы можем только спорить - хорошо ли приспособлена Java для 100K потоков, или тут уже нужен Erlang.

Но если мы сами создаем Модель Памяти? Скажем берем realiable multicasting, на нем строим другие мулькастинги (atomic, causal, total order, etc), на них строим любые модели Shared Memory, поверх Shared Memory реализуем какой-нибудь механизм координации - что-то вроди Linda. Это текущие процессы.

А если так: business people пишут свою логику, а система по логике 1) находит слабейшую можель памяти на которой это еще будет работать, 2) указывает, какие моменты в бизнесс-правилах наиболее органичивают систему в масштабировании. Под эту модель памяти поднимается Grid. Т.е. масштабируемость системы зависит исключительно от бизнесс-логики, а не от того какой кэш вы выбрали: GemFire ReplicatedCache или Coherence PartitionedCache.

P.S. В моем представлении, сейчас период безвременья между Февральской и Октябрьскими Революциями. Царя уже свергли (ядра лепят, кластеры поднимают), но нет мощной идеи определяющей развитие на десятилетие вперед (конституционная монархия, либеральная демократия, мировая революция == Shared Memory, MOM, Linda, IMDG, Actors, ...).

P.P.S. Естественно государственный деятель должен учитывать вызовы будущего - мировые войны, модернизацию промышленности, решение проблем урбанизации (я имею в виду квантовые компьютеры с миллионами/миллиардами "потоков" между которыми очень-очень странные и асимметричные взаимодействия).

Зачем писать свой IMDG?

Info: лицензия за GemFire на 1 нод на один год - 25K$. Т.е. кластер на 40 нодов - 1M$/year.
1.000.000$ с КАЖДОГО бизнеса КАЖДЫЙ год пользования твоим IMDG!
Так это еще и низкая цена - Oracle Coherence стоит заметно дороже.

P.S. Да к черту эти стартапы! Социальные сети для собак, e-shops, новейшие сервисы по отсылу СМС, ... Все на написание IMDG!

JGroups: author blog

Обнаружен блог автора и основного разработчика JGroups. Также он еще и разработчик JBoss Infinispan (IMDG).

IMDG Internals: JGroups

Давно уже чесались взяться за JGroups - a toolkit for reliable multicast communication.

И вот выяснилось, что ее используют Ehcache, GemFire, JBoss Infinispan:
Ehcache - Replicated Caching using JGroups.
Gemfire - для Member Discovery (не уверен на счет Communication and Data Transfer)
JBoss Infinispan

Тут много всяких доков включая даже книгу (ссылка не работает). "Ken Birman: Building Secure and Reliable Network Applications. Excellent book on group communication. In-depth description of various protocols (atomic bcast, causal, total order, probabilistic broadcast). Very technical content."

P.S. Есть желание изучить ключевые либы, на которых строятся cutting edge проекты для JVM. Пока обнаружено два кандидата: JGroups и Netty (пожулуй самая производительная либа для NIO). Netty вместе с автором сейчас работают над JBoss Infinispan.

[GC]: G1: Следующее поколение сборщика мусора для HotSpot VM

G1: Следующее поколение сборщика мусора для HotSpot VM

P.S. От сюда.

Attack on NoSQL

The "NoSQL" Discussion has Nothing to Do With SQL

Философия SQL или причина популярности NoSQL.

Собираю материал по Memory Consistency Models of IMDGs

Собираю материал по Memory Consistency Models of IMDGs.
Помогите кто чем богат:)

В корпоративном блоге Алексей Рогозин начал писать серию статей "Data Grid Pattern-s". Я зацепился за Data Grid Pattern - Network shared memory.

Как известно всякая Shared Memory должна обладать какой-то Memory Consistency Model. Но по бедноте материала на эту тему даже от "монстров" рынка: Oracle Coherence, IBM WebSphere eXtreme Scale стало понятно, что это "больное место" IMDG (да собственно и большинства NoSQL-решений).

[PJP]: JMX - Best Practices

JMX - Best Practices