Execution Engine Stopped
Problem
Jobs cannot be submitted to Semarchy xDM because the Execution Engine has stopped.
The PDE log shows errors like this:
Background
This is most often caused when a Semarchy instance has multiple data locations, and all of the data locations are set to purge their old data simultaneously. If a few connections are used by users on the systems and a few are used by integration jobs, then the scheduled purges can find that there are no available connections to connects and delete old data. The default connection pool size is just 8 connections.
Solution
Go into the Workbench and review the purge schedule.
In this example, the purge schedule was created when the system was upgraded to xDM 4.3. By default it is scheduled to run at exactly midnight on Sunday (based on the timezone of the application server). In this screenshot the schedule has been updated to run at 10 minutes past midnight so that it does not run simultaneously with the purges scheduled for other data locations.
If your purge schedules are all the same, then change them. Use something along these lines to run at 10 minute intervals:
0 0 0 ? * SUN
0 10 0 ? * SUN
0 20 0 ? * SUN
0 30 0 ? * SUN
Alternate Solution
Update semarchy.xml to allow more active connections. You may find that staggering the purge schedule fully solves your problem. If so, then there is no need to update semarchy.xml. But if you find that you are still exhausting your supply of available connections, then you should increase the maxActive connections.
The default connection sample for a data location looks like this:
<Resource name="jdbc/SEMARCHY_CUSTOMER_B2C_MDM" auth="Container" factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" type="javax.sql.DataSource" driverClassName="org.postgresql.Driver" url="jdbc:postgresql://localhost:5432/postgres" username="semarchy_customer_b2c_mdm" password="semarchy_customer_b2c_mdm" maxActive="8" maxIdle="8" minIdle="0" maxWait="15000" initialSize="1" defaultAutoCommit="false" rollbackOnReturn="true" validationQuery="select 1" testOnBorrow="true" timeBetweenEvictionRunsMillis="45000" validationInterval="60000" />
If you have arrived at this article, you have probably encountered "pool empty" problems. In that case, increase maxActive from "8" to "32" as a good starting point.
The choices here are not one-size-fits-all. You'll need analysis of your expected usage along with experimentation to determine the best parameters for your needs.
Related articles