Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-10819

Message Correlation throws an exception "Cannot add TRANSIENT" with localVariables

XMLWordPrintable

    • Icon: Bug Report Bug Report
    • Resolution: Fixed
    • Icon: L3 - Default L3 - Default
    • 7.12.0, 7.12.0-alpha5
    • None
    • engine
    • None

      Hi guys
      I have a process definition that starts with a Message Start Event. When I try to set a localVariable invoking the runtimeService.createMessageCorrelation an exception is thrown. Example;

      A simple flow like:

      Works fine when I set a global variable using setVariable but fails when I invoke the code with setVariableLocal:

      runtimeService?.createMessageCorrelation("START_EVENT")?.
                    processInstanceBusinessKey("XPTO-001")?.
                    setVariableLocal("local-var", "Some Message")?.
                    correlateWithResult()

      The exception is:

      org.camunda.bpm.engine.ProcessEngineException: ENGINE-03002 Cannot add TRANSIENT entity with id '4ae7a392-d552-11e9-810b-ea553ab1b917' and type 'class org.camunda.bpm.engine.impl.persistence.entity.HistoricVariableInstanceEntity' into cache. An entity with the same id and type is already in state 'TRANSIENT'
	at org.camunda.bpm.engine.impl.db.EnginePersistenceLogger.entityCacheDuplicateEntryException(EnginePersistenceLogger.java:98) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.db.entitymanager.cache.DbEntityCache.putInternal(DbEntityCache.java:210) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.db.entitymanager.cache.DbEntityCache.putTransient(DbEntityCache.java:154) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.db.entitymanager.DbEntityManager.insert(DbEntityManager.java:575) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.history.handler.DbHistoryEventHandler.insertHistoricVariableUpdateEntity(DbHistoryEventHandler.java:114) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.history.handler.DbHistoryEventHandler.handleEvent(DbHistoryEventHandler.java:45) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.history.handler.CompositeHistoryEventHandler.handleEvent(CompositeHistoryEventHandler.java:96) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.history.event.HistoryEventProcessor.processHistoryEvents(HistoryEventProcessor.java:75) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.persistence.entity.VariableInstanceHistoryListener.onCreate(VariableInstanceHistoryListener.java:39) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.fireHistoricVariableInstanceCreateEvents(ExecutionEntity.java:1297) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.pvm.runtime.ExecutionStartContext.executionStarted(ExecutionStartContext.java:49) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationActivityStart.eventNotificationsCompleted(PvmAtomicOperationActivityStart.java:36) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationActivityStart.eventNotificationsCompleted(PvmAtomicOperationActivityStart.java:28) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.core.operation.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:66) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:96) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:128) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:108) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:83) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:73) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:649) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:624) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.core.operation.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:62) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:96) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:128) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:108) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:83) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:73) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:649) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:624) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.core.operation.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:62) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:96) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:128) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:108) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:83) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:73) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:649) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:624) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.core.operation.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:62) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:96) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:128) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:108) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:83) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:640) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:614) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationActivityStartCreateScope.scopeCreated(PvmAtomicOperationActivityStartCreateScope.java:43) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationCreateScope.execute(PvmAtomicOperationCreateScope.java:54) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationCreateScope.execute(PvmAtomicOperationCreateScope.java:28) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:96) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:128) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:115) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext$1.call(CommandInvocationContext.java:99) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext$1.call(CommandInvocationContext.java:97) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.context.ProcessApplicationClassloaderInterceptor.call(ProcessApplicationClassloaderInterceptor.java:48) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.application.AbstractProcessApplication.execute(AbstractProcessApplication.java:121) [camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.application.AbstractProcessApplication.execute(AbstractProcessApplication.java:132) [camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.context.Context.executeWithinProcessApplication(Context.java:195) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:97) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:83) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:640) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:614) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.pvm.runtime.PvmExecutionImpl.start(PvmExecutionImpl.java:248) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.start(ExecutionEntity.java:449) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.cmd.AbstractCorrelateMessageCmd.instantiateProcess(AbstractCorrelateMessageCmd.java:83) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.cmd.AbstractCorrelateMessageCmd.createMessageCorrelationResult(AbstractCorrelateMessageCmd.java:113) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.cmd.CorrelateMessageCmd.execute(CorrelateMessageCmd.java:95) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.cmd.CorrelateMessageCmd.execute(CorrelateMessageCmd.java:42) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandExecutorImpl.execute(CommandExecutorImpl.java:28) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:107) ~[camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:46) [camunda-engine-spring-7.11.0.jar:7.11.0]
	at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:140) [spring-tx-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.camunda.bpm.engine.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:44) [camunda-engine-spring-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.ProcessApplicationContextInterceptor.execute(ProcessApplicationContextInterceptor.java:70) [camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:33) [camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.MessageCorrelationBuilderImpl.execute(MessageCorrelationBuilderImpl.java:313) [camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.impl.MessageCorrelationBuilderImpl.correlateWithResult(MessageCorrelationBuilderImpl.java:224) [camunda-engine-7.11.0.jar:7.11.0]
	at abner.report.bugs.camunda.FlowDeployListener.notify(FlowDeployListener.kt:20) [classes/:na]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_212]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_212]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_212]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_212]
	at org.springframework.context.event.ApplicationListenerMethodAdapter.doInvoke(ApplicationListenerMethodAdapter.java:261) [spring-context-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.context.event.ApplicationListenerMethodAdapter.processEvent(ApplicationListenerMethodAdapter.java:179) [spring-context-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.context.event.ApplicationListenerMethodAdapter.onApplicationEvent(ApplicationListenerMethodAdapter.java:142) [spring-context-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172) [spring-context-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165) [spring-context-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139) [spring-context-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:402) [spring-context-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:372) [spring-context-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.camunda.bpm.spring.boot.starter.SpringBootProcessApplication.onPostDeploy(SpringBootProcessApplication.java:112) [camunda-bpm-spring-boot-starter-3.3.4.jar:3.3.4]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_212]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_212]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_212]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_212]
	at org.camunda.bpm.container.impl.deployment.PostDeployInvocationStep.performOperationStep(PostDeployInvocationStep.java:68) [camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.container.impl.spi.DeploymentOperation.execute(DeploymentOperation.java:120) [camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.container.impl.jmx.MBeanServiceContainer.executeDeploymentOperation(MBeanServiceContainer.java:160) [camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.container.impl.spi.DeploymentOperation$DeploymentOperationBuilder.execute(DeploymentOperation.java:216) [camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.container.impl.RuntimeContainerDelegateImpl.deployProcessApplication(RuntimeContainerDelegateImpl.java:102) [camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.application.AbstractProcessApplication.deploy(AbstractProcessApplication.java:66) [camunda-engine-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.spring.application.SpringProcessApplication.start(SpringProcessApplication.java:110) [camunda-engine-spring-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.spring.application.SpringProcessApplication.afterPropertiesSet(SpringProcessApplication.java:119) [camunda-engine-spring-7.11.0.jar:7.11.0]
	at org.camunda.bpm.spring.boot.starter.SpringBootProcessApplication.afterPropertiesSet(SpringBootProcessApplication.java:101) [camunda-bpm-spring-boot-starter-3.3.4.jar:3.3.4]
	at org.camunda.bpm.engine.spring.application.SpringProcessApplication.onApplicationEvent(SpringProcessApplication.java:96) [camunda-engine-spring-7.11.0.jar:7.11.0]
	at org.camunda.bpm.engine.spring.application.SpringProcessApplication.onApplicationEvent(SpringProcessApplication.java:52) [camunda-engine-spring-7.11.0.jar:7.11.0]
	at org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172) [spring-context-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165) [spring-context-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139) [spring-context-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:402) [spring-context-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:359) [spring-context-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:896) [spring-context-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.finishRefresh(ServletWebServerApplicationContext.java:162) [spring-boot-2.1.8.RELEASE.jar:2.1.8.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:552) [spring-context-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:141) [spring-boot-2.1.8.RELEASE.jar:2.1.8.RELEASE]
	at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:744) [spring-boot-2.1.8.RELEASE.jar:2.1.8.RELEASE]
	at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:391) [spring-boot-2.1.8.RELEASE.jar:2.1.8.RELEASE]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:312) [spring-boot-2.1.8.RELEASE.jar:2.1.8.RELEASE]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1215) [spring-boot-2.1.8.RELEASE.jar:2.1.8.RELEASE]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1204) [spring-boot-2.1.8.RELEASE.jar:2.1.8.RELEASE]
	at abner.report.bugs.camunda.ApplicationKt.main(Application.kt:13) [classes/:na]

      You can replicate the error using the code here:

        This is the controller panel for Smart Panels app

          1. process_definition.png
            process_definition.png
            31 kB

            [CAM-10819] Message Correlation throws an exception "Cannot add TRANSIENT" with localVariables

            Nikola Koevski added a comment - - edited

            Hi abnerrolim,

            Thank you for the report. I have successfully reproduced the issue and will forward it for a decision on how to resolve it.

            Best,
            Nikola

            Nikola Koevski added a comment - - edited Hi abnerrolim , Thank you for the report. I have successfully reproduced the issue and will forward it for a decision on how to resolve it. Best, Nikola

            Nikola Koevski added a comment - - edited

            Root cause is that the Historic Variable Create Event for a transient variable is called twice:

            1. First time is through the AbstractCorrelateMessageCmd#instantiateProcess -> processInstance.setVariablesLocal call. This invokes AbstractVariableScope#invokeVariableLifecycleListenersCreate which eventually caches a CachedDbEntity in the dbCache.
            2. Second call happens during process execution, after the Start Event activity instance is created through the ExecutionEntity#fireHistoricVariableInstanceCreateEvents. Eventually, there is an attempt to cache the transient entity a second time. This leads to an exception being thrown here.

            Nikola Koevski added a comment - - edited Root cause is that the Historic Variable Create Event for a transient variable is called twice: First time is through the AbstractCorrelateMessageCmd#instantiateProcess -> processInstance.setVariablesLocal call. This invokes AbstractVariableScope#invokeVariableLifecycleListenersCreate which eventually caches a CachedDbEntity in the dbCache. Second call happens during process execution, after the Start Event activity instance is created through the ExecutionEntity#fireHistoricVariableInstanceCreateEvents . Eventually, there is an attempt to cache the transient entity a second time. This leads to an exception being thrown here .

            Thorben Lindhauer added a comment -

            Hello abnerrolim,

            Thanks for reporting this problem. As we currently have a busy schedule, we will not be able to prioritize a fix for this as of now. However, we are open for a contribution. Please let us know if you have any questions.

            Best regards,
            Thorben

            Thorben Lindhauer added a comment - Hello abnerrolim , Thanks for reporting this problem. As we currently have a busy schedule, we will not be able to prioritize a fix for this as of now. However, we are open for a contribution. Please let us know if you have any questions. Best regards, Thorben

            Abner Luis Santos Rolim added a comment -

            Hi @Thorben Lindhauer,

            I started to look at this bug and if I get this right the problem is that the AbstractCorrelateMessageCmd#instantiateProcess is calling processInstance.setVariablesLocal(builder.getPayloadProcessInstanceVariablesLocal()); before the processInstance starts:

            AbstractCorrelateMessageCmd.java
              protected ProcessInstance instantiateProcess(CommandContext commandContext, CorrelationHandlerResult correlationResult) {
   ....stuffs

    processInstance.setVariablesLocal(builder.getPayloadProcessInstanceVariablesLocal());
    processInstance.start(builder.getPayloadProcessInstanceVariables());

    return processInstance;
  }

            This set method will invoke the ExecutionEntity#getVariableInstanceLifecycleListeners where it does a check:

            ExecutionEntity.java
                if (isAutoFireHistoryEvents()) {
      listeners.add((VariableInstanceLifecycleListener) VariableInstanceHistoryListener.INSTANCE);
    }

            On the isAutoFireHistoryEvents we have a long comment:

            ExecutionEntity.java
              protected boolean isAutoFireHistoryEvents() {
    // as long as the process instance is starting (i.e. before activity instance
    // of the selected initial (start event) is created), the variable scope should
    // not automatic fire history events for variable updates.

    // firing the events is triggered by the processInstanceStart context after
    // the initial activity has been initialized. The effect is that the activity instance id of the
    // historic variable instances will be the activity instance id of the start event.

    // if a variable is updated while the process instance is starting then the
    // update history event is lost and the updated value is handled as initial value.

    ActivityImpl currentActivity = getActivity();

    return (startContext == null || !startContext.isDelayFireHistoricVariableEvents())
      && (currentActivity == null || isActivityNoStartEvent(currentActivity)
      || isStartEventInValidStateOrNotAsync(currentActivity));
  }

            the problem is that the startContext is null at this point and the isAutoFireHistoryEvents returns true and adds the VariableInstanceHistoryListener to be executed. It's this listener that fires Historic Variable Create Event followed by the processInstance.start fire.

            Long story short:

            I just inverted the calling sequence and this solves the issue because the startContext is no more null.

            AbstractCorrelateMessageCmd.java
              protected ProcessInstance instantiateProcess(CommandContext commandContext, CorrelationHandlerResult correlationResult) {
    ProcessDefinitionEntity processDefinitionEntity = correlationResult.getProcessDefinitionEntity();

    ActivityImpl messageStartEvent = processDefinitionEntity.findActivity(correlationResult.getStartEventActivityId());
    ExecutionEntity processInstance = processDefinitionEntity.createProcessInstance(builder.getBusinessKey(), messageStartEvent);

    if (variablesEnabled) {
      variablesListener = new ExecutionVariableSnapshotObserver(processInstance, false, deserializeVariableValues);
    }
   //upside down
    processInstance.start(builder.getPayloadProcessInstanceVariables());
    processInstance.setVariablesLocal(builder.getPayloadProcessInstanceVariablesLocal());

    return processInstance;
  }

            Don't know if is the ideal solution. But hope this can help in some form. And you guys want, I can do a merge request, just point to me the guidelines.

            Regards,
            Abner Rolim

            Abner Luis Santos Rolim added a comment - Hi @Thorben Lindhauer, I started to look at this bug and if I get this right the problem is that the AbstractCorrelateMessageCmd#instantiateProcess is calling processInstance.setVariablesLocal(builder.getPayloadProcessInstanceVariablesLocal()); before the processInstance starts: AbstractCorrelateMessageCmd.java protected ProcessInstance instantiateProcess(CommandContext commandContext, CorrelationHandlerResult correlationResult) { ....stuffs processInstance.setVariablesLocal(builder.getPayloadProcessInstanceVariablesLocal()); processInstance.start(builder.getPayloadProcessInstanceVariables()); return processInstance; } This set method will invoke the ExecutionEntity#getVariableInstanceLifecycleListeners where it does a check: ExecutionEntity.java if (isAutoFireHistoryEvents()) { listeners.add((VariableInstanceLifecycleListener) VariableInstanceHistoryListener.INSTANCE); } On the isAutoFireHistoryEvents we have a long comment: ExecutionEntity.java protected boolean isAutoFireHistoryEvents() { // as long as the process instance is starting (i.e. before activity instance // of the selected initial (start event) is created), the variable scope should // not automatic fire history events for variable updates. // firing the events is triggered by the processInstanceStart context after // the initial activity has been initialized. The effect is that the activity instance id of the // historic variable instances will be the activity instance id of the start event. // if a variable is updated while the process instance is starting then the // update history event is lost and the updated value is handled as initial value. ActivityImpl currentActivity = getActivity(); return (startContext == null || !startContext.isDelayFireHistoricVariableEvents()) && (currentActivity == null || isActivityNoStartEvent(currentActivity) || isStartEventInValidStateOrNotAsync(currentActivity)); } the problem is that the startContext is null at this point and the isAutoFireHistoryEvents returns true and adds the VariableInstanceHistoryListener to be executed. It's this listener that fires Historic Variable Create Event followed by the processInstance.start fire. Long story short: I just inverted the calling sequence and this solves the issue because the startContext is no more null. AbstractCorrelateMessageCmd.java protected ProcessInstance instantiateProcess(CommandContext commandContext, CorrelationHandlerResult correlationResult) { ProcessDefinitionEntity processDefinitionEntity = correlationResult.getProcessDefinitionEntity(); ActivityImpl messageStartEvent = processDefinitionEntity.findActivity(correlationResult.getStartEventActivityId()); ExecutionEntity processInstance = processDefinitionEntity.createProcessInstance(builder.getBusinessKey(), messageStartEvent); if (variablesEnabled) { variablesListener = new ExecutionVariableSnapshotObserver(processInstance, false , deserializeVariableValues); } //upside down processInstance.start(builder.getPayloadProcessInstanceVariables()); processInstance.setVariablesLocal(builder.getPayloadProcessInstanceVariablesLocal()); return processInstance; } Don't know if is the ideal solution. But hope this can help in some form. And you guys want, I can do a merge request, just point to me the guidelines. Regards, Abner Rolim

            Thorben Lindhauer added a comment - - edited

            Hi abnerrolim,

            Thanks for looking into this . Your analysis makes complete sense.

            I think changing the order of the calls is not the correct fix for the following reason: ExecutionEntity#start executes the process until wait states are reached. If we only set the local variables after that, the variables will not be available in the first steps of the process. For example, consider there is an end execution listener on the start event. It would not be able to access the local variables.

            As an alternative, how about we merge the variable maps and then supply the merged map to the ExecutionEntity#start call?

            Cheers,
            Thorben

            Thorben Lindhauer added a comment - - edited Hi abnerrolim , Thanks for looking into this . Your analysis makes complete sense. I think changing the order of the calls is not the correct fix for the following reason: ExecutionEntity#start executes the process until wait states are reached. If we only set the local variables after that, the variables will not be available in the first steps of the process. For example, consider there is an end execution listener on the start event. It would not be able to access the local variables. As an alternative, how about we merge the variable maps and then supply the merged map to the ExecutionEntity#start call? Cheers, Thorben

            Abner Luis Santos Rolim added a comment -

            Hi Thorben,
            Understood, make sense.

            I observed the behavior of runtimeService.createProcessInstanceByKey("key").businessKey("X").setVariableLocal("var", "Some Message").execute() and something similar happens, all {ProcessInstanceModificationInstantiationBuilder#setVariableLocal}} will be put into the processVariables at this point. I thought to put the same responsability inside MessageCorrelationBuilder but the check if goes to local or process map is made lookin inside a List<AbstractProcessInstanceModificationCommand> operations and it doesn't have this operations concept.

            So I was thinking of just add all local variables inside the process variables map in the AbstractCorrelateMessageCmd#instantiateProcess method. As far I as know it will be only executed if the correlate msg is a start message.

            Sorry for the late answer, but I'm also running with other initiatives

            If you are ok with that, I go ahead.
            Cheers

            Abner Luis Santos Rolim added a comment - Hi Thorben, Understood, make sense. I observed the behavior of runtimeService.createProcessInstanceByKey("key").businessKey("X").setVariableLocal("var", "Some Message").execute() and something similar happens, all {ProcessInstanceModificationInstantiationBuilder#setVariableLocal}} will be put into the processVariables at this point. I thought to put the same responsability inside MessageCorrelationBuilder but the check if goes to local or process map is made lookin inside a List<AbstractProcessInstanceModificationCommand> operations and it doesn't have this operations concept. So I was thinking of just add all local variables inside the process variables map in the AbstractCorrelateMessageCmd#instantiateProcess method. As far I as know it will be only executed if the correlate msg is a start message. Sorry for the late answer, but I'm also running with other initiatives If you are ok with that, I go ahead. Cheers

            Thorben Lindhauer added a comment -

            Hi Abner,

            Sounds good to me. I think its easiest to discuss the details directly at the code, so feel free to submit a PR

            Cheers,
            Thorben

            Thorben Lindhauer added a comment - Hi Abner, Sounds good to me. I think its easiest to discuss the details directly at the code, so feel free to submit a PR Cheers, Thorben

            Abner Luis Santos Rolim added a comment -

            Hi Thorben,

            Sure, I did a pull request yesterday. #521

            Cheers, have a nice day.
            Abner

            Abner Luis Santos Rolim added a comment - Hi Thorben, Sure, I did a pull request yesterday. #521 Cheers, have a nice day. Abner

            Thorben Lindhauer added a comment -

            Resolved via https://github.com/camunda/camunda-bpm-platform/pull/521

            Thorben Lindhauer added a comment - Resolved via https://github.com/camunda/camunda-bpm-platform/pull/521

            Thorben Lindhauer added a comment -

            Merged.

            Thorben Lindhauer added a comment - Merged.

              thorben.lindhauer Thorben Lindhauer
              abnerrolim Abner Luis Santos Rolim
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: