Spring: событие опубликовано, обработчик не вызван
Событие опубликовано, исключений нет, а метод с
По умолчанию обработчик привязан к
Здесь речь об обычной транзакции, привязанной к потоку. Выбор фазы связывает обработчик с её исходом, но не обеспечивает гарантированную доставку во внешнюю систему.
Transaction-bound Events в Spring
#spring #java
Событие опубликовано, исключений нет, а метод с
@TransactionalEventListener не вызван. Сначала проверьте, была ли в момент публикации активная транзакция.По умолчанию обработчик привязан к
AFTER_COMMIT. При откате он не сработает. Если транзакции вообще нет, Spring пропустит вызов. Атрибут fallbackExecution=true явно разрешает обработку и в этом случае.Здесь речь об обычной транзакции, привязанной к потоку. Выбор фазы связывает обработчик с её исходом, но не обеспечивает гарантированную доставку во внешнюю систему.
Transaction-bound Events в Spring
#spring #java
Приглашаем на Java Jam — бесплатный митап ЮMoney для бэкенд-разработчиков 🔥
✅ 29 октября, четверг, 19:00 МСК — приходите на митап в Санкт-Петербурге или смотрите трансляцию.
Спикеры из ЮMoney и Сбера выступят с докладами:
🟣 Один апгрейд — больше сотни сервисов: как мы обновляем Java-стек в компании
Обсудим, как обновить Gradle, Spring Boot и Java в 120+ компонентах, не останавливая разработку. Расскажем, как выстраивали процессы на протяжении этого времени: от порядка действий и массовых патчей до взаимодействия с командами и решения трудностей, с которыми столкнулись во время последнего обновления.
🟣 Как я автоматизировал свой проект — и всё сломал
Разберём, как выстроить автоматизацию в проекте с помощью ИИ и какие шишки можно набить на пути. Поговорим, как работает длинный контекст в моделях и как организовать работу с учётом этих особенностей.
🟣 Откатить нельзя оставить: мониторинг выкладки релиза на основе Sentry
Ошибки случаются. Узнаем, какие из них появляются или возникают чаще после последнего релиза — и достаточно ли этого, чтобы принять решение об откате.
Зарегистрируйтесь, чтобы принять участие. Все подробности — на сайте митапа Java Jam👈
Спикеры из ЮMoney и Сбера выступят с докладами:
Обсудим, как обновить Gradle, Spring Boot и Java в 120+ компонентах, не останавливая разработку. Расскажем, как выстраивали процессы на протяжении этого времени: от порядка действий и массовых патчей до взаимодействия с командами и решения трудностей, с которыми столкнулись во время последнего обновления.
Разберём, как выстроить автоматизацию в проекте с помощью ИИ и какие шишки можно набить на пути. Поговорим, как работает длинный контекст в моделях и как организовать работу с учётом этих особенностей.
Ошибки случаются. Узнаем, какие из них появляются или возникают чаще после последнего релиза — и достаточно ли этого, чтобы принять решение об откате.
Зарегистрируйтесь, чтобы принять участие. Все подробности — на сайте митапа Java Jam
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Gradle: сгенерированный checksum ещё нужно проверить
Команда
При генерации этой базы Gradle доверяет тому, что уже доступно в репозиториях. Если JAR к этому моменту подменён, в базу попадёт checksum подменённого файла. Поэтому сгенерированные метаданные нужно проверить до принятия в проект.
Checksum подтверждает совпадение с доверенной базой. Он не ищет вредоносный код и сам по себе не устанавливает автора. Changing-зависимости, включая SNAPSHOT, и локальные артефакты этой проверкой не покрываются.
Руководство Gradle 9.7.0
Команда
./gradlew --write-verification-metadata sha256 собирает контрольные суммы зависимостей. Файл gradle/verification-metadata.xml затем служит базой для проверки загружаемых артефактов.При генерации этой базы Gradle доверяет тому, что уже доступно в репозиториях. Если JAR к этому моменту подменён, в базу попадёт checksum подменённого файла. Поэтому сгенерированные метаданные нужно проверить до принятия в проект.
Checksum подтверждает совпадение с доверенной базой. Он не ищет вредоносный код и сам по себе не устанавливает автора. Changing-зависимости, включая SNAPSHOT, и локальные артефакты этой проверкой не покрываются.
Руководство Gradle 9.7.0
Quarkus: три промаха кеша, один вызов метода
Несколько запросов одновременно обращаются к отсутствующему ключу. В Quarkus 3.27 с кешем на Caffeine аннотация
Это работает в пределах одного кеша, одного ключа и одного экземпляра приложения. У объектов, входящих в ключ, должны корректно работать equals() и hashCode(). Разные ключи обрабатываются отдельно. Между экземплярами приложения такой блокировки нет.
При попадании в кеш тело метода не выполняется.
Кеширование в Quarkus 3.27
Несколько запросов одновременно обращаются к отсутствующему ключу. В Quarkus 3.27 с кешем на Caffeine аннотация
@CacheResult обрабатывает такие обращения вместе: первый вызов вычисляет значение, остальные ждут результат.Это работает в пределах одного кеша, одного ключа и одного экземпляра приложения. У объектов, входящих в ключ, должны корректно работать equals() и hashCode(). Разные ключи обрабатываются отдельно. Между экземплярами приложения такой блокировки нет.
lockTimeout задаёт предел ожидания блокировки. Это не таймаут выполнения самого метода. По умолчанию предел ожидания отключён.При попадании в кеш тело метода не выполняется.
Кеширование в Quarkus 3.27
ResourceLock в JUnit: параллельный доступ на чтение
В параллельных тестах JUnit Jupiter
Два теста с
Параллельный запуск нужно включить и задать режим выполнения, например через
Это координация тестов Jupiter, объявивших один ресурс, а не блокировка между процессами ОС.
Parallel Execution и Synchronization
В параллельных тестах JUnit Jupiter
@ResourceLock объявляет общий ресурс по строковому имени и режим доступа к нему.Два теста с
READ для одного ресурса могут выполняться одновременно. READ_WRITE конфликтует с любым другим доступом к тому же ресурсу. Для аннотации на тестовом методе блокировка захватывается до @BeforeEach и освобождается после @AfterEach.Параллельный запуск нужно включить и задать режим выполнения, например через
@Execution(CONCURRENT). Одного флага enabled для параллельного выполнения тестов недостаточно.Это координация тестов Jupiter, объявивших один ресурс, а не блокировка между процессами ОС.
Parallel Execution и Synchronization
NMT в HotSpot: сначала включить, потом искать рост
Native Memory Tracking нужно включить при старте JVM, например флагом
После прогрева сохраните базу командой
NMT учитывает внутренние аллокации HotSpot, но не всю память стороннего native-кода. Рост категории даёт направление для диагностики, а не готовое доказательство утечки.
На карточке — команды из руководства Oracle Java 25.
Native Memory Tracking в HotSpot
#jvm #java
Native Memory Tracking нужно включить при старте JVM, например флагом
-XX:NativeMemoryTracking=summary. Если процесс уже работает без NMT, включить сбор через jcmd не получится.После прогрева сохраните базу командой
jcmd <pid> VM.native_memory baseline. Позже jcmd <pid> VM.native_memory summary.diff покажет изменения по категориям относительно неё.NMT учитывает внутренние аллокации HotSpot, но не всю память стороннего native-кода. Рост категории даёт направление для диагностики, а не готовое доказательство утечки.
На карточке — команды из руководства Oracle Java 25.
Native Memory Tracking в HotSpot
#jvm #java
Micrometer: каждый новый 404 может раздувать метрику
Если в собственной инструментализации записывать сырой URI в тег метрики, запросы к
Micrometer разбирает именно такой пример: если не ограничивать значения URI для 404, кардинальность метрики растёт с каждым новым отсутствующим ресурсом. Вместо произвольного пути можно использовать ограниченное значение вроде
Это задача проектирования собственных тегов. Из примера не следует, что все интеграции Spring Boot по умолчанию записывают сырые 404-пути.
На схеме меняется только тег URI. Значения условные, измерений памяти здесь нет.
Micrometer: Tag Values
Если в собственной инструментализации записывать сырой URI в тег метрики, запросы к
/missing/a, /missing/b и тысячам других несуществующих путей дадут тысячи разных значений тега.Micrometer разбирает именно такой пример: если не ограничивать значения URI для 404, кардинальность метрики растёт с каждым новым отсутствующим ресурсом. Вместо произвольного пути можно использовать ограниченное значение вроде
NOT_FOUND.Это задача проектирования собственных тегов. Из примера не следует, что все интеграции Spring Boot по умолчанию записывают сырые 404-пути.
На схеме меняется только тег URI. Значения условные, измерений памяти здесь нет.
Micrometer: Tag Values
Kafka: heartbeat не заменяет вызовы poll
Consumer может отправлять heartbeat и при этом слишком долго обрабатывать пачку. В Java-клиенте Kafka 4.0 прогресс проверяется отдельно: интервал между вызовами
Если интервал превышен, consumer рискует потерять партиции, а коммит может завершиться
Если обработку вынести в worker, consumer должен продолжать вызывать poll. Auto commit отключают, партиции приостанавливают до конца обработки, а offsets коммитят вручную только после обработки. Сам
KafkaConsumer 4.0: Detecting Consumer Failures
Consumer может отправлять heartbeat и при этом слишком долго обрабатывать пачку. В Java-клиенте Kafka 4.0 прогресс проверяется отдельно: интервал между вызовами
poll ограничивает max.poll.interval.ms.Если интервал превышен, consumer рискует потерять партиции, а коммит может завершиться
CommitFailedException. Размер пачки ограничивает max.poll.records. Увеличение интервала даёт больше времени на обработку, но может замедлить rebalance.Если обработку вынести в worker, consumer должен продолжать вызывать poll. Auto commit отключают, партиции приостанавливают до конца обработки, а offsets коммитят вручную только после обработки. Сам
KafkaConsumer не thread-safe: worker-потоки не должны произвольно вызывать его методы.KafkaConsumer 4.0: Detecting Consumer Failures
StampedLock: читать поля можно до проверки, использовать — после
Оптимистическое чтение в
Если за это время другой поток захватывал write lock, проверка провалится. В примере Oracle чтение повторяют уже под read lock. До проверки поля могут противоречить друг другу. При обходе изменяемого массива или вызове метода по прочитанной ссылке могут понадобиться дополнительные проверки согласованности данных.
Это механизм для коротких участков с известным устройством данных.
StampedLock, Java SE 25
#java
Оптимистическое чтение в
StampedLock обходится без удержания read lock. Поток получает stamp через tryOptimisticRead(), копирует поля в локальные переменные и вызывает validate(stamp). Использовать прочитанные значения можно после успешной проверки.Если за это время другой поток захватывал write lock, проверка провалится. В примере Oracle чтение повторяют уже под read lock. До проверки поля могут противоречить друг другу. При обходе изменяемого массива или вызове метода по прочитанной ссылке могут понадобиться дополнительные проверки согласованности данных.
Это механизм для коротких участков с известным устройством данных.
StampedLock не реентерабелен, а его политика не гарантирует предпочтения читателям или писателям.StampedLock, Java SE 25
#java
ClassValue хранит вычисленные данные для каждого класса
Таблицу методов для диспетчеризации или разобранные метаданные можно кешировать отдельно для каждого класса. Для такой задачи у JDK есть
При гонке вычисление может выполниться несколько раз. С классом свяжется одно значение, его и получат вызывающие потоки. Поэтому
ClassValue, Java SE 25
#java
Таблицу методов для диспетчеризации или разобранные метаданные можно кешировать отдельно для каждого класса. Для такой задачи у JDK есть
ClassValue<T>: get(type) возвращает значение, связанное с конкретным Class, и при необходимости запускает computeValue(type).При гонке вычисление может выполниться несколько раз. С классом свяжется одно значение, его и получат вызывающие потоки. Поэтому
computeValue должен допускать повторный вызов. Если внутри отправлять платёж или регистрировать ресурс с необратимым побочным эффектом, гарантий «ровно один раз» не будет.remove(type) убирает связь и инвалидирует устаревшие вычисления. При следующем обращении значение можно вычислить заново. Здесь удобно хранить именно данные, зависящие от класса, а не произвольный кеш по бизнес-ключам.ClassValue, Java SE 25
#java
Дерево процессов в ProcessHandle меняется во время обхода
Java-сервис запускает внешний конвертер, а тот порождает дочерние процессы.
Процесс из снимка может завершиться ещё до того, как до него дойдёт обход. Между проверкой
Поэтому один обход
ProcessHandle, Java SE 25
#java
Java-сервис запускает внешний конвертер, а тот порождает дочерние процессы.
children() даёт только прямых детей, descendants() — потомков всех уровней. Оба метода возвращают снимок, а не живую коллекцию.Процесс из снимка может завершиться ещё до того, как до него дойдёт обход. Между проверкой
isAlive() и действием тоже остаётся гонка. Хранить только PID тоже рискованно: после завершения процесса ОС может выдать этот номер другому.Поэтому один обход
descendants() не гарантирует, что вся группа процессов будет остановлена. Для управления внешней задачей нужны обработка ошибок и учёт ограничений ОС. ProcessHandle не даёт прав сверх тех, что есть у обычного нативного приложения.ProcessHandle, Java SE 25
#java
transferTo может скопировать меньше запрошенного
Вызов
При повторном вызове нужно сдвинуть явный offset и уменьшить остаток на число переданных байтов. Позиция исходного
Если метод вернул ноль, повтор без ожидания готовности target или проверки конца файла может превратиться в пустой цикл.
ОС иногда передаёт данные прямо из файлового кеша. Это может ускорить передачу, но документация не обещает zero-copy для любой системы и любого канала.
FileChannel.transferTo, Java SE 25
#java
Вызов
FileChannel.transferTo(position, count, target) возвращает число реально переданных байтов. Оно может быть меньше count и даже равняться нулю. Например, у неблокирующего target может не хватить места в выходном буфере.При повторном вызове нужно сдвинуть явный offset и уменьшить остаток на число переданных байтов. Позиция исходного
FileChannel сама не меняется. Если offset уже достиг текущего размера файла, новых байтов не будет.Если метод вернул ноль, повтор без ожидания готовности target или проверки конца файла может превратиться в пустой цикл.
ОС иногда передаёт данные прямо из файлового кеша. Это может ускорить передачу, но документация не обещает zero-copy для любой системы и любого канала.
FileChannel.transferTo, Java SE 25
#java
G1 не использует остаток региона после большого объекта
G1 в JDK 25 считает humongous объект размером не меньше половины региона. Он попадает в последовательность соседних регионов old generation. Остаток последнего региона недоступен другим аллокациям до освобождения всего объекта.
Поэтому свободные байты в heap ещё не означают, что для следующего большого объекта найдётся достаточно соседних свободных регионов. Размер региона G1 выбирает автоматически, если его не задали через
Ставшие недостижимыми humongous-объекты обычно освобождаются на Remark или Full GC. Для массивов примитивов есть механизм раннего освобождения. Одна большая аллокация сама по себе не означает обязательный Full GC: поведение нужно сопоставлять с логами и заполнением heap.
Oracle: Humongous Objects, JDK 25
#jvm
G1 в JDK 25 считает humongous объект размером не меньше половины региона. Он попадает в последовательность соседних регионов old generation. Остаток последнего региона недоступен другим аллокациям до освобождения всего объекта.
Поэтому свободные байты в heap ещё не означают, что для следующего большого объекта найдётся достаточно соседних свободных регионов. Размер региона G1 выбирает автоматически, если его не задали через
-XX:G1HeapRegionSize.Ставшие недостижимыми humongous-объекты обычно освобождаются на Remark или Full GC. Для массивов примитивов есть механизм раннего освобождения. Одна большая аллокация сама по себе не означает обязательный Full GC: поведение нужно сопоставлять с логами и заполнением heap.
Oracle: Humongous Objects, JDK 25
#jvm
🤨1
Завершённый шаг Spring Batch при рестарте пропускается
Job упал на финальном шаге. При рестарте того же
Другая настройка,
Настройки рестарта не отменяют уже отправленное письмо или выполненный внешний HTTP-запрос. Что произойдёт при повторе таких действий, нужно определить в самом шаге и его интеграциях.
Spring Batch 6.0.6: Configuring a Step for Restart
#spring
Job упал на финальном шаге. При рестарте того же
JobInstance Spring Batch обычно пропускает шаги со статусом COMPLETED. Если проверку входных данных или уборку ресурсов нужно выполнять каждый раз, у шага задают allowStartIfComplete(true).Другая настройка,
startLimit, ограничивает число запусков шага. В примере документации лимит равен 2: после двух неудач на третьей попытке шаг уже не запускается. Повтор требует вмешательства, например изменения лимита или запуска нового JobInstance.Настройки рестарта не отменяют уже отправленное письмо или выполненный внешний HTTP-запрос. Что произойдёт при повторе таких действий, нужно определить в самом шаге и его интеграциях.
Spring Batch 6.0.6: Configuring a Step for Restart
#spring
Opaque token проверяется через сервер авторизации
При introspection Resource Server отправляет bearer token на endpoint сервера авторизации со своими учётными данными. В ответе Spring Security проверяет
По умолчанию principal —
В стандартной цепочке проверка токена зависит от доступности introspection endpoint. Собственный кеш меняет частоту обращений к нему и поведение при отзыве токена. При такой настройке нельзя заранее обещать мгновенный отзыв.
Spring Security 7.1.2: Opaque Token
#spring
При introspection Resource Server отправляет bearer token на endpoint сервера авторизации со своими учётными данными. В ответе Spring Security проверяет
active: true, а scopes превращает в authorities с префиксом SCOPE_.По умолчанию principal —
OAuth2AuthenticatedPrincipal. Имя аутентификации берётся из sub, если это поле есть в ответе. Для настройки нужны адрес introspection endpoint, client ID и client secret.В стандартной цепочке проверка токена зависит от доступности introspection endpoint. Собственный кеш меняет частоту обращений к нему и поведение при отзыве токена. При такой настройке нельзя заранее обещать мгновенный отзыв.
Spring Security 7.1.2: Opaque Token
#spring
BTrace: временная трассировка работающей JVM
Когда нужен ответ на конкретный вопрос о работающем Java-приложении, BTrace позволяет подключить Java-пробу к процессу. Инструментация временная, без изменения кода приложения и его перезапуска.
В wiki BTrace для стабильной ветки 2.2.x указан namespace
BTrace можно применять вместе с JFR: JFR даёт непрерывную историю, проба помогает собрать целевые наблюдения для текущей диагностики. Перед подключением нужно отдельно проверить совместимость с целевой JVM и права на attach. Описание инструмента не гарантирует, что проба будет безопасной, а накладные расходы — низкими на вашей нагрузке.
Когда нужен ответ на конкретный вопрос о работающем Java-приложении, BTrace позволяет подключить Java-пробу к процессу. Инструментация временная, без изменения кода приложения и его перезапуска.
В wiki BTrace для стабильной ветки 2.2.x указан namespace
org.openjdk.btrace. Это стоит учитывать при поиске примеров: старый скрипт и текущая версия инструмента могут использовать разные имена пакетов.BTrace можно применять вместе с JFR: JFR даёт непрерывную историю, проба помогает собрать целевые наблюдения для текущей диагностики. Перед подключением нужно отдельно проверить совместимость с целевой JVM и права на attach. Описание инструмента не гарантирует, что проба будет безопасной, а накладные расходы — низкими на вашей нагрузке.
Что считает circuit breaker, если рядом есть retry
Порядок обёрток определяет, какие вызовы попадают в окно breaker. Если retry снаружи, а breaker внутри, breaker видит каждую попытку. При обратном порядке он видит итог целого запроса после повторов. Три попытки могут стать тремя записями в окне или одной.
В учебном проекте Fuse разобраны оба варианта. В цепочке декораторов последняя добавленная политика оказывается внешней. От порядка обёрток зависит и момент, когда breaker узнает о сбое.
Отдельная ловушка — повторять
Fuse полезен как разбор реализации. Для production его автор рекомендует Resilience4j.
Порядок обёрток определяет, какие вызовы попадают в окно breaker. Если retry снаружи, а breaker внутри, breaker видит каждую попытку. При обратном порядке он видит итог целого запроса после повторов. Три попытки могут стать тремя записями в окне или одной.
В учебном проекте Fuse разобраны оба варианта. В цепочке декораторов последняя добавленная политика оказывается внешней. От порядка обёрток зависит и момент, когда breaker узнает о сбое.
Отдельная ловушка — повторять
CallNotPermittedException от открытого breaker. До зависимости вызов уже не дошёл, а retry может продолжить тратить бюджет попыток и ждать backoff. Автор предлагает исключить этот тип из повторов.Fuse полезен как разбор реализации. Для production его автор рекомендует Resilience4j.