Wan-Derer

public Publisher<Void> addReport(HttpServerRequest req, HttpServerResponse resp) {
        return req.receive()
                .asString()
                .doOnNext(string -> {
                    // todo :: make some handy job with string
                    System.out.println(string);
                })
                .flatMap(__ -> resp.status(HttpResponseStatus.OK)  
                        .addHeader(ACCESS_CONTROL_ALLOW_ORIGIN, "*")     // CORS
                        .sendString(Mono.just("")));
    }

Общее представление можно получить из книги Maurer, Wolfthal - Netty in Action. Документацию по API читать на официальном сайте. Ну и сразу готовиться к тому, что придётся постоянно лазить за ответами в исходники, как самого Netty, так и использующих его проектов. Найти их можно на Github'е. Кроме того, стоит учесть, что без знания принципов сетевого программирования шансов на успешное освоение нет.

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

Тут оберните результат в скобки, без скобок работает только на первую строку, а у вас их две. А на будущее - не загружайте код в виде видео, это неуважительно из-за невозможности цитировать строчки и ужастно неудобно. Просто скопируйте и вставьте в вопрос.
Конечный код:

if(role == 2){
System.out.print("Текст");
int code = Armour.nextInt();
}

Любая авторизация должна выполнятся на строне сервера, всё что на стороне клиета обходится на раз!
Как именно - дело Вашею Есть десятки систем авторизациию Имя + пароль - самая распостраненная

ffmpeg -i input_video.mp4 -c:v copy -b:a 64k output_video.mp4

Установите live reload

https://chrome.google.com/webstore/detail/liverelo...
https://addons.mozilla.org/ru/firefox/addon/live-r...
https://addons.mozilla.org/ru/firefox/addon/livere...

И включите возможность в İDE (по ссылке ниже есть инструкция для intellij idea)
https://stackoverflow.com/questions/33349456/how-t...

Тут говорят, что можно включить hot reload для Thymeleaf. Это позволит автоматически обновлять страницу при изменении шаблона без необходимости перезапуска сервера. Для этого нужно добавить следующие строки в файл application.properties:

spring.thymeleaf.cache=false
spring.thymeleaf.enabled=true

После этого, при изменении шаблона, он должен автоматически перезагружаться и отображаться на странице.

Если прямая видимость - без проблем можно до 500 Мбит до 11 км вытянуть используя диапазон 5 ГГц и спецоборудование, например Микротик. Всё утыкается в бюджет
Вопрос другой - а зачем?
Что мешает на роутере правильно QoS настроить? Тогда ничего лагать не будет - роутер сам будет приоритеты трафика разруливать
На компе, что торренты качает - с самом торренте ограничение на 50 Мбит поставь - хватит выше крыши
По секрету скажу, FullHD трансляция - это около 5 Мбит
4K При частоте 24 – 30 кадров в секунду – порядка 35 – 45 Мб/с.
4K При частоте 40 – 60 кадров, битрейт составляет 58 – 65 Мб/с.
У меня на работе полсотни человек сидит на 100Мбитном канале. Если верить Zabbix - средняя нагрузка Интернет канала - 22 Мбит в рабочее время с редкими скачками

Не претендую на правду. Просто несколько мыслей.

В чем минусы событийно ориентированного подхода?
Насколько я понимаю, Алан Кей (тот кто придумал термин Объекто-ориентированный) старался придерживаться именно этого подхода. т.е. кто-то отправляет сообщение, а объекты в системе на него реагируют, каждый по-своему.
По сути у нас есть message bus, в который добавляется сообщение, а объекты системы слушают этот самый message bus.

Мысль первая. Наследие.

Когда мы говорим о наследии Алана Кея - надо просто глянуть что он создал практически.
А создал он язык Smalltalk. Поэтому логично изучать минусы событийного подхода на
примере софта который написан с использованием Smalltalk. Кто из коллег в топике
знает примеры такого софта? Я - к сожалению не знаю.

По ссылкам википедии https://en.wikipedia.org/wiki/Smalltalk можно видеть в категории
influenced мы просто видим что Smalltalk
влиял на Java, Go, Swift. Но я здесь не согласен потому что мы не можем измерить глубину
этого влияния. Это все равно что сказать что Сталин влиял на Черчилля. Как влиял? На 10%?
Или более чем половину? Сложно. Насчет Java я тут сказал-бы что сомнительно. ООП? Может быть.
Акторы? Нет. В Java изначально нет акторов. Они существуют позже в виде фреймворков но
языком не поддерживаются.

По поводу MessageBus. Если брать технологию акторов которая используется в Erlang.
то там скорее не message bus а очереди сообщений между потоками-акторами.
Если про Smalltalk сказать нечего то про Erlang я могу сказать что на нем написаны
две единицы софта такие как RabbitMq (очень надежная и неубиваемая система MQ).
Может не супер-производительная. И CouchDb которая выделяется своей
устойчивостью ко всяким сетевым сбоям. Реклама говорит что Кауч работает
практически при мигающей сети, при обрывах и т.п. лучше чем аналогичый TCP-IP совт.

Мысль вторая. Что Кей говорил про ООП.

У меня есть цитатник. Я туда собираю некоторые слова на лытни. И иногда слова Кнута, Дейкстры
и прочих it-академиков. Вот из цитатника Кея:

I made up the term "object-oriented," and I can tell you
I did not have C++ in mind.

Что в этой прямой речи можно понять. Что господин Кей открещивается от современного ООП.
А фактически все современное ООП зеркалит то что есть в С++. Здесь вы можете со мной спорить
о первенстве (я не буду спорить я не знаю). Но абсолютно очевиден факт что мир пошел по пути
жесткой синхронщины в 80х. И пока все еще идет. Будут ли примитивные типы int/double обьектами
не суть важно. Тут важно что Кей постулирует среду в которой двигаются сообщения. Как сеть в миниатюре.
А классическое ООП С++ - лишает нас этой среды и заменяет ее вызовом метода. Никакого сообщения
в С++ нет и быть не может потому что сообщение НЕ существует в отрыве от основного потока который
инициировал вычисления. Умрет поток - развалится весь стек и параметры и все. В противоположность
в языке Erlang поток (процесс) приёмник может дохнуть много раз но стек сохраняет свою живучесть
просто повторяя вычисления заново. И здесь мне кажется и идет развилка путей.

И здесь как-раз мы может говорить о недостатках. Очевидно что у нас появляется лаг приемки-передачи
сообщения. У нас появляются мягкие гарантии времени обработки. И многое другое.

Интересно почему в 80х Алан Кей проигрывал. Я думаю что победил прагматизм. В те далекие 80-е
комьютеры были еще слабыми. Частота мерялась сотнями килогерц и мегагерцами. И в расчетах
каждый такт был важен. И красивые и академические языки такие как Lisp, Prolog, Smalltalk
просто проигрывали языку С в силу оверинжинеринга. А поскольку С++ был вначале действительно
ООП-надстройкой над С - то он предлагал и ООП-подход и скорость портабельного ассемблера.
И хотя я лично не люблю С++ (я считаю его перегруженным техническими долгами прошлого)
я признаю что бизнес выбирая С++ выбирал просто скорость вычислений. Академизм и красивые
доказательства правоты программ были тогда не нужны. Нужно чтоб банковское приложение
быстро считало кредиты и выдавало зарплаты и пенсии.

Сегодня, когда мы нежемся в сладкой неге мощных процессоров и даже (!) облаков - мы можем
себе позволить любого уровня парадигмы и абстракции. Цена 1 абстракции стала настолько дешево
стоить что нам дешевле в банках запускать Java/Net приложения и на ходу фиксить ошибки
чем долго разрабатывать на С++ и иметь неопредленнное поведение и тяжелый анализ
в случае падения. Даже такой уродец как Python взлетел как язык интеграции а не разработки.

Мысль третья. Нестандартные и асинхронные архитектуры реализованные в железе.

Недавно смотрел анонс нового процессора от Чака Мура (это тот самый Мур который создал закон имени себя).
Мне кажется это пример той самой асинхронной клетки о которой мечтал Алан Кей.

Мысль четвертая. На кого похож Алан Кей?

Не знаю как вам. :) А мне он уж очень напоминает Боливара Траска из Люди Икс Дни Минувшего будущего.

Мысль 5. Что делает Алан Кей на фото?

Бренчит на музыкальных инструментах. Наверное блюз. Блюз потерянных архитектур :)