cancel
Showing results for 
Search instead for 
Did you mean: 

5.10 HistoricTaskInstanceQuery extension.

gromar
Champ in-the-making
Champ in-the-making
Hello.

I would like to extend HistoricTaskInstanceQuery with possibility to select tasks finished after due time.
How can I manage it on the 5.10 tag? (I think new features could be added only to the 5.12-SNAPSHOT).

The reason for 5.10 is that 5.11 has issues with database. When it is not possible to extend 5.10, I have to upgrade to 5.12-snapshot. In that case I will write jUnit test which will simulate error and will ask another question.
7 REPLIES 7

frederikherema1
Star Contributor
Star Contributor
You could just checkout the 5.10 tag and modify it locally (or fork on github), alter the source-code and build the engine-jar yourself. You can suggest the change to us, by applying the change to the current 5.12 master and creating a pull-request (or attaching a patch to a JIRA-issue).

gromar
Champ in-the-making
Champ in-the-making
In that case it would be better to upgrade process-monitor project to the latest activiti version.

I tried to upgrade from Activiti 5.10 -> 5.11. I have created new test which is failing with 5.11 but was totally OK with 5.10.

Could you please show me what I am doing wrong here?

Description:
TwoEnginesTest.java
Test puts process engine into defined state (generateLiveDB()),
deploys simple process:
[img]https://raw.github.com/gro-mar/activiti-crystalball/Activiti-5.11/simulator/src/test/process/org/act...[/img]

and runs the test (starts deployed process).



@Test
public void test() {
  // prepare params
  Map<String, Object> params = new Hashtable<String, Object>();

  params.put( "tempDir", System.getProperty("tempDir", "target") );
     params.put( "runningDatabaseFile", LIVE_DB+".h2.db");


     // start process
  runtimeService.startProcessInstanceByKey(
    MONITOR_PROCESS_KEY, "GENERATOR-KEY-1", params).getId();
}

In this one node process groovy script is called (starts new "simulation" process engine and runs simulation on the top of it):

import org.apache.commons.io.*;
       import static org.junit.Assert.*;
import java.util.List;
import org.activiti.engine.IdentityService;
import org.activiti.engine.identity.User;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.processmonitor.simulator.*;

// create copy of the running process engine database and set system property to this file

FileUtils.copyFile( FileUtils.getFile(runningDatabaseFile), FileUtils.getFile( tempDir+"/TwoEngines-simulationRunDB"+Thread.currentThread().getId()+".h2.db"))
System.setProperty("_SIM_DB_PATH", tempDir+"/TwoEngines-simulationRunDB"+Thread.currentThread().getId())

  ClassPathXmlApplicationContext appContext = new ClassPathXmlApplicationContext("/org/processmonitor/simulator/SimEngine-h2-context.xml")
  IdentityService identityService = appContext.getBean("identityService")
  IdentityService simIdentityService = appContext.getBean("simIdentityService")
  List<User> simUsers = simIdentityService.createUserQuery().list();
  List<User> users = identityService.createUserQuery().list();
  assertTrue("Copied identity service is not the same as source  identity service", simUsers.size() == users.size());

  SimulationRun simRun = appContext.getBean(SimulationRun.class)
  resultEventList = simRun.execute(new Date(), null)

  assertTrue("Simulation result event list is empty", resultEventList.size() > 0);

  appContext.close()

The problem is that

assertTrue("Simulation result event list is empty", resultEventList.size() > 0);

is failing because of various reasons:
Identity service is not the same as "live" process engine.
TaskService is not the same.
etc…


The same test without process deploy and start is not failing (see TwoEnginesWithoutProcessTest.java)

Both tests are passing with activiti-5.10 master branch

Could you help me please?'>.

Could you help me please?

frederikherema1
Star Contributor
Star Contributor
Not really sure why you're using a process to spawn off a new process-engine to run the simulation in… Is the issue that is presenting occurring due to the simulation NOT working well on the 5.11? Or is the original process-spawning 5.11 engine causing issues?

gromar
Champ in-the-making
Champ in-the-making
Simulation is working well on 5.11. in the case when it is not called from process simulation node (see TwoEnginesWithoutProcessTest.java )

From my point of view the 5.11 engine is causing this issues - it is not possible to execute another process engine instance from the running process instance.

Both tests are passing with activiti-5.10 master branch.

frederikherema1
Star Contributor
Star Contributor
This has to do with the way service-calls are handled from within a running process. In order to have the API-calls (rg, from a service-task) use the same transaction, some work has been done in the 5.11 release… So I presume the command-contexts of engine A is taken over by engine B. At least, that's what I suspect is the issue.

It's off course a highly unusual use case, to spawn a second engine from the first one. I get why you're using a separate engine for simulation (to not influence the production-engine), but not sure why the simulation should run in an engine, booted within another engine…

gromar
Champ in-the-making
Champ in-the-making
The reason: Only for presentation purposes. It is easier to communicate with business people process diagrams as code.

Question: How to fix this issue?

jbarrez
Star Contributor
Star Contributor
Ok, so the problem here is exactly how Fred describes it. By fixing transactions in 5.11, and introducing command context reuse, we've broken your use case (albeit it is a very, very exceptional use case 😉 )
The problem here is that the command context stack is cached thread local for further service invocations. You are using different services, but the thread local cache is the same for all these instances.

Luckily you can disable this behavior, by calling

  public void setContextReusePossible(boolean isContextReusePossible) {
    this.isContextReusePossible = isContextReusePossible;
  }


on CommandContextInterceptor.

You could override


public class StandaloneProcessEngineConfiguration extends ProcessEngineConfigurationImpl {

  protected Collection< ? extends CommandInterceptor> getDefaultCommandInterceptorsTxRequired() {
    return createDefaultCommandInterceptors(true);
  }

and pass true there.