В результате теста производительности JMeter возникает тупик Activiti

Question

У меня проблема с параллелизмом activiti. У нас есть приложение с калиткой и встроенным движком activiti. Он отлично работает без одновременных пользователей, но во время теста производительности jmeter activiti создает тупик на своих собственных таблицах. Например: ACT_RU_JOB, ACT_RU_EXECUTION, ACT_RU_VARIABLE. Я нашел тему на форуме activiti об этой проблеме ( Activiti Forum). Они предлагают использовать очереди для запуска процессов activiti. Это решение не решило проблему, потому что все еще существуют тупики. Я предоставляю некоторую конфигурацию и трассировку стека для вас. Все ответы могут быть полезны для меня. Спасибо за помощь!

моя конфигурация activiti:

<bean id="processEngineConfiguration" class="org.activiti.spring.SpringProcessEngineConfiguration">
        <property name="databaseType" value="mssql" />
        <property name="dataSource" ref="dataSource" />
        <property name="transactionManager" ref="transactionManagerLugy" />
        <property name="databaseSchemaUpdate" value="true" />
        <property name="jobExecutorActivate" value="true" />
        <property name="deploymentResources" value="classpath*:/diagrams/idm/*.bpmn20.xml" />   
        <property name="history" value="none"/>     
        <property name="jdbcMaxActiveConnections" value="1000"/>
        <property name="jdbcMaxIdleConnections" value="10"/>
        <property name="jdbcMaxWaitTime" value="50000"/>
    </bean> 


    <bean id="processEngine" class="org.activiti.spring.ProcessEngineFactoryBean">
        <property name="processEngineConfiguration" ref="processEngineConfiguration" />
    </bean>

трассировки стека:

### Error querying database.  Cause: org.hibernate.exception.LockAcquisitionException: Transaction (Process ID 67) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
### The error may involve org.activiti.engine.impl.persistence.entity.VariableInstanceEntity.selectVariablesByExecutionId-Inline
### The error occurred while setting parameters
### Cause: org.hibernate.exception.LockAcquisitionException: Transaction (Process ID 67) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
    at org.springframework.jms.listener.adapter.MessageListenerAdapter.invokeListenerMethod(MessageListenerAdapter.java:471)
    at org.springframework.jms.listener.adapter.MessageListenerAdapter.onMessage(MessageListenerAdapter.java:355)
    at org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:535)
    at org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:495)
    at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:467)
    at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:325)
    at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263)
    at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1058)
    at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1050)
    at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:947)
    at java.lang.Thread.run(Thread.java:662)

Answer 1

Я удалил все таймеры из своей диаграммы активности, и тупики исчезли. Я не знаю почему, но это работает.

Answer 2

У меня также была проблема мертвой блокировки при выполнении теста jmeter.

В моем случае проблема заключается в том, что в моем пуле DataSource содержится не более 10 соединений, но было 100 потоков, обращающихся к API, которые создают экземпляр процесса, которому необходимо создать асинхронную задачу.

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

Когда я установил размер пула больше, чем количество потоков jmeter, проблема исчезла.

- Моя версия activiti - 5.19.0