Василий Банников, в настоящем хайлоаде самые невероятные сценарии как раз срабатывают в первую очередь и если в коде размер коллекции явным образом не ограничен, то обязательно наступит момент, когда коллекция переполнится. Так что эксперимент ТС вполне себе практический и добытые знания пригодятся в будущем.
Перебалансировка не производится, если консюмер подписан на конкретные партиции вручную. Так что если агент упадет, то никто не перехватит его сообщения.
MiniDeveloper, соглашусь с Сергей Горностаев. Вот прям буквально - подберите список языков, которые вы предпочли бы изучить, зайдите на сайт с вакансиями, ограничьте поиск по своему городу, по порядку вбивайте каждый язык и приступайте к изучению того языка, на который выпало максимальное количество вакансий. Это что касается "дальнейшего трудоустройства".
Далее, как только изучите выбранный язык на хорошем уровне, то можно будет отвлечься и на другие языки. Проблем с этим быть не должно, так как все императивные языки похожи друг на друга и вам не нужно будет тратить время на освоение тысячи мелочей, одинаковых во всех языках, и можно сразу сосредоточиться на самом интересном. Реально сложный в изучении только первый язык. Причём неважно какой он будет.
Изучать непопулярный язык с целью заработать на нём - это лотерея. Если не повезёт и вас сразу не возьмут ни в одно из 5 мест, куда требуется rust, то с трудоустройством будут явные проблемы.
Я похожим образом выбирал фреймворк для PHP проекта - выбирал из самых популярных в моём регионе и не прогадал.
Мне казалось комментарий к коду вполне ясно описывает, что System.gc() не позволяет управлять gc. Но судя по вашему комментарию, мне это и правда только казалось...
Если быть точным, то не jvm решает, а сборщик мусора.
Hotspot, например, честно триггеритсборку (если не используется опция -XX:+DisableExplicitGC). Но вот произойдёт ли она на самом деле - зависит от сборщика.
Точно могу сказать, что при использовании сборщика epsilon вызов System.gc() никогда не приведёт к сборке :)
Раз запрос технически соответствует документации, значит проблема административная и решить её можно только запросом в техподдержку. Спросите у них почему с вашим токеном запросы отклоняются.
Roman Biz, с библиотекой всё так. Не так здесь про проброс docker сокета в контейнер. По уровню безопасности это как запускать скрипты от имени root прям на хосте.
Валентин, полагаю, автор вопроса не имеет контроля над приложением, но очень хочет отреверсить его протокол. Был бы доступ к нешифрованному участку (к серверу, по сути), то и вопроса бы не возникло.
3.1, 3.2. Берётся из оперативной памяти. Не бывает такого, что загрузилась только часть класса, а потом по мере надобности догружаются оставшиеся части класса. Класс либо загружается в память полностью и создаётся объект класса Class для него, либо не загружается вообще с генерированием соответствующего исключения - ClassNotFoundException, NoClassDefFoundError, VerifyError, LinkageError и др. Создавать объекты и вызывать методы (статические и нестатические) можно только на полностью загруженном классе.
Через composer его не установить. Это отдельная независимая программа, которая нужна только один раз для первичной генерации grpc клиента. В следующий раз она понадобится только когда сервер внесёт изменения в свой proto файл - тогда и нужно будет перекомпилировать скрипты grpc клиента. Да и то не факт, так как protobuf создавался с расчетом на обратную совместимость и если новые фичи из нового proto файла не нужны, то и компилировать заново ничего не нужно. Ещё перекомпиляция потребуется при переходе на новую версию grpc/protobuf модуля.
Скачать компилятор с плагином можно с официального сайта. В конце страницы есть таблица со ссылками на результаты ежедневных билдов. Переходите по самой свежей ссылке из колонки "Build ID" и качайте архив под свою систему из раздела "gRPC protoc Plugins". В архиве будет и плагин, и сам компилятор.