Чем текущее решение лучше/практичнее Spring Data REST? Зачем выдумывать очередной велосипед, кроме как получение физического контроля над выполняемой логикой?
Западные техники мониторинга команд в т.ч. скрам - не применимы к продуктовым компаниям РФ, пока существуют фундаментальные проблемы процессов. Это все только создает для рабочей среды огромную трату времени..
Тест с reactor в корне неверный. Обратитесь к документации, где четко сказано, что любое IO необходимо публиковать на выделенный Schedulers. Иначе, что вы хотите сказать графиками - reactor хуже servlet stack?
Тестирование различных пулов Reactor стоит оставить для статей по реактору.
Если тестировать - то правильно. Как минимум по графикам уже понятно, чем event loop занят 99% времени.
Интересно, что же все таки случится в «правильном тесте» webflux, если добавить к вызову репозитория switch context скажем bounded elastic пул. В MVC - где тесты с тем же CompletableFuture, а как же loom вместо стандартной фабрики потока на запрос?
Описание пайплайна не верное, тест можно считать провальным.
Имхо нет смысла заморачиваться с распознанием, есть next target. Достаточно реализовать цикличные макросы с таймингами и частотой нажатий по заданному шаблону клавиш клавиатуры, бонусом это можно делать в свернутом окне через User32.SendMessage, что не умеет макросная мышка. Но есть вероятность словить бан хамер, если защитное ПО (Frost точно это делает на ру) проверит стек вызова - драйвер мыши/клавиатуры решает проблему и прямые команды через COM.
Увы, материалы сам когда-то искал, так и не нашел. Провел пару тестов в нагрузке (tcp - 10к клиентов с рейтом в 30-40rps) - профайлер показал деградацию в Record<init> (jdk 19).
Это все конечно замечательно, синтаксический сахар и все вот это вот удобство.. но вы же, наверно, вкурсе о больших накладных расходах при создании record-классов? Нет? Проведите стресс тест системы, будете удивлены. Крайне не советую в принципе использовать в высоконагруженной системе все эти удобства.
Какой-то мейнстрим вокруг spring и всей его экосистемы. Есть кучу компаний и решений, не использующих spring, в которых нужны core разработчики. Новичок, конечно же, сразу пойдет хайпить по новомодному стеку, прочитав эту статью - зачем знание core разработки, когда можно писать MVC сутками и плевать как оно работает, имхо. Как будто бы все программирование на Java сводится к построению веб-решений и только.
Тащить в проект inMemory бд ради того что бы не хранить в ней данные, а использовать распределенные блокировки.. слишком много оверхеда. Для каждой задачи есть свой инструмент, и этот не подходит под вашу задачу. Нужны распределенные воркеры, которые будут запускаться поочередно на каждой ноде - quartz в помощь. Даже банальная таблица синхронизации в реляционной базе с запросами вида select for update, решает эту задачу.
А про что тогда 0_о? В данный момент вы делаете тоже самое что и указанный модуль. Поясните в чем же фундаментальные различия.
Чем текущее решение лучше/практичнее Spring Data REST?
Зачем выдумывать очередной велосипед, кроме как получение физического контроля над выполняемой логикой?
ЗО РП/ПМ, «долой оптимизации - даешь больше фич», нехватка ресурса.. можно долго перечислять
Западные техники мониторинга команд в т.ч. скрам - не применимы к продуктовым компаниям РФ, пока существуют фундаментальные проблемы процессов. Это все только создает для рабочей среды огромную трату времени..
«Больше инспекций богу инспекций» (с)
Скоро совсем перестанет анализировать код, вернемся к временам notepad.
Тест с reactor в корне неверный. Обратитесь к документации, где четко сказано, что любое IO необходимо публиковать на выделенный Schedulers. Иначе, что вы хотите сказать графиками - reactor хуже servlet stack?
Если тестировать - то правильно. Как минимум по графикам уже понятно, чем event loop занят 99% времени.
Интересно, что же все таки случится в «правильном тесте» webflux, если добавить к вызову репозитория switch context скажем bounded elastic пул. В MVC - где тесты с тем же CompletableFuture, а как же loom вместо стандартной фабрики потока на запрос?
Описание пайплайна не верное, тест можно считать провальным.
Правильно ли понимаю, что используете нативный сокет из коробки, если да, то почему не netty?
«Локальная машина», а это лупбек. сомнительный эксперимент
Работает, не трогай! (Сбер)
Имхо нет смысла заморачиваться с распознанием, есть next target. Достаточно реализовать цикличные макросы с таймингами и частотой нажатий по заданному шаблону клавиш клавиатуры, бонусом это можно делать в свернутом окне через User32.SendMessage, что не умеет макросная мышка. Но есть вероятность словить бан хамер, если защитное ПО (Frost точно это делает на ру) проверит стек вызова - драйвер мыши/клавиатуры решает проблему и прямые команды через COM.
Да, имхо единичный "мой" случай, дособираю статистику и вышлю багрепортом.
Увы, материалы сам когда-то искал, так и не нашел. Провел пару тестов в нагрузке (tcp - 10к клиентов с рейтом в 30-40rps) - профайлер показал деградацию в Record<init> (jdk 19).
Это все конечно замечательно, синтаксический сахар и все вот это вот удобство.. но вы же, наверно, вкурсе о больших накладных расходах при создании record-классов? Нет? Проведите стресс тест системы, будете удивлены. Крайне не советую в принципе использовать в высоконагруженной системе все эти удобства.
А давайте заведем практику - вместо инъекции зависимостей, будем напрямую инициализировать их из контекста во всем приложени.
Какой-то мейнстрим вокруг spring и всей его экосистемы. Есть кучу компаний и решений, не использующих spring, в которых нужны core разработчики. Новичок, конечно же, сразу пойдет хайпить по новомодному стеку, прочитав эту статью - зачем знание core разработки, когда можно писать MVC сутками и плевать как оно работает, имхо. Как будто бы все программирование на Java сводится к построению веб-решений и только.
Окей, это все круто, что вы смогли элегантно обойти проблему. Но, зачем велосипед если есть vavr?
Удивительно.
Имхо, стоит внимательней вчитываться в код того же IntegrationFlowBuilderRegistry...
Тащить в проект inMemory бд ради того что бы не хранить в ней данные, а использовать распределенные блокировки.. слишком много оверхеда. Для каждой задачи есть свой инструмент, и этот не подходит под вашу задачу. Нужны распределенные воркеры, которые будут запускаться поочередно на каждой ноде - quartz в помощь. Даже банальная таблица синхронизации в реляционной базе с запросами вида select for update, решает эту задачу.
Как это не может "многопоточно"?
С точки зрения выполнения команд в коре - да. С точки зрения вашего кода - CAS и Retry уже не используется?