Welcome Guest! Log in

Runtime as a Windows Service not starting

    Symptom

    The Runtime, configured as a Windows Service, cannot start. The following error (or similar) can be found in Windows' event logs:

    A timeout was reached (30000 milliseconds) while waiting for the Stambia Runtime service to connect.

    Solution

    Please refer to this Microsoft KB entry:

    https://support.microsoft.com/en-us/help/922918/a-service-does-not-start-and-events-7000-and-7011-are-logged-in-window

    Some of our users had this issue and solved it with the solution provided by Microsoft (editing the Registry to set the ServicesPipeTimeout parameter to 60000).

    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.

             

            Knowledge Base

            Suggest a new Article!