В результате теста производительности JMeter возникает тупик Activiti - PullRequest
Новая
       12

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

3 голосов
/ 12 июля 2011

У меня проблема с 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)

Ответы [ 2 ]

1 голос
/ 23 августа 2011

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

0 голосов
/ 19 марта 2018

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

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

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

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

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

...