If Studio is unable to connect to the TDV server, Studio will typically display an error message of the type below:

------------------------------------------------------------------------------------------------------------------
Failed to connect to http://internal.redwood.com:9400/cdms/webapi; nested exception is: 
    java.rmi.RemoteException: HTTP transport error: java.net.ConnectException: Connection refused: connect; nested exception is: 
    HTTP transport error: java.net.ConnectException: Connection refused: connect [Log ID: 464d7f6a-ff09-4899-99e6-540629700eaa] 
--------------------------------------------------------------------------------------------------------------

In this case, follow the steps below.

 (1) Are you able to connect using wget or curl on the Linux machine?

Example
              wget  http://internal.redwood.com:9400
              curl http://internal.redwood.com:9400

The screenshot below shows the output of wget making a successful connection. Notice that the screenshot contains "200 OK". A 200 OK means that wget opened a connection to TDV, and got back a response.
  
        

If the answer to the above question is YES:

This means that a local client (i.e.  running on the same machine as your TVD server) can connect, but a remote client (Studio, which is running on a different machine) cannot. It indicates that there may be a network issue blocking the connections coming in to TDV from remote machines. To double-check, see if you can connect using a browser running on the machine on which your Studio is installed:
             http://internal.redwood.com:9400
If the browser also fails to connect, then it is very likely to be a network issue.

If the answer to the above question is  NO:

If curl and wget cannot connect, then the basic services (i.e. TDV and the Repository) may not be down. Check whether this is the case, as follows:

             $ ps -elf | grep ServerBoot
             $ ps -elf | grep postgres

The screenshot below shows the type of outputs that you will see if the services are running:

               

If the basic services are not running, start the services.

(2) Is TDV server in a listening state?

Use netstat to find out whether TDV is accepting requests.                
             netstat -an | grep 9400

The netstat output should show that the port  ( e.g. 9400) has a "LISTEN" status. If the output does not display this status,  it means that TDV has stopped listening for requests.
 
     

If TDV is not in a listening state, wait for a while and retry, as it could be that TDV is busy servicing requests and needs some time to finish processing the requests. If this does not help, restart TDV or if  restarting is not feasible (e.g. this is a Prod environment), obtain a Thread Dump as described below and contact Technical Support to analyze the dump to find out the root cause.

(4)  Get a Thread Dump 

To generate a Thread Dump, follow the steps  below:

(i)     ps -elf | grep ServerBoot

This will give you the PID of the CIS server. Below is a sample output:

0 S support  17816 17773  0  80   0 - 1208423 futex_ 2017 ?  03:20:05 /opt/Cisco_Systems/CIS_704_Anil/jre/bin/java ...<snip>... com.compositesw.base.boot.ServerBoot run

==> From this output, the server PID is   17816

(ii)    kill -3 <PID>

Example
kill -3 17816

Running kill -3 tells the JVM to write a Full Thread Dump to the cs_server.out* log.

(iii)    Send us the cs_server.out* log. When time permits, zip up the entire TDS_INSTALL/logs folder and send it to us. 

To verify that a thread dump was generated:
    -  Open  cs_server.out* using any text editor
    -  Look for a line that says " Full thread dump"

Example
cs_server.out:Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.71-b01 mixed mode):