Как только будут готовы "все" инструменты — в том числе починят ломбок, выпустят "совместимые" версии — в прошлый раз прошло недели две. Я обычно с этого момента уже еду на тестовые :) Пару недель там, и к месяцу на проде. С 13, 14, 15 было именно так :)
Поддержу. Имхо, всегда лучше стараться исключить сервере время как таковое: использовать или время по UTC (Instant), или локальное по отношению к клиенту/источнику запроса/т.п.
К сожалению, я не пишу на питоне, и не увижу каких-то дополнительных подводных камней, но в своих Java и JS проектах я использую другой подход. Делюсь:
Вместо того, чтобы запускать с помощью CI сборку докером, а докером запускать сборку питоном, можно всё это дело "вынести вверх". Сделать свой образ для сборки, $CI_REGISTRY_IMAGE/tooling:latest, установить в него все нужные для сборки инструменты и docker cli (чтобы не запускать dind). Докерфайл для его сборки положить в корень в папку tooling и джобу запускать при only.changes в ней. Пушим в регистри.
Далее уже выполняем сборку приложения джобой, у которой image: $CI_REGISTRY_IMAGE/tooling:latest. Тут уже можно легко использовать кеширование зависимостей, например у меня и maven и gradle целиком сохраняют все свои пакеты между запусками. После выполнения основного скрипта собираем докером образ из полученных артефактов и пушим, куда надо.
Большое спасибо за статью!
У меня на проекте случилось тоже самое — при обновлении с 14 на 15 увеличилось потребление памяти, ограничения на размер Code Cache не было. На тот момент просто подняли лимиты в K8s, так как ресурсы были. Сейчас тоже думаю заняться вопросом исследования потребления памяти, т.к. функционал растёт, и память хочется ограничить везде, где можно.
Также хочу высказаться в поддержку того, что гораздо проще собирать костыли в небольшом количестве раз в полгода, чем сразу много оптом. Кроме того, все эти промежуточные релизы Java — это именно релизы, полноценные, прошедшие тесты. Это ведь не Beta, где реально могут что-то сломать. А багов каждый раз фиксят много.
Ну если, например, ваш код вызвал new long[Integer.MAX_VALUE], то именно тут можно и поймать OOM, и как-то обработать (запросить меньше?), и пойти выполняться дальше.
Практически не встречал ситуаций, когда в приложении несколько thread-pool-ов для запуска @Async-методов, и разработчикам приходится выбирать из них.
Всё-таки чаще это или дефолтный, или прям тут в приложении однажды описанный бин, которому нужно просто вызвать setTaskDecorator.
Если над одним кодом работает столько незнакомых людей, всё равно это ничего не ломает — они продолжают писать просто Async. Ситуация, когда и разработчиков овер-много, и тред-пулов в контекст уже набросали — за скоупом моего решения.
Практически всегда читаю Хабр с телефона. Так вот в мобильном Хроме недавно появилась возможность сделать свайпом "назад" и "вперёд" (проведя горизонтально от края экрана на середине высоты). Работает во всём этом интернете, кроме Хабра. Очень неудобно возвращаться из комментариев в статью или из статьи к списку статей обычными кнопками внизу одной рукой (второй качаю дочку в кроватке).
Вот бы найти, если такой существует, список экзаменов и сертификаций по "всему этому IT". В том числе и как эти, CKA и CKS, а также Оракловые по Java и т.п.
C 11-й Java доступен httpClient, который реализует описанный выше неблокирующий подход. А с Spring 5 есть его обёртка — WebClient, которым можно заменить RestTemplate.
Вот нет, не обёртка над ним. Я сам, если честно, их не использую, но имея желание нагуглить подтверждение вашему утверждению, сделать этого, увы, не смог.
Внезапно, начав мердж из сторонней тулзы, не смог найти Resolve conflicts в Идее. Только зная, что они существуют, нашёл через Search everywhere. Верните, плз.
А можно подробности? У меня не такой случай (Xmx=Xms), но ваше заявление очень интересно. Спасибо.
Возможно, хаб Java тут лишний?
Действительно, my fault. Исправил.
(2021 — 1995) / 16 = новая версия каждые ~1.5 года, неплохо идёт! :))
Как только будут готовы "все" инструменты — в том числе починят ломбок, выпустят "совместимые" версии — в прошлый раз прошло недели две. Я обычно с этого момента уже еду на тестовые :) Пару недель там, и к месяцу на проде. С 13, 14, 15 было именно так :)
IDEA уже поддерживает, ждём тонкие образы от Bellsoft, проверяем работоспособность спринга, ломбока, прочих инструментов, да едем в прод :)
Поддержу. Имхо, всегда лучше стараться исключить сервере время как таковое: использовать или время по UTC (Instant), или локальное по отношению к клиенту/источнику запроса/т.п.
К сожалению, я не пишу на питоне, и не увижу каких-то дополнительных подводных камней, но в своих Java и JS проектах я использую другой подход. Делюсь:
Вместо того, чтобы запускать с помощью CI сборку докером, а докером запускать сборку питоном, можно всё это дело "вынести вверх". Сделать свой образ для сборки, $CI_REGISTRY_IMAGE/tooling:latest, установить в него все нужные для сборки инструменты и docker cli (чтобы не запускать dind). Докерфайл для его сборки положить в корень в папку tooling и джобу запускать при only.changes в ней. Пушим в регистри.
Далее уже выполняем сборку приложения джобой, у которой image: $CI_REGISTRY_IMAGE/tooling:latest. Тут уже можно легко использовать кеширование зависимостей, например у меня и maven и gradle целиком сохраняют все свои пакеты между запусками. После выполнения основного скрипта собираем докером образ из полученных артефактов и пушим, куда надо.
Большое спасибо за статью!
У меня на проекте случилось тоже самое — при обновлении с 14 на 15 увеличилось потребление памяти, ограничения на размер Code Cache не было. На тот момент просто подняли лимиты в K8s, так как ресурсы были. Сейчас тоже думаю заняться вопросом исследования потребления памяти, т.к. функционал растёт, и память хочется ограничить везде, где можно.
Также хочу высказаться в поддержку того, что гораздо проще собирать костыли в небольшом количестве раз в полгода, чем сразу много оптом. Кроме того, все эти промежуточные релизы Java — это именно релизы, полноценные, прошедшие тесты. Это ведь не Beta, где реально могут что-то сломать. А багов каждый раз фиксят много.
Ну если, например, ваш код вызвал new long[Integer.MAX_VALUE], то именно тут можно и поймать OOM, и как-то обработать (запросить меньше?), и пойти выполняться дальше.
Всё-таки чаще это или дефолтный, или прям тут в приложении однажды описанный бин, которому нужно просто вызвать setTaskDecorator.
Если над одним кодом работает столько незнакомых людей, всё равно это ничего не ломает — они продолжают писать просто Async. Ситуация, когда и разработчиков овер-много, и тред-пулов в контекст уже набросали — за скоупом моего решения.
Свой decorator, который вешается на thread pool. Почти как таковой от security.
У меня свой mdc closeable, и утильный метод, который знает, что именно в MDC нужно прокидывать. Могу скинуть код, всё лаконично.
И да, sleuth в проекте присутствует и свои поля пробрасывает сам. У меня только нужные мне (api uri, логин юзера, т.п.).
Замечание, не касающееся редактора.
Практически всегда читаю Хабр с телефона. Так вот в мобильном Хроме недавно появилась возможность сделать свайпом "назад" и "вперёд" (проведя горизонтально от края экрана на середине высоты). Работает во всём этом интернете, кроме Хабра. Очень неудобно возвращаться из комментариев в статью или из статьи к списку статей обычными кнопками внизу одной рукой (второй качаю дочку в кроватке).
Как бы, понимаю, что мелочь...
Вот бы найти, если такой существует, список экзаменов и сертификаций по "всему этому IT". В том числе и как эти, CKA и CKS, а также Оракловые по Java и т.п.
Я извиняюсь, но правды ради:
Вот нет, не обёртка над ним. Я сам, если честно, их не использую, но имея желание нагуглить подтверждение вашему утверждению, сделать этого, увы, не смог.
Хм :) Гарантия отчитывается с момента "продажи" (запуска)? :)
Внезапно, начав мердж из сторонней тулзы, не смог найти Resolve conflicts в Идее. Только зная, что они существуют, нашёл через Search everywhere. Верните, плз.
Справедливости ради, Java-имплементации миграций есть у обоих инструментов.