Welcome Guest! Log in
Stambia versions 2.x, 3.x, S17, S18, S19 and S20 are reaching End of Support January, 15th, 2024. Please consider upgrading to the supported Semarchy xDI versions. See Global Policy Support and the Semarchy Documentation.

The Stambia User Community is moving to Semarchy! All the applicable resources have already been moved or are currently being moved to their new location. Read more…

Runtime startup and execution time is slow on MAC OS


    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.



    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:   localhost yourMacHostname
    ::1         localhost yourMacHostname


    You can refer to the following articles for further information:




    Runtime command - Unparseable date exception raised


      An unparseable date exception is raised when the used java version in designer and runtime is not the same.

      For instance when user in Java 8 tries to access a runtime runtime in Java 11 and vice versa:

      Unparseable date 


      Add this java option of JRE 11, in initvariable.bat file, when communicating with JRE 8.





      Please refer to this Openjdk article for further information: https://openjdk.java.net/jeps/252

      Scheduler triggers twice the same job because of two conflicting schedules


        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.


        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
          org.quartz.jobStore.misfireThreshold = 1

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



        Runtime as a Windows Service not starting


          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.


          Please refer to this Microsoft KB entry:


          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


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


            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.

            Knowledge Base

            Suggest a new Article!