Задержка принятия следующего Jms сообщения после ошибки
Вариант реализации JmsListenerContainerFactory (на основе DefaultJmsListenerContainerFactory) для задержки принятия следующего jms сообщения, если был выброшен необработанный эксепшен: Инициализация выглядит следующим образом
9.Транзакционность в JMS
Транзакционность используется для возвращения сообщения обратно в очередь, в случае возникновения исключения при его обработке. Для настройки транзакционности, нужно указать ContainerFactory бину — бин PlatformTransactionManager. Пример настроек JMS: Для того, чтобы rollback сообщения сработал, достаточно чтобы из метода помеченного @JmsListener выбросилось необработанное исключение. Таким образом, исходное сообщение снова появится в очереди и его хэадер JMSXDeliveryCount увеличится на 1. Но здесь есть сайд-эффект, т.к. это сообщение через секунду снова залетит в приложение. Таким образом, если исключение будет постоянно появляться — мы попадём в бесконечный цикл ( есть способ задержки принятия следующего Jms сообщения после ошибки ). По поводу транзакционности, есть пара статуй от IBM: https://community.ibm.com/community/user/integration/blogs/stephanie-wilkerson1/2021/02/25/understanding-mq-backout-queues-thresholds https://www.ibm.com/docs/en/ibm-mq/9.2?topic=applications-handling-poison-messages-in-mq-classes-jms
Кастомная Jackson десериализация/сериализация
Допустим, имеем такую DTO: А нам нужно десериализовать из такого json: То используем над полем аннотацию @JsonDeserialize(using = ProductDtoDeserializer.class) и делаем десериализатор А теперь сделаем так, чтобы строковое поле сериализовывалось в UpperCase
Как настроить ssh при работе (GitLab/GitHub) + SmartGit
GitLab: GitHub: В смартгит можно управлять ключами в Edit -> Properties -> Authentication
Проверка json в mockMVC тестах и не только
Протестировать ваш jsonPath можно в сервисе https://jsonpath.com/ Кроме того, просто извлечь значение согласно указанного jsonPath можно так:
Настройка Gitlab CI/CD для java приложения
1. Создание раннера Для начала нам нужно организовать постоянно работающий процесс (runner), который будет выполнять все задачи по нашему CICD (т.е. задания билдинга, проверки, закрузки на сервер и выполнения в нём каких-то команд). Кстати, у гитлаба есть много разных публичных runner’ов, но, во-первых — я бы не хотел чтобы код моего закрытого репозитория улетал на какие-то непонятные раннеры, во-вторых — раннер надо настроить под конкретную задачу, чтобы адекватно кешировались промежуточные результаты и не тормозил весь процесс снова и снова проделывая одни и те же операции. В общем, про установку гитлаб раннеров написано здесь. Я буду поднимать на имеющемся ubuntu сервере докер контейнер с раннером. Установленный раннер регистрируется на gitlab и постоянно спрашивает у него новые задачи. Как только задача будет получена, то раннер создаёт ещё один докер-контейнер рядом с собой и задача уже выполняется в том контейнере. После выполнения контейнер удаляется. Для того чтобы это работало, раннеру, который сам будет…
Добавление модулей в ObjectMapper
Часто бывают проблемы с десериализацией дат из строки в, например, LocalDateTime. Порой это выглядит так: Есть несколько способов решить эту проблему. Один из них е использование аннотации @JsonFormat над нужным полем в dto Но бывают случаи, когда такое решение не приемлемо. Однако, есть ещё способ — кастомизация самого ObjectMapper’а. Я имею в виду про добавление модулей для сериализации/десериализации. Например, добавление модуля поддержки jsr310: Или добавление модуля поддержки joda: Наряду с этим, есть возможность писать собственные модули для сериализации/десериализации чего угодно. Не отходя от темы дат, приведу пример десериализации даты, представленной в любом из ожидаемых форматов: где классы выглядят так:
Профилирование java приложений
Если приложение сжирает слишком много памяти, либо сильно грузит проц, то можно на скорую руку сделать его профилирование. Ниже представлены команды, которые, при запуске на сервере, могут дать понять — в чём проблема. Отображение потребления ресурсов потокам С помощью диспетчера процессов top, можно отобразить список потоков приложения: где 20345 — это PID запущенного процесса Вашего приложения Сэмплинг Помогает найти тормозные методы в приложении. Суть метода заключается в выполнении скоупа нескольких одинаковых запросов. Каждый запрос показывает методы, в которых в данный момент находятся потоки приложения. Таким образом, если в нескольких запросах фигурирует один и тот же метод, то можно предположить, что он является очень долгим и, возможно, требует оптимизации. Команда для выполнения одного запроса: где 20345 — это PID запущенного процесса Вашего приложения (можно узнать в диспетчере процессов top), ru.knastnt — корневое имя всех пакетов в моём приложении. Это нужно чтобы показывать только методы, написанные непосредственно мной. Потому что без grep,…
2. JMS + IBM MQ + Tests
Нужно написать интеграционный тест для тестирования обработки входящих в топик сообщений. Для этого нужно будет настроить тестовый контекст таким образом, чтобы поднимался встроенный JMS-сервер, через который осуществлялось бы взаимодействие. Буду рассматривать приложение, описанное в первой статье: https://blog.knasys.ru/1-jms-ibm-mq-pub-sub/ Я не нашел информации о том можно ли встроить IBM MQ в приложение, поэтому встраивать будем ActiveMQ (он так умеет точно =) ), а поскольку он тоже является реализацией JMS, то проблем быть не должно. Для начала нам понадобится зависимость: Далее, для тестового профиля, нам следует отключить бины внутри основной конфигурации, которые настраивают связь с сервером IBM MQ, т.е. над бинами ru.knastnt.springjmsibmmq.config.IbmMqConfiguration.MQConfigurationProperties и ru.knastnt.springjmsibmmq.config.IbmMqConfiguration.MQConnectionFactory поставить аннотацию @Profile(«!test») Теперь создадим родительский класс для всех интеграционнах тестов, в котором опишем все требования к контексту. Сразу после добавления зависимости, в приложении будет стартовать встроенный брокер сообщений Acrive MQ, осталось только добавить ConnectionFactory для создания подключения к нему (называться он должен так же как и ConnectionFactory для…
1. JMS + IBM MQ — чтение из топика (паттерн Publisher/Subscriber)
Для начала нам понадобится сервис IBM MQ. Поднимаем его локально с помощью Docker. Для этого выполним команду в консоли: В результате скачается и запустится образ. Будут проброшены 2 порта — 11414 (для взаимодействия с MQ) и 9443 (web-интерфейс).Web-интерфейс поднимется не сразу, у меня он начинает работать только минуты через 4 после запуска контейнера. До этого то соединение сброшено, то ошибка установки защищённого соединения, то неожиданный ответ. В итоге, когда web-интерфейс — таки поднимется, зайти в него можно используя логин и пароль Подключение к web: https://localhost:9443/Логин/пароль: admin passw0rd Настройки по умолчанию: Имя администратора очередей: QM1Канал: DEV.ADMIN.SVRCONN Внутри Web-интерфейса можно ничего не делать. Теперь нам нужно будет иметь возможность кидать тестовые сообщения (например, в web-интерфейсе я не нашёл возможности этого делать). Поэтому устанавливаем программу MQ Explorer View. Установка MQ Explorer View:https://www.ibm.com/docs/en/ibm-mq/9.1?topic=windows-installing-stand-alone-mq-explorerДля скачивания нужно будет зарегистрироваться на сайте. В итоге у меня скачался файл 9.1.5.0-IBM-MQ-Explorer-Win64.zip размером около 400Мб. Установка не вызывает затруднений. Но…