Sessions blocked in prepared state and not executing

Symptom

You are executing deliveries on a Runtime started on a Windows machine and nothing gets executed.

The sessions appear as prepared but stay in this state.

sessionsPrepared

Solution

The Windows cmd prompt has an option called 'QuickEdit Mode'. It can be enabled or disabled in the Properties of the cmd window.

When this is activated, the cmd will be paused as soon as the focus is done on it.

So if you click in the Runtime console, Windows will block it until the focus is released.

editing console

For example, we are here editing the console to copy something from the logs.

As a consequence, the console will be blocked by Windows until we use the 'ESC' key to stop focusing on it.

-> This is why the sessions stay in the prepared state.

-> If you unleash the console, all the prepared sessions will be executed.

Add new comment

Error unmarshaling return header: Read timed out when executing a Process/Mapping

Symptom

The following is error is thrown in the Designer's Console, after executing a Process or a Mapping from the Designer:

Exception : java.rmi.UnmarshalException: Error unmarshaling return header;
nested exception is: java.net.SocketTimeoutException: Read timed out

The Process or Mapping is however executed, despite this error.

Most of the time it appears when executing a big Process (with a lot of sub-processes for example).

Solution

This happens on environments where the connection between the Designer and Runtime is slow, causing this error.

There is an option in the Designer allowing to increase the timeout for the communications with the Runtime.

You can find it under Window > Preferences > Stambia > Runtime > Runtime Timeout (milliseconds)

Preferences

You can increase this value until the error disappear.

Note:

Set it to '0' for an infinite timeout.

We advise to use this only for testing purposes as it is better to find the right timeout corresponding to your environment.

Add new comment

Error "URI has an authority component" when processing files

Symptom

When executing a process which manipulates files on Windows, or when performing an action which generates files (Build documentation for example), the following error occurs:

java.lang.IllegalArgumentException: URI has an authority component

The files to be manipulated or created are located on a network location such as \\some-server\some-directory

Solution

This error is raised by Java when trying to work on an UNC location (\\server\directory).

The solution is to work on a local directory, and/or try to work on a network drive (G:, H:...).

Add new comment

Error "java.net.SocketException: Connection reset" when executing an FTP action

Symptom

When executing a process which contains an FTP action, an error is raised by the FTP action, similar to this one:

java.net.SocketException: Connection reset
                at java.net.SocketInputStream.read(SocketInputStream.java:168)
                at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:452)
                at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:494)
                at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:222)
                at java.io.InputStreamReader.read(InputStreamReader.java:177)
                at java.io.BufferedReader.fill(BufferedReader.java:136)
                at java.io.BufferedReader.readLine(BufferedReader.java:299)
                at java.io.BufferedReader.readLine(BufferedReader.java:362)
                at org.apache.commons.net.ftp.FTPFileEntryParserImpl.readNextEntry(FTPFileEntryParserImpl.java:53)
                at org.apache.commons.net.ftp.FTPListParseEngine.readStream(FTPListParseEngine.java:157)
                at org.apache.commons.net.ftp.FTPListParseEngine.readServerList(FTPListParseEngine.java:100)
                at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2303)
                at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2269)
                at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2046)
                at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2093)
                at com.indy.engine.actionCodes.FtpGetActionCodeI.executeSimpleCode(SourceFile:390)
                at com.indy.engine.action.common.ActionCodeTypeI.executeCode(SourceFile:1646)
                at com.indy.engine.action.common.ActionCodeTypeI.run(SourceFile:1805)
                at java.lang.Thread.run(Thread.java:738)

The FTP server is up and running.

Solution

This can happen when the FTP server is busy and takes some time to respond, resulting in a timeout. This may occur when establishing the FTP connection (connection timeout), or when trying to get/send files (data timeout).

The solution is to increase the "Connection Timeout" and "Data Timeout" on the FTP action. They are expressed in milliseconds. For example 10000 means 10 seconds.

Add new comment