Welcome Guest! Log in

Runtime startup and execution time is slow on MAC OS

    Symptom

    You installed a Runtime on MAC OS, and you notice that Runtime's startup is very slow, as well as executing sessions.

    For instance, instead of a few seconds, it takes more than one minute to startup the Runtime, and when executing sessions, it is very slow also.

     

    Solution

    This may come from an issue on MAC OS where the retrieval of local address from Java is slow which therefore makes every communications with the Runtime when using 'localhost' hostname slow.

    To resolve this issue, you can try to add your MAC OS hostname inside the system host file, which in most cases resolve this slow issue if it comes from the resolution of local hostname.

     

    Open the /etc/hosts file and update it like this:

    127.0.0.1   localhost yourMacHostname
    ::1         localhost yourMacHostname

     

    You can refer to the following articles for further information:

    https://stackoverflow.com/questions/33289695/inetaddress-getlocalhost-slow-to-run-30-seconds/33289897#33289897

     

     

    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).

      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.

        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).

            Knowledge Base

            Suggest a new Article!