План Карафа заблокирован при запуске с остановкой пакетов
Уже несколько месяцев мы используем karaf версии 2.3.3 в системе, которая принимает файлы данных, переводит данные в объекты и сохраняет данные в постоянном хранилище.
Недавно мы заметили, что когда karaf останавливается / перезапускается, пакеты на некоторое время переходят в какое-то заблокированное состояние.
Вот последовательность событий:
1) Во время выполнения chef-пакета пакеты развертываются в каталоге развертывания, пока karaf не работает
2) Когда появляется караф, все связки и чертежи разрешаются правильно
3) Когда karaf зацикливается, связки разрешаются правильно, но чертежи переходят в заблокированное состояние, когда большинство находится в рабочем состоянии, но один находится в состоянии остановки, а некоторые могут находиться в разрешенном состоянии.
4) Через 5 минут (тайм-аут) стоп-пакет переходит в разрешенное состояние, а другой пакет переходит в состояние остановки.
5) Иногда (в большинстве случаев?), Если вы будете ждать достаточно долго, все пакеты в конечном итоге перейдут в активное состояние, и система будет полностью загружена.
Пока запускается karaf, я могу использовать клиент karaf для выдачи команд list и наблюдать за запуском пакетов. Они из цикла:
Установлено -> Разрешено -> Активно,
в то время как чертежи цикла из:
пусто -> Создание -> Создано с периодическим добавлением GracePeriod во время запуска зависимых сервисов.
После того, как окажется, что все службы активны и все чертежи созданы, один пакет застрянет в состоянии остановки, а другие вернутся в состояние разрешения:
[ 136] [Active ] [Created ] [ 80] transformation-services (1.0.3)
[ 137] [Active ] [Created ] [ 80] event-services (0.1.2)
[ 138] [Active ] [Created ] [ 80] ftp-services (0.0.0)
[ 139] [Active ] [Created ] [ 80] ingest-resources (0.0.1)
[ 140] [Active ] [Created ] [ 80] orchestration-app (0.2.3)
[ 141] [Active ] [Created ] [ 80] aws-services (0.4.0)
[ 142] [Resolved ] [ ] [ 80] point-data-service-test (0.2.0)
[ 143] [Active ] [Created ] [ 80] event-consumer-app (1.3.4)
[ 144] [Stopping ] [ ] [ 80] XXXX_no_op_log_transform.xml (0.0.0)
[ 145] [Resolved ] [ ] [ 80] persistence-app (1.3.3)
[ 146] [Active ] [Created ] [ 80] ftp-ingest-endpoint (1.0.2)
[ 147] [Resolved ] [ ] [ 80] secondary_ftp.xml (0.0.0)
[ 148] [Resolved ] [ ] [ 80] event-rest-test (0.0.0)
[ 149] [Resolved ] [ ] [ 80] customer_credentials.xml (0.0.0)
[ 150] [Resolved ] [ ] [ 80] customer1_xml.xml (0.0.0)
[ 151] [Active ] [Created ] [ 80] endpoint-services (0.0.0)
[ 152] [Active ] [Created ] [ 80] scheduler-services (0.1.0)
[ 153] [Active ] [Created ] [ 80] fourhundred_xml.xml (0.0.0)
[ 154] [Active ] [Creating ] [ 80] point-data-service (2.3.3)
[ 155] [Installed ] [ ] [ 80] customer1_csv.xml (0.0.0)
У нас есть около 20 пользовательских пакетов, которые выполняют различные услуги. Некоторые описывают сервисы, которые выполняются у запланированного исполнителя. Некоторые выставляют cxf REST сервисы. Некоторые из них представляют собой простые файлы чертежей, которые были добавлены в каталог развертывания karaf. Мы используем шаблон доски для поиска, регистрации и доступа к сервисам из файлов чертежей, которые были сброшены в ходе горячего развертывания.
Я поиграл с использованием файла функций или установкой начальных уровней комплекта, но все еще вижу то же поведение. Я обнаружил несколько JIRA, в которых говорится о проблеме, связанной с синхронизацией чертежей ( https://issues.apache.org/jira/browse/KARAF-1724 https://issues.apache.org/jira/browse/ARIES-1051), но на самом деле не даю никаких реальных советов.
Кто-нибудь сталкивался с такой же проблемой и придумал надежный способ ее обойти?