Если сообщения теряются, тогда выкинем jms, и заменим его на редис или кафку. Но сообщения, все равно, будут теряться. )))
@mikhail66944 жыл бұрын
Яков Файн в конце хорошо ответил)
@oeaoo7 жыл бұрын
Вопрос "Нужен ли мне JMS?" на практике должен разворачиваться в следующий "Хочу ли я делать реализацию напротив JMS API или же юзать конкретную JMS реализацию?". Все потому что это лишь интерфейс.
@olegnekludov8 жыл бұрын
Хороший доклад, в одном месте собраны варианты. Спасибо.
@romandzhadan55463 жыл бұрын
great talk!
@vladimirmokeev28565 жыл бұрын
21:36 Автор не посмотрел, что это не настоящий синий экран :D Шутки про мам дошли до Java конференций
@pablocoder9066 жыл бұрын
Отличный обзорный доклад!
@user-gw6df6ns7e6 жыл бұрын
Никто не верит. Но если включить все фичи, то сильно просаживается производительность.
@fdghjfdhjgfhjfghjfgh8 жыл бұрын
Докладчик интересно рассказывает и поверхностно знаком со множеством технологий, но к сожалению многие факты притянуты за уши. Видимо сказывается недостаток hands-on опыта и некоторый пробел в системном подходе в Computer Science. Докладчик просто не понимает как бегают байты и где надёжность спорит с производительностью. Во-первых, как-то тупо сравнивать производительность JMS который поддерживает persistance c брокерами которые его не поддерживают. Во-вторых, в распределённых системах с репликацией стыдливо замолчен вариант репликации: синхронный или асинхронный, если репликация асинхронная то о какой надёжности может идти речь В-третих в любых системах где надо гарантировать доставку сообщения и отсутствие дупликатов не обойтись без распределённых транзакций неважно jms это или нет. Рекомендация использовать в разработке амазоновский сервер который находится за тридевять земель и навозможно развернуть локально вообще за гранью добра и зла
@PsychoDelissemo5 жыл бұрын
А вас не затруднит дать ссылку на раскрытие ваших тезисов? Особенно интересен тезис про распределенные транзакции