Camunda Cockpit и Rest API отключены, но приложение работает / Конфигурация JobExecutor - PullRequest
Новая
       34

Camunda Cockpit и Rest API отключены, но приложение работает / Конфигурация JobExecutor

0 голосов
/ 17 ноября 2018

Мы столкнулись с серьезным инцидентом в нашем оркестре Camunda.Когда мы попадаем в 100 запущенных экземпляров процесса, Camunda Cockpit занимает вечность и никогда не отвечает.У нас та же проблема при вызове / app / engine /.Из RabbitMQ поступает несколько сообщений, а затем все останавливается.

Приложение не выключено.Я подозреваю, что проблема конфигурации механизма процесса из-за невозможности получить журнал исполнителя задания.

Когда я устанавливаю для JobExecutorActivate значение false, все происходит правильно для потребления кабины и очереди, но процессы останавливаются в концепервый подпроцесс.

У нас есть этот цикл журнала без остановок: 

2018/11/17 14:47:33.258 DEBUG ENGINE-14012 Job acquisition thread woke up
2018/11/17 14:47:33.258 DEBUG ENGINE-14022 Acquired 0 jobs for process engine 'default': []
2018/11/17 14:47:33.258 DEBUG ENGINE-14023 Execute jobs for process engine 'default': [8338]
2018/11/17 14:47:33.258 DEBUG ENGINE-14023 Execute jobs for process engine 'default': [8217]
2018/11/17 14:47:33.258 DEBUG ENGINE-14023 Execute jobs for process engine 'default': [8256]
2018/11/17 14:47:33.258 DEBUG ENGINE-14011 Job acquisition thread sleeping for 100 millis
2018/11/17 14:47:33.359 DEBUG ENGINE-14012 Job acquisition thread woke up

И этот журнал тоже (для потребления в очереди): 

2018/11/17 15:04:19.582 DEBUG Waiting for message from consumer. {"null":null}
2018/11/17 15:04:19.582 DEBUG Retrieving delivery for Consumer@5d05f453: tags=[{amq.ctag-0ivcbc2QL7g-Duyu2Rcbow=queue_response}], channel=Cached Rabbit Channel: AMQChannel(amqp://guest@127.0.0.1:5672/,4), conn: Proxy@77a5983d Shared Rabbit Connection: SimpleConnection@17a1dd78 [delegate=amqp://guest@127.0.0.1:5672/, localPort= 49812], acknowledgeMode=AUTO local queue size=0 {"null":null}

Среда: Spring Boot 2.0.3.RELEASE, Camunda v7.9.0 с PostgreSQL, RabbitMQ

Camunda BPM прослушивает и отправляет в 165 очередь RabbitMQ.

Конфигурация: 

# Data source (PostgreSql)
com.campDo.fr.camunda.datasource.url=jdbc:postgresql://localhost:5432/campDo
com.campDo.fr.camunda.datasource.username=campDo
com.campDo.fr.camunda.datasource.password=password
com.campDo.fr.camunda.datasource.driver-class-name=org.postgresql.Driver
com.campDo.fr.camunda.bpm.database.jdbc-batch-processing=false
oms.camunda.retry.timer=1
oms.camunda.retry.nb-max=2

SpringProcessEngineConfiguration: 

@Bean
    public SpringProcessEngineConfiguration processEngineConfiguration() throws IOException {
        final SpringProcessEngineConfiguration config = new SpringProcessEngineConfiguration();
        config.setDataSource(camundaDataSource);
        config.setDatabaseSchemaUpdate("true");
        config.setTransactionManager(transactionManager());
        config.setHistory("audit");
        config.setJobExecutorActivate(true);
        config.setMetricsEnabled(false);
        final Resource[] resources = resourceLoader.getResources(CLASSPATH_ALL_URL_PREFIX + "/processes/*.bpmn");
        config.setDeploymentResources(resources);

        return config;
    }

Pom зависимости: 

 <dependency>
            <groupId>org.camunda.bpm.springboot</groupId>
            <artifactId>camunda-bpm-spring-boot-starter</artifactId>
        </dependency>
        <dependency>
            <groupId>org.camunda.bpm.springboot</groupId>
            <artifactId>camunda-bpm-spring-boot-starter-webapp</artifactId>
        </dependency>
        <dependency>
            <groupId>org.camunda.bpm.springboot</groupId>
            <artifactId>camunda-bpm-spring-boot-starter-rest</artifactId>
        </dependency>

Я совершенно уверен, что моя конфигурация исполнителя задания неверна.

Обновление:

Я могу запустить кабину и заставить Камунду принимать сообщения, установив для JobExecutorActivate значение false, но процессы по-прежнему останавливаются на первом шаге, необходимом исполнителю задания: 

config.setJobExecutorActivate(false);

Спасибо за твой чочь.

1 Ответ

0 голосов
/ 28 ноября 2018

Первое: если ваш процесс содержит асинхронные шаги (задания), он будет приостановлен. Активация jobExecutor просто скажет, что camunda должен управлять тем, как работают эти задания. Если вы отключите исполнителя, ваши процессы все равно будут остановлены, и, поскольку никто не выполнит их, они останутся остановленными. Отключение выполнения задания имеет смысл только во время тестирования или когда у вас есть несколько узлов, и только некоторые из них должны выполнять обработку.

К вашей основной проблеме: исполнитель заданий работает с ThreadPool. Исходя из того, что вы описываете, очень вероятно, что все потоки в пуле блокируются навсегда, поэтому они никогда не завершаются и никогда не возвращаются, что означает, что ваша система зависла.

Это случилось с нами некоторое время назад, когда мы работали с сервером smtp, в соединении было бесконечное время ожидания, поэтому потоки продолжали ждать, хотя машина была недоступна.

Поскольку выполнение работы в камунде очень надежно и хорошо проверено само по себе, я бы посоветовал вам еще раз проверить все, что вы делаете в своих делегатах, если вам повезет (и я прав), вы найдете место, где вы просто ждете навсегда ...

...