Я бы попросил скрытных товарищей предъявлять аргументы в споре, а не молча подленько про себя минусовать. Неоднократно отмечалось, что если вы не согласны — это не повод минусить.
При проверке от лица системы всегда можно подняться вверх по стеку и проверить, кто вызвал привилегированную операцию. В стандартном Privileged Action по-моему так и делается. И хорошо, что Ява управляемая – позволяет сделать это без риска все закрэшить. Т.е. если есть некий определенный соглашениями контекст, то проверить его свойства вполне можно, в т.ч. число оставшихся потоков и даже потреблённую память (но это уже задание со звёздочкой)
Я полагал, что опытному программисту со стажем не составит труда представить, какие минимальные изменения нужно сделать, чтобы получить желаемый результат.
Готовое решение — это продукт, а я пока не решился на написание кода, только идеи есть.
Ограничение на потоки делается имеющимися средствами в пару строк кода: https://stackoverflow.com/a/31039987
В принципе, управление ресурсами можно реализовать при желании. Всеми, кроме памяти. Что и делает тот же желастик. Для меня всегда было загадкой только как они управляют объемом памяти. Это единственная вещь, которую я считал если не невозможной, то очень трудной.
В ответ на ваш пример: сделать административный Бин или коннектор для сервера, который прибьет зависший поток — плёвое дело. Часто это делают через JMX.
Вот насчёт защиты JVM вы зря. Апплеты вполне себе независимо работали. И обычный инстанс если запустить с секурити, вы мало что сможете вне контекста сделать. Например рефлексируя в OSGI, получите по рукам.
И сервера приложений слабо, но защищены даже по умолчанию. Рми сильно ограничен. И можно ужесточить защиту.
Имелись в виду 20 сторонних клиентов с 20-ю порталами.
Доменный контроллер глассФиша умеет управлять серверами. И Флай тоже.
Правда управлять в смысле определять лимиты, кол-во копий бинов и т.п. Это оценка ресурсов в штуках, а не в мб, как в Амазон ЕЦС.
А вот jelastic cloud как раз метрики собирает и как-то хитро калибрует память.
Как же не умеют. Есть джеластик Ява как раз про это всё.
JVM не умеет, зато доменный контроллер, запущенный на ней, вполне умеет (в современной терминологии контрол-плэйн).
XML нужен не тогда, когда у вас 1 экземпляр, а когда надо 15 настроенных релизов выкатить на 20 клиентов с очень разным но тем не менее схожим составом блинов в логике и разным расположением ендпойнтов на корп. портале.
Поскольку Ява почти ОС, то Ява и есть нода. Если вылетит, то целиком. Но она не вылетит. И нода большая, иначе смысла запускать Яву вообще нет. Т.е. одна Явная нода. И вылет по явовскому ООМ случится тогда, когда кончатся ресурсы, и это безопаснее, чем пресловутая молчаливая смерть от нативного ООМ.
Как я уже описал, в специализированных серверах есть балансировка, это значит, что да, нагрузка перемещается по кластеру, на то он и кластер.
Если под л вы подразумеваете левел сети, то ejb/RMI – прикладной уровень. Да, я не спорю, что может быть уровень тисипи эффективнее. Но это нивелируется работой с джсоном по хттп между сервисами в большинстве случаев.
И кстати, я не делал вывод, что Ява может заменить Кубер. Я лишь оцениваю недавнюю историю развития Явы и как платформа профукала свой рынок. И показываю как должна работать Ява. Что т.н. кровавый ынтырпрайз по мнению некоторых был неудачным тяжеловесным решением и надо срочно сделать монолитный Спринг.
История показала, кто был прав и какие технологии продуманны и обкатаны, а какие сделаны на коленке. И показываю, что еджби в ентерпрайз-кластерах, по сути то же, что докеры в кубере. А заголовок — это для привлечения внимания.
Насчёт Андроид, да, там ява больше для гуи оболочки использовалась. Примерно как иксы или винда 3 версии. В принципе, с некоторой натяжкой можно и её считать отдельной ОС.
Вообще я перечислил признаки ОС в Ява-машине.
Можно ещё уточнить, что Линукс — не ОС, это ядро ОС. А ОС чаще всего гну. Андроид не гну ос. И обратно, гну ос может работать на ядре Хёрд.
В JavaEE и других фреймворках вполне хватает средств кластеризации. Только там немного другая гранулярность. В качестве инстанса выступает джвм с Веб-сферой, к примеру. Инстансы организуются в кластер и другие объединения.
Что касается ОС: у Оракла была такая система, JRocketVM. Это тоже не Линукс, конечно, но из него выдраны многие лишние компоненты. Лёгкая версия, скажем так. И позиционировалась для запуска на металле.
Для самой jvm по большому счёту, не нужна ОС, достаточно ядра. Причём я даже рассматривал варианты запуска в реальном режиме по причинам, описанным в статье.
Меня всегда интересовало, почему разработчики яваее жалуются на долгий деплой. Если у вас приложение не монолит, а цивилизованно побито на небольшие модули, как то: еджби и вареники, то проблем с инкрементальной сборкой и даже деплоем не будет. Один небольшой EJB деплоится в считанные секунды. Это быстрее и удобнее, чем любые микросервисы.
Ясно понятно, что под завязку нагруженный сервер стартует довольно долго. Но его не надо стартовать часто. Раз в неделю вполне достаточно. Вы же не разворачиваете кластер Кубера каждые полчаса?
Дело в правильном планировании и организации работ.
Насчёт памяти согласен. Это одна из больных проблем Ява-машины. Как и долгий старт. Ну а что вы хотите? Делать супернакрученную логику по загрузке классов и при этом не потерять в производительности?
Я нарочно здесь пел хвалебные песни. Но я ведь отметил, что недостатков хватает. О них расскажут другие.
На мой взгляд, в современных реалиях Ява может найти применение именно в виде легковесных лямбд, целиком грузить процессы слишком накладно. Причём для легких функций больше подойдут именно EJB, Spring в данном случае проигрывает как монолит и его уже вытесняют Quarcus и аналоги.
Хорошо, теперь всё встало на свои места. Реальное устройство, если вам верить, более плоское и простое, чем я себе представлял. В принципе, простота иногда выливается в надёжность.
Если все операторы получают адреса на одном уровне (что по-моему всё-таки не всегда верно), то иерархия существует только в структуре реестров, т.е. сугубо бюрократически обслуживается. Тогда да, действительно, нет прямой связи между диапазонами адресов и физическими подключениями.
Про корневые это я оговорился. Имелись в виду сертификаты самого верхнего уровня, привязанные к реальным диапазонам. Но сути это не меняет. Большая часть верхнеуровневых диапазонов, я подозреваю, в собственности крупнейших провайдеров. И тут дело десятое, кем они были выданы — одним ЛИРом или десятью с пяти континентов. Главное, что приоритетное право подписывать огромные пространства сети имеют небольшое число магистральщиков.
И если у одного телекома-ТНК 20% адресов интернета и монопольное право выдавать подписи своим приватным ключом на различные куски этого пространства, то на мой взгляд, очевидно, что "никакой, даже самый большой, оператор не может никак" — не совсем верно.
Спасибо за разъяснение по поводу цели подписи. Получается, что подписывается только голова (последний, или первый слева элемент) AS-PATH. Это действительно тогда защищает от анонса от чужого имени, не ломая маршруты. Но это решает лишь часть проблем с мошенничеством — а именно ддос атаки.
Атаки типа перехвата трафика, прослушки и чёрной дыры всё равно возможны, так как все остальные элементы AS-PATH, его хвост, по-прежнему могут быть произвольными. И если эндпойнт способен принять этот трафик, то он может сделать такой анонс. В крайнем случае, если сам не переварит, завалит трафиком партнёров. Если ещё при этом по-хитрому распределить среди них нагрузку, то и черная дыра остаётся актуальной.
Но тут, видимо нет универсального решения. Либо ограничение трафика, либо безопасность.
При проверке от лица системы всегда можно подняться вверх по стеку и проверить, кто вызвал привилегированную операцию. В стандартном Privileged Action по-моему так и делается. И хорошо, что Ява управляемая – позволяет сделать это без риска все закрэшить. Т.е. если есть некий определенный соглашениями контекст, то проверить его свойства вполне можно, в т.ч. число оставшихся потоков и даже потреблённую память (но это уже задание со звёздочкой)
Я полагал, что опытному программисту со стажем не составит труда представить, какие минимальные изменения нужно сделать, чтобы получить желаемый результат.
Готовое решение — это продукт, а я пока не решился на написание кода, только идеи есть.
Я рекомендую вам внимательнее читать и код, и документацию, прежде чем писать комментарии.
Ограничение на потоки делается имеющимися средствами в пару строк кода: https://stackoverflow.com/a/31039987
В принципе, управление ресурсами можно реализовать при желании. Всеми, кроме памяти. Что и делает тот же желастик. Для меня всегда было загадкой только как они управляют объемом памяти. Это единственная вещь, которую я считал если не невозможной, то очень трудной.
В ответ на ваш пример: сделать административный Бин или коннектор для сервера, который прибьет зависший поток — плёвое дело. Часто это делают через JMX.
Я как раз и говорю про "функции, на которых строился GUI софта". Это и называется графической оболочкой, часто одной из главных частей ОС.
Вот насчёт защиты JVM вы зря. Апплеты вполне себе независимо работали. И обычный инстанс если запустить с секурити, вы мало что сможете вне контекста сделать. Например рефлексируя в OSGI, получите по рукам.
И сервера приложений слабо, но защищены даже по умолчанию. Рми сильно ограничен. И можно ужесточить защиту.
На контейнерах они стали работать, чтобы следовать моде. Изначально у них был чисто явовый паас.
Да почему же на одном то. У вас 20 сборок, которые деплоят в 20 разных конторах в 20 местах планеты на 20 разных языках вот такой кейс.
Имелись в виду 20 сторонних клиентов с 20-ю порталами.
Доменный контроллер глассФиша умеет управлять серверами. И Флай тоже.
Правда управлять в смысле определять лимиты, кол-во копий бинов и т.п. Это оценка ресурсов в штуках, а не в мб, как в Амазон ЕЦС.
А вот jelastic cloud как раз метрики собирает и как-то хитро калибрует память.
Как же не умеют. Есть джеластик Ява как раз про это всё.
JVM не умеет, зато доменный контроллер, запущенный на ней, вполне умеет (в современной терминологии контрол-плэйн).
XML нужен не тогда, когда у вас 1 экземпляр, а когда надо 15 настроенных релизов выкатить на 20 клиентов с очень разным но тем не менее схожим составом блинов в логике и разным расположением ендпойнтов на корп. портале.
Поскольку Ява почти ОС, то Ява и есть нода. Если вылетит, то целиком. Но она не вылетит. И нода большая, иначе смысла запускать Яву вообще нет. Т.е. одна Явная нода. И вылет по явовскому ООМ случится тогда, когда кончатся ресурсы, и это безопаснее, чем пресловутая молчаливая смерть от нативного ООМ.
Как я уже описал, в специализированных серверах есть балансировка, это значит, что да, нагрузка перемещается по кластеру, на то он и кластер.
Если под л вы подразумеваете левел сети, то ejb/RMI – прикладной уровень. Да, я не спорю, что может быть уровень тисипи эффективнее. Но это нивелируется работой с джсоном по хттп между сервисами в большинстве случаев.
И кстати, я не делал вывод, что Ява может заменить Кубер. Я лишь оцениваю недавнюю историю развития Явы и как платформа профукала свой рынок. И показываю как должна работать Ява. Что т.н. кровавый ынтырпрайз по мнению некоторых был неудачным тяжеловесным решением и надо срочно сделать монолитный Спринг.
История показала, кто был прав и какие технологии продуманны и обкатаны, а какие сделаны на коленке. И показываю, что еджби в ентерпрайз-кластерах, по сути то же, что докеры в кубере. А заголовок — это для привлечения внимания.
Насчёт Андроид, да, там ява больше для гуи оболочки использовалась. Примерно как иксы или винда 3 версии. В принципе, с некоторой натяжкой можно и её считать отдельной ОС.
Вообще я перечислил признаки ОС в Ява-машине.
Можно ещё уточнить, что Линукс — не ОС, это ядро ОС. А ОС чаще всего гну. Андроид не гну ос. И обратно, гну ос может работать на ядре Хёрд.
В JavaEE и других фреймворках вполне хватает средств кластеризации. Только там немного другая гранулярность. В качестве инстанса выступает джвм с Веб-сферой, к примеру. Инстансы организуются в кластер и другие объединения.
Что касается ОС: у Оракла была такая система, JRocketVM. Это тоже не Линукс, конечно, но из него выдраны многие лишние компоненты. Лёгкая версия, скажем так. И позиционировалась для запуска на металле.
Для самой jvm по большому счёту, не нужна ОС, достаточно ядра. Причём я даже рассматривал варианты запуска в реальном режиме по причинам, описанным в статье.
Меня всегда интересовало, почему разработчики яваее жалуются на долгий деплой. Если у вас приложение не монолит, а цивилизованно побито на небольшие модули, как то: еджби и вареники, то проблем с инкрементальной сборкой и даже деплоем не будет. Один небольшой EJB деплоится в считанные секунды. Это быстрее и удобнее, чем любые микросервисы.
Ясно понятно, что под завязку нагруженный сервер стартует довольно долго. Но его не надо стартовать часто. Раз в неделю вполне достаточно. Вы же не разворачиваете кластер Кубера каждые полчаса?
Дело в правильном планировании и организации работ.
Это опять же смотря где. В GlassFish плагинами являются по сути сами приложения, если я ничего не путаю. И они устанавливаются при каждом деплое.
Я нарочно здесь пел хвалебные песни. Но я ведь отметил, что недостатков хватает. О них расскажут другие.
На мой взгляд, в современных реалиях Ява может найти применение именно в виде легковесных лямбд, целиком грузить процессы слишком накладно. Причём для легких функций больше подойдут именно EJB, Spring в данном случае проигрывает как монолит и его уже вытесняют Quarcus и аналоги.
Хорошо, теперь всё встало на свои места. Реальное устройство, если вам верить, более плоское и простое, чем я себе представлял. В принципе, простота иногда выливается в надёжность.
Если все операторы получают адреса на одном уровне (что по-моему всё-таки не всегда верно), то иерархия существует только в структуре реестров, т.е. сугубо бюрократически обслуживается. Тогда да, действительно, нет прямой связи между диапазонами адресов и физическими подключениями.
Про корневые это я оговорился. Имелись в виду сертификаты самого верхнего уровня, привязанные к реальным диапазонам. Но сути это не меняет. Большая часть верхнеуровневых диапазонов, я подозреваю, в собственности крупнейших провайдеров. И тут дело десятое, кем они были выданы — одним ЛИРом или десятью с пяти континентов. Главное, что приоритетное право подписывать огромные пространства сети имеют небольшое число магистральщиков.
И если у одного телекома-ТНК 20% адресов интернета и монопольное право выдавать подписи своим приватным ключом на различные куски этого пространства, то на мой взгляд, очевидно, что "никакой, даже самый большой, оператор не может никак" — не совсем верно.
Спасибо за разъяснение по поводу цели подписи. Получается, что подписывается только голова (последний, или первый слева элемент) AS-PATH. Это действительно тогда защищает от анонса от чужого имени, не ломая маршруты. Но это решает лишь часть проблем с мошенничеством — а именно ддос атаки.
Атаки типа перехвата трафика, прослушки и чёрной дыры всё равно возможны, так как все остальные элементы AS-PATH, его хвост, по-прежнему могут быть произвольными. И если эндпойнт способен принять этот трафик, то он может сделать такой анонс. В крайнем случае, если сам не переварит, завалит трафиком партнёров. Если ещё при этом по-хитрому распределить среди них нагрузку, то и черная дыра остаётся актуальной.
Но тут, видимо нет универсального решения. Либо ограничение трафика, либо безопасность.