Exception while running Vacation Request flow

[vishals]

Hi,

I am getting the following exception when i am running the Vacation Request flow. Also i would like to give a context along with this regarding my application. I am current using activiti-emgine as a jar in my spring application and am developing functionality where in i am using following operations formService.submitStartFormData & formService.submitTaskFormData to carry out the workflow activities. The exception occurs on execution of method formService.submitTaskFormData (not the first time, but on the second loop as the user adjust his days and resends it to his manager and then the manager tries to confirm the adjusted request, in the context of vacation request flow).

Exception:
org.apache.ibatis.exceptions.TooManyResultsException: Expected one result (or null) to be returned by selectOne(), but found: 2
   at org.apache.ibatis.session.defaults.DefaultSqlSession.selectOne(DefaultSqlSession.java:42)
   at org.activiti.engine.impl.db.DbSqlSession.selectOne(DbSqlSession.java:175)
   at org.activiti.engine.impl.db.DbHistorySession.findHistoricActivityInstance(DbHistorySession.java:76)
   at org.activiti.engine.impl.history.HistoricFormPropertyEntity.<init>(HistoricFormPropertyEntity.java:45)
   at org.activiti.engine.impl.cmd.SubmitTaskFormCmd.execute(SubmitTaskFormCmd.java:63)
   at org.activiti.engine.impl.interceptor.CommandExecutorImpl.execute(CommandExecutorImpl.java:22)
   at org.activiti.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:37)
   at org.activiti.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:42)
   at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:130)
   at org.activiti.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:40)
   at org.activiti.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:33)
   at org.activiti.engine.impl.FormServiceImpl.submitTaskFormData(FormServiceImpl.java:64)
   at org.mkcl.insyncflow.controller.WorkflowController.submitUserTask(WorkflowController.java:196)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:176)
   at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:427)
   at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:415)
   at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:788)
   at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:717)
   at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:644)
   at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:560)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
   at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
   at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
   at org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter.doFilterInternal(OpenEntityManagerInViewFilter.java:113)
   at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
   at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
   at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
   at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:366)
   at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
   at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
   at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:378)
   at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:97)
   at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:378)
   at org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:100)
   at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:378)
   at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:78)
   at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:378)
   at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:54)
   at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:378)
   at org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:35)
   at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:378)
   at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:187)
   at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:378)
   at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:105)
   at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:378)
   at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:79)
   at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:378)
   at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:167)
   at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
   at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
   at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
   at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
   at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
   at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
   at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
   at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
   at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
   at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
   at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
   at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
   at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
   at java.lang.Thread.run(Thread.java:680)

Please let me know the solution, if this a bug or if am making any mistake. Thanks

[shardt]

This problem still persists in version 5.8.
We do deploy the engine in two separate applications at the same time with the same @Singleton @Startup EJB in a JBoss 7 via a cli-script.
There seems to be a high probability that the engine starts up at the exact same time.
As an effect the database table ACT_RE_PROCDEF contains duplicate entries of processes with the same id and version.
If both applications are deployed with a delay the problem does  not occur.

The engine is configured via createProcessEngineConfigurationFromResourceDefault.
activiti.cfg.xml contains:

   <bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager">
        <property name="transactionManagerName" value="java:jboss/TransactionManager" />
    </bean>
    <bean id="processEngineConfiguration" class="org.activiti.spring.SpringProcessEngineConfiguration">
        <property name="dataSourceJndiName" value="java:jboss/datasources/datasource.name" />
        <property name="transactionManager" ref="transactionManager" />
        <property name="transactionsExternallyManaged" value="true" />
        <property name="databaseSchemaUpdate" value="true" />
        <property name="mailServerHost" value="mail " />
        <property name="mailServerPort" value="25" />
        <property name="deploymentResources" value="classpath:/diagrams/*.bpmn20.xml" />
    </bean>

It uses the same resources in booth applications.
(This is only an interims implementation and not for production, but it produces the problem.)

database table ACT_RE_PROCDEF with duplicate entries:

ID_                              CATEGORY_   NAME_                    KEY_                     VERSION_  DEPLOYMENT_ID_
Prototype_flow_activiti:10:2008  http://…  prototype_flow_activiti  Prototype_flow_activiti  10        2001
Prototype_flow_activiti:10:2108  http://…  prototype_flow_activiti  Prototype_flow_activiti  10        2101


[trademak]

Hi,

In a clustered environment it's not a good idea to use the autodeploy feature on more than 1 Activiti instance.
Would it work for you to have the autodeploy feature only active on 1 instance?

Best regards,

[goekan-t]

Hi,
we are running Activiti 5.5 and had the same Problem in our production system. (Additional info: We are using the SpringAutoDeployment. So the bug http://jira.codehaus.org/browse/ACT-736 affects the deployment.)
I agree with Franklin: "Seems like occured when the process was deployed from two machines at nearly the same time." The problem occured when four servers where rebooted at the same time.
It ended up that none of the applications started sucessfully!

As written in http://forums.activiti.org/en/viewtopic.php?f=6&t=2207&p=9360 the solution can be a unique constraint because the engine acts like there is one.
ALTER TABLE `ACT_RE_PROCDEF` ADD UNIQUE INDEX `KEY_VERSION` (`KEY_` ASC, `VERSION_` ASC) ;By adding this only the instance that wants to insert the duplicate will fail to start.

Is it possible to add this to the next release?

Regards,
Tobi

[spanko]

Hi,

we are also hit by this problem using Activiti 5.9, and I was wondering if it is possible to delegate the version increment using a DB sequence. I saw that this code is executed to perform the version increment (taken from org.activiti.engine.impl.bpmn.deployer.BpmnDeployer):


        ProcessDefinitionEntity latestProcessDefinition = processDefinitionManager.findLatestProcessDefinitionByKey(processDefinition.getKey());
        if (latestProcessDefinition != null) {
          processDefinitionVersion = latestProcessDefinition.getVersion() + 1;
        } else {
          processDefinitionVersion = 1;
        }

If the increment of the version would simply done by a DB sequence, this would ensure that at least the version is incremented every time during a deployment, even if two instances are started almost simultaneously (which happens in our case). Of course the versions would no longer be consecutive (and not even start at "1"), but at least it would be ensured that they are increasing. Since DB sequences (at least in PostgresQL) are not rolled back even in failure cases and access to a sequence is atomic, there would be no collision.

WDYT?

Regards

Sven

[frederikherema1]

Sven,

Since not all DB's we support, have sequences, this approach isn't generic enough to implement in the engine. As Tijs said, it's not a good idea to use automatic resource-deployment on a cluster. But the solution Tobi suggested with a database-constraint on key and version should prevent any double-inserts.

https://jira.codehaus.org/browse/ACT-1280

[satheesh1]

HI

I have same error referred above: Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'processEngine': FactoryBean threw exception on object creation; nested exception is org.apache.ibatis.exceptions.TooManyResultsException: Expected one result (or null) to be returned by selectOne(), but found: 2

i found 9 process  to have duplicate records in ACT_RE_PROCDEF.
I updated the VERSION_ of the duplicate records to 0, since this is production version i was not allowed to delete the records.

I did select the max version and modified the process belongs to that version, is this correct approach?

i have totally 12 process defenitions but i see only 9 of the procdef KEY_ with max VERSION_ - what is happening to remaining process?

the app is deployed in 2 tomcat servers. one of the server is already running second one faces issues. After updating the duplicate record VERSION_ i tried to restart the tomcat servers and i am still getting the same error. Is it cached somewhere? i deleted the webapps and Catalina/localhost app folders before starting the server. still i get the same error, pls advise.

using Activiti 5.10



Thanks
Satheesh