Scheduler triggers twice the same job because of two conflicting schedules

Symptom

The same delivery has two schedules for different periods. Sometimes these periods have conflicting occurences. When this happens, the delivery is executed twice.

For example:

• Schedule 1: execute delivery1 every tuesday at 10am
• Schedule 2: execute delivery1 every 5th month day, at 10am

=> When the 5th day of a month is a tuesday, delivery1 will execute twice.

Solution

This is normal, considering the default configuration of the Scheduler.

When a scheduled job tries to start, it will wait for the other occurences to finish. If the "misfireThreshold" delay is reached then the awaiting job is cancelled. By default this delay is 60 seconds.

You can change this behavior in file stambiaRuntime/properties/engineScheduler.properties.

• Create this file if it does not exist (copying engineScheduler.properties.sample)
• Change this line:
  org.quartz.jobStore.misfireThreshold = 60000
  to
  org.quartz.jobStore.misfireThreshold = 1

=> the awaiting job is immediately cancelled (after 1 millisecond...).

Runtime will not start with error "java.lang.UnsupportedClassVersionError"

Symptom

When trying to start the Runtime, it crashes instantly. The error is as follows:

Exception in thread "main" java.lang.UnsupportedClassVersionError: com/indy/engine/EngineStartI (Unsupported major.minor version 50.0)
        at java.lang.ClassLoader.defineClass0(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:537)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:13)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)

Note: On Windows systems, the command window is immediately closed. Type "cmd" inside a command window, and then type "startengine.bat" to see the error message.

Solution

Define the STAMBIA_JAVA_HOME environment variable, and set its value to the absolute path of a valid Java installation (JRE or JDK version 6, 7, or 8).

Runtime does not start - no visible error

Symptom

When starting the Runtime, it stops immediately or a few seconds later.

When launched as a Windows or Linux service, the service stops after a few seconds.

When launched manually on Windows (from the Designer or double-clicking startengine.bat), the Command window does not appear or disappears instantly.

When launched manually on Linux or Mac OS, the process does not stay up.

In the end, the Runtime's system process stopped and does not appear in the Task manager (Windows), Activity Monitor (Mac OS) or in the process list (ps -ef | grep engine).

Solution

There can be multiple reasons. You need to consult the Runtime's logs and standard output.

Try starting the Runtime from the command line and redirect output to a log file.

On Windows:

D:\stambiaRuntime>startengine.bat > start.log 2>&1

On Linux / Mac OS (bash):

stambia@devsrv01:~/support/supportRuntime/stambiaRuntime$ ./startengine.sh &> start.log

Then consult the start.log files.

Feel free to share this log file with the Support Team if you need advice.

The H2 log database's file won't reduce after a session purge

Symptom

After purging sessions from the Runtime's H2 log database, the "stambiaRuntime\sessions\internalDb\sessionLogs.h2.db" file does not decrease in size.

Restarting the Runtime has no (or very small) effect on the file's size.

Solution

Note: this is not a limitation, this is due to the H2 database's COMPACT mechanism.

Note2: We recommend to use a more robust RDBMS if your Runtime has to handle a big number of session. See the Designer's Help to know how to configure the Runtime with an external log database.

When deleting data from the H2 database, the file is not reorganized in real time: this requires a database shutdown. When shutting down, H2 "compacts" the file in order to reduce the file size. But this operation is limited to 200 milliseconds duration (default H2 behaviour).

The solution is to stop the Runtime, and start the H2 Database independently to execute a SHUTDOWN COMPACT command. Here is how to do:

• Stop all the Runtimes which use this database
• Open a command line and change directory (cd) to the Runtime's directory.
• Execute this command to start the H2 database server:

D:\apps\stambia\stambiaDesigner_S17.2.10_20141007_120415\stambiaRuntime>java -cp lib\jdbc\h2.jar org.h2.tools.Server -webAllowOthers
Web server running on http://192.168.75.14:8082 (others can connect)
Please open a browser and go to http://192.168.75.14:8082
TCP server running on tcp://192.168.75.14:9092 (only local connections)
PG server running on pg://192.168.75.14:5435 (only local connections)

• Open the H2 Web server's URL in a web browser
• Set the connection URL to this: jdbc:h2:<pathToYourRuntimeDirectory>/sessions/internalDb/sessionLogs
• Click "Connect", a SQL window should be displayed in the web browser
• Execute the SQL command: shutdown compact
• The sessionLogs.h2.db file's size should be reduced now
• Close the H2 Server and restart the Runtimes.