cancel
Showing results for 
Search instead for 
Did you mean: 

Error while signaling an activity (receive task)

luka
Champ in-the-making
Champ in-the-making
Hi,

We are facing an intermittent issue when attempting to signal an existing process instance receive task. The approach we have taken is to signal via the API as defined in http://activiti.org/userguide/index.html#N12ABE. However, on occasion we are getting an ActivitiException indicating the target execution does not exist.

To try and better describe the problem, below is a summary of our execution flow:
    1. An Activiti process instance is started that will generate a JMS message and post it to a queue hosted on the same application server.
    2. After successfully publishing the JMS message, the process flow transitions into a receive activity, where it will wait to be signalled.
    3. An external application will consume the published JMS message, do some processing and publish a response JMS message.
    4. A Spring integration component will consume the JMS response message and attempt to signal the waiting receive task via
    runtimeService.signal(correlation, input);
    where the correlation comes from the JMS message and was originally published by the process via
    execution.getId()
The above execution flow results in one of two outcomes:
    a. Activiti process is successfully signalled and process flow continues without any problems.
    b. The Spring integration component fails when trying to signal the process with the following exception.
    2012-11-19 23:00:28,169 [org.springframework.jms.listener.DefaultMessageListenerContainer#1-1][…][9e2ad17a-1077-456d-a134-9
    efdfa046e4f] ERROR - Executing BPMN Process
    org.activiti.engine.ActivitiException: execution 105918 doesn't exist
            at org.activiti.engine.impl.cmd.SignalCmd.execute(SignalCmd.java:53)
            at org.activiti.engine.impl.interceptor.CommandExecutorImpl.execute(CommandExecutorImpl.java:24)
            at org.activiti.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:42)
            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.RuntimeServiceImpl.signal(RuntimeServiceImpl.java:142)
Looking into the database I can see the following:
    1. ACT_HI_ACTINST table has persisted all activity up to the receive task. The record has a START_TIME_, but the END_TIME_ is empty.
    2. ACT_RU_EXECUTION table has a record for the target execution. i.e.
    select *
    from act_ru_execution
    where proc_inst_id_ = 105918;
    returns a single record. I am not sure of the meaning of all the columns, so I have included some of these below:
    IS_ACTIVE_ = 1
    IS_CONCURRENT_ = 0
    IS_SCOPE_ = 1
    IS_EVENT_SCOPE_ = 0
    SUSPENSION_STATE_ = 1
    CACHED_ENT_STATE_ = 7
I remember reading a post on this forum in the past that suggested the runtimeService would need to have the process instance persisted to the database before it can be signalled. Some debugging through the Activiti code seemed to suggest the same. Given the intermittent nature of our problem and the fact that it seems to occur at times when the external processing is very quick (see step 3. above), it would seem that this could the root cause of our problem.

Can someone please confirm this understanding and if correct are there any alternative ways of signalling a process instance?

Thank you,
Luka
4 REPLIES 4

frederikherema1
Star Contributor
Star Contributor
As long as the process is still "flowing", the process is not persisted up to that state and the process cannot be signaled. I'm afraid there are no alternatives for this, other than queuing/retrying the signal() API-calls after "execution nog found" exception occurs.

fitzcaraldo
Champ in-the-making
Champ in-the-making
…so can anyone suggest a workaround for this problem?
Is there a way to ensure the instance is persisted?
I am about to implement this very pattern and this concerns me.

luka
Champ in-the-making
Champ in-the-making
This topic has also been discussed in a separate thread that offers a solution. In short, it has to do with how you control your transactional boundaries, but for more information please see http://forums.activiti.org/en/viewtopic.php?f=6&t=5859

seyyedjamal
Champ in-the-making
Champ in-the-making
I think setting attribute activiti:async=true will solve the problem.