Сбой кварца в методе notifyJobStoreJobComplete

Question

Сценарий:

1. У нас есть планировщик, который использует JDBC Job Store.Версия кварца - 2.1.2.
2. Планируемое задание также обновляет базу данных.
3. База данных одинакова как для кварца, так и для самого задания и размещена на MySQL Server.Таблицы приложений и кварцевые таблицы хранятся в одной базе данных.

4. Пул соединений различен как для приложения, так и для кварца.В приложении мы используем пружину для пула соединений, а кварц вынужден использовать пул соединений через quartz.properties.Вот фрагмент кода quartz.properties

   org.quartz.dataSource.qzDS.driver = com.mysql.jdbc.Driver
   org.quartz.dataSource.qzDS.URL = jdbc:mysql://localhost:3306/dbname?autoReconnect=true
   org.quartz.dataSource.qzDS.user = dbuser
   org.quartz.dataSource.qzDS.password =dbpassword
   org.quartz.dataSource.qzDS.maxConnections = 30
   org.quartz.datasource.qzDS.validationQuery = select 1
   #org.quartz.datasource.qzDS.minEvictableIdleTimeMillis=21600000
   #org.quartz.datasource.qzDS.timeBetweenEvictionRunsMillis=1800000
   #org.quartz.datasource.qzDS.numTestsPerEviction=-1
   #org.quartz.datasource.qzDS.testWhileIdle=true
   org.quartz.datasource.qzDS.debugUnreturnedConnectionStackTraces=true
   org.quartz.datasource.qzDS.unreturnedConnectionTimeout=120
   org.quartz.datasource.qzDS.initialPoolSize=5
   org.quartz.datasource.qzDS.minPoolSize=5
   org.quartz.datasource.qzDS.maxPoolSize=30
   org.quartz.datasource.qzDS.acquireIncrement=5
   org.quartz.datasource.qzDS.maxIdleTime=120
   org.quartz.datasource.qzDS.validateOnCheckout=true
   

5. База данных кластеризована с репликацией MASTER-MASTER на двух серверах и используется через виртуальный IP везде в приложении и в кварце.

6. Планировщик, т.е. кварц также кластеризован на тех же двух машинах, где MySQL кластеризован.

Проблема:

Один из серверов (до сих пор мыпроблема с сервером резервного копирования) иногда выдает ошибку соединения с базой данных при вызове метода notifyJobStoreJobComplete.Это приводит к тому, что задание остается в состоянии «ЗАБЛОКИРОВАНО», даже если само задание успешно завершено, но кварц не смог обновить его состояние.

Вопросы:

1. В чем может быть причинапроблема?
2. Как перевести ЗАБЛОКИРОВАННЫЕ задания в состояние ОЖИДАНИЯ, чтобы задания можно было запускать по крайней мере в свое следующее запланированное время.Прямое редактирование таблиц QRTZ_SIMPLE_TRIGGERS не будет хорошим решением, даже если оно будет работать.

РЕДАКТИРОВАТЬ: чтобы поднять вопрос.

Answer 1

Я думаю, что основной проблемой был сбой линии связи MySQL, который мы решили, увеличив «wait_timeout» до 14 дней, и поскольку наше обслуживание запланировано каждые 15 дней, мы перезапускаем каждый сервер MySQL в нашем кластере БД (у нас есть Мастер-Мастер репликации на месте). С подходом у нас не будет никакого отказа линии связи после этого. Фактически, некоторое время мы не перезагружаем сервер каждые 15 дней, но все равно ошибки не возникает (touch wood) :)

И поскольку триггеры Quartz заблокированы в состоянии BLOCKED, мы обновили кварц до версии 2.1.4, в которой возможно исправление почти такой же проблемы . После обновления кварца мы столкнулись с тем, что триггеры находятся в БЛОКИРОВАННОМ состоянии очень и очень редко.

Мы все еще не можем выяснить, как вывести триггер из состояния BLOCKED без непосредственной модификации кварцевых таблиц. Всякий раз, когда мы сталкиваемся с этой проблемой, мы вручную удаляем запись для триггера BLOCKED из таблицы qrtz_fired_triggers, и это решает проблему. Я думаю, что корпоративная версия кварца может иметь эту функцию из некоторого веб-интерфейса.

Answer 2

ошибка во время notifyJobStoreJobComplete: org.quartz.impl.jdbcjobstore.JobStoreTX - Не удалось переопределить автоматическую фиксацию соединения / изоляцию транзакции. [java] com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Последний пакет, успешно полученный от сервера, был 619,082,686 миллисекунд назад. Последний пакет, успешно отправленный на сервер, был 619,082,686 миллисекунд назад. больше, чем сконфигурированное сервером значение wait_timeout. Чтобы избежать этой проблемы, следует рассмотреть возможность истечения срока действия и / или проверки допустимости соединения перед использованием в приложении, увеличения значений, настроенных сервером для тайм-аутов клиента, или использования свойства соединения Connector / J 'autoReconnect = true'.