"Континуэшен останется на этом аксепте а реальный нативный поток "отцепится" и пойдёт другую работу делать" а как где именно это произойдет? unpack ведь не вызовется из-за того что мы повисли

https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html

В разделе
"All your blocking are belong to us"

Как раз про ввод/вывод кратенько - общий принцип

да, это отвечает на мой вопрос, спасибо

а можно ли как-то чисто в отладочных целях кинуть исключение если ReadWriteLock не заблокирован текущим потоком (или на чтение, или на запись)?

D

На самом деле, с точки зрения бизнеса это вполне себе аргумент

Если у них много ресурсов в виде .net инженеров, то проще и правильнее будет новый проект писать на .net, чем нанимать javистов, полгода оттягивать начало проекта, потом переделывать систему разворачивания проектов итд

Если много ресурсов в виде windows серверов, то логично что они не будут использовать докер итд

Я был на проекте с огромной репортинговой тулой, где большая часть кода была в виде plsql

Главное было правильно разграничить ответственность - что например ВСЯ логика должна быть в PLSQL, и что не надо подхачивать результат вывода PLSQL на джаве потом (в плане бизнес-логики)

Есть около 300 различных независимых друг от друга сервисов,  выполняющих несложную логику (в основном, обработка форм и передача данных в/из внешних систем). Необходимо реализовать их на Java и Spring Boot.

Проблема: если придерживаться классического монолита, при изменении одного сервиса потребуется перезапуск всего приложения (зная производительность бута при запуске, загрузка 300 модулей будет занимать очень много времени.) То же, вероятно, и при компиляции.

Варианты:

- Микросервисы
- Инструменты для hotswap, JRebel, например
- ???

Странный вопрос, на самом деле. Если сервисы уже есть и независимые, то зачем переписывать их на бут и тем более объединять в монолит?

Они сейчас реализованы на другом языке, возникла необходимость переписать их на джаве. В силу интерпретируемости PHP эта проблема неактуальна, на джаве все сложнее

Нельзя назвать их «сервисами» в чистом виде. Фактически, это один большой пхпшный монолит

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

Ну, начните тогда выделять эти сервисы в отдельные приложения

Да, но такое количество микросервисов будет довольно трудно сопровождать, и у нас сейчас нет достаточных ресурсов для этого. Микросервисы - это крайний вариант, за неимением достойных альтернатив

А их вот прям реально 300? Или все же то что сейчас это не совсем микросервисы и их можно объединить логически?

Переписывать монолит с пхп на монолит на жабе - это точно не достойная альтернатива

еще. как довольно необычный вариант - реализовывать логику на груви скриптах, если это возможно, а на джаве написать только движок для этого