• Font Size
  • S
  • M
  • L

Search via FAQ No.

  • No : 24303
  • Open Date : 2016/06/13 14:17
  • 更新日時 : 2020/10/20 13:30
  • Print

[DataSpider Servista] The status at which the Script is ending is not the same when it was executed

The status at which the Script is ending is not the same when it was executed. Why is it turning to this status? How to check this?
Category : 


*Contents linked from this page might be in Japanese.

■Problem Condition

If there is no response after sending a request to the connection destination via script, then DataSpider Sevista will be on standby which would then cause this issue.

■Possible Cause

In the past we have confirmed the issue in the following conditions

  • When process is running on the connection destination for a extended period of time and has not completed.
  • When response to a request was not able to receive due to temporarily network failure.
  • When connecting from a terminal with incorrect RMI connection settings.


Please restart DataSpiderServer in order to stop running scripts.


Isolate the issue by checking the following "■Verification Point" to determine the cause. If the issue lies on the connection destination or the environment, please proceed accordingly to the cause.

If the problem cannot be determined please refer to "■Information Necessary for Investigation" with the information based on your "■Verification Point" and contact the support center.

 ■Verification Point

  1. Determining Problem Location

Verify the problem component (icon) from execution log and server log.

  • If you cannot determine from execution log

Prior to 3.0 SP2 version, an execution log was produced after a certain amount (*kb) has been buffered thus there are cases when it is not possible to determine the script process that stopped.
 In this case please add log output process before and after the potentially suspicious location; and determine at what point the process halted.
  *Please refer to "Reference Information" url for more details on log output process.
  *From version 3.1, addition of log out process is unnecessary because an output log is automatically produced per process of each icon.

  1.  Determining Connection Destination

Determine the connection destination from the global resource used by the component in section 1.

  1. Status Confirmation of Connection Destination and Network

Regarding the connection destination determined in section 2., check destination database, application, file system and network process status of the connection destination; and determine whether the process was stopped (unresponsive status to requests) at the time of problem.

As for database, aside from logs may be able to retrieve detailed logs from the driver you use upon connection. Anything found in the past case is  listed at the "Reference Information."

If the component is difficult to determine, then please verify the issue condition from "4." and/or "5."
If the halt cause is still unresolved even after determining the component (getting response from connection destination, etc.) please refer to "■Information Necessary for Investigation" and contact our support center.

  1. Verify Connection Settings

Please verify the connection settings on DataSpiderServer and DataSpider Studio.

In the past, there was a case when the debug execution was carried out on a terminal that had an invalid RMI connection settings (java.rmi.server.hostname)then process that obtained other script execution process and script process went on standby.

  1. Comparing Normal State and Problem State

Please verify the difference between the time when the problem arise and when it doesn't.

For example if the problem occurs only when it is connecting to a particular connection destination then it is highly probable that the problem may lie on the connection destination.
  If the problem occurs only when multiple processes are running then it is highly probably that running too many processes could be the cause.

■Information Needed for Investigation

Please reply back to Appresso Support Center with attaching the following logs of time of error occurrence.

  1. Log file from the time of error occurrence
  • $DATASPIDER_HOME/server/logs/server.log
  • $DATASPIDER_HOME/server/logs/server.log.n (n:integer)
  • $DATASPIDER_HOME/server/logs/server.error.log
  • $DATASPIDER_HOME/server/logs/${execution date}/exec.log
  • $DATASPIDER_HOME/server/logs/${execution date}/execution/${execution ID}.xml
  1. Thread Dump

By exporting the list of threads (thread dump) in execution, you will be able to determine the process running at the time of the error.

You can obtain thread dump relatively at ease by using "jstack" tool.
*For more details please refer to the url of "Reference Information"

Thread dump required for DataSpider Servista investigation can be obtained by the following command.

jstack -l PID > output file

For the process starting services, the above command will produce an error due to restriction on the process from the OS side.
In this situation you can use "PsExec" tool to avoid the problem.
*For more details please refer to the url of "Reference Information."

 Upon using "PsExec," a thread dump can be obtained with the following command.

 psexec -s jstack -l [PID] > [output file name]

Points to be Noted
 "jstack" and "PsExec" are both third party tools.
 Therefore, we would have to ask you to contact the developer for more information regarding its usage.

Reference Information

  • Log Output


  • Obtaining Trace from Driver
    • Oracle

  * Upon adding arguments to Java system/property, please designate lax.nl.java.option.additional of $DATASPIDER_HOME/server/bin/DataSpiderServer.lax


*For more details regarding setting description, please contact the database developer.
*For inquiry regarding database trace file that is not mentioned above, please contact the database developer for further assistance.

  • jstack


  • PsExec