Troubleshooting DataStax Studio

Tips for resolving problems in DataStax Studio.

cassandra.yaml

The location of the cassandra.yaml file depends on the type of installation:
Package installations /etc/dse/cassandra/cassandra.yaml
Tarball installations installation_location/resources/cassandra/conf/cassandra.yaml

The DataStax Enterprise Help Center also provides troubleshooting information.

Studio will not start with wrong Java version

Studio checks the JAVA_HOME environment variable at startup. To ensure that Studio starts with the correct version of Java, make sure the JAVA_HOME environment variable points to the installation directory with the supported version of Java. See Supported platforms. Note that even when the java -version command shows a supported Java version, it is possible that JAVA_HOME environment variable is not set to the correct Java installation directory.
Tip: Windows users: For related troubleshooting information, see Starting Studio on Windows 10 or Starting Studio on Windows 7 in this topic.

NOT ENABLED error: AlwaysOn SQL cell cannot be executed

The AlwaysOn SQL cell cannot be executed when the connection is to a DSE cluster that is not correctly configured for the AlwaysOn SQL service.

In order to run AlwaysOn SQL, you must have:

STOPPED error: AlwaysOn SQL cell cannot be executed

The AlwaysOn SQL cell cannot be executed when the AlwaysOn SQL service is stopped on the DSE node. See Checking the status of AlwaysOn SQL.

HTTP protocol

DataStax Studio does not run with HTTPS everywhere. Preface the URL used to run DataStax Studio with HTTP and not HTTPS.

Studio won't accept connections from external addresses

By default, Studio binds itself to the IP address 127.0.0.1 (or localhost). If running in the cloud, this IP address prevents Studio from accepting connections from external addresses. If you have already installed Studio in the cloud using localhost, change the httpBindAddress value in the configuration.yaml Studio configuration file to the IP address of the host it is running on.
Important: Changing the httpBindAddress setting from the default (localhost) can pose a security risk as users on external machines can gain access to notebooks and the DSE clusters those notebooks are connected to. Studio is designed to be used as a desktop application. Distributed deployment introduces potential security risks.

Unable to connect Studio to a secured DSE cluster

If you are unable to connect Studio when client-to-node encryption enabled on a DSE cluster, the Studio log has this entry:
Cannot support TLS_RSA_WITH_AES_256_CBC_SHA with currently installed providers
Java Cryptography Extension (JCE) Unlimited Strength Policy files is required to ensure support for all encryption algorithms. See Using SSL connections in DataStax Studio.

Content assist not working

On MacOS 10.12, a network configuration issue when running Studio causes content assist functionality to become slow or unresponsive. For troubleshooting steps to resolve this networking issue, see this Stack Overflow post.

Notebook needs troubleshooting

When you export a notebook, you can specify actions for the notebook. As appropriate, select to include cell code and results or cell code only. For either of these actions, you can also select to include diagnostics. Exporting a notebook with diagnostics might include sensitive Information. Credentials are not included in the export.

Studio UI behaves strangely after upgrade

If you leave an old Studio session open in a browser, using an older version of Studio, and then upgrade to a new version, you can experience strange behavior. This is caused by caching in the browser. You can solve this problem by force-loading the index.html page. For example, if using the Chrome browser, you can navigate to the top-level index.html page and click on the refresh button while holding down the control key.

Starting Studio on Windows 10

While running Studio on the Microsoft Windows 10 operating system, out-of-date libraries can prevent system-specific JNI libraries from being loaded correctly. The result is the following stack trace:

[Studio-akka.actor.default-dispatcher-4] ERROR akka.actor.OneForOneStrategy ID:  TS: - head of empty list
java.util.NoSuchElementException: head of empty list
    at scala.collection.immutable.Nil$.head(List.scala:420) ~[scala-library-2.11.8.jar:?]
    at scala.collection.immutable.Nil$.head(List.scala:417) ~[scala-library-2.11.8.jar:?]
    at akka.actor.ActorCell.receiveMessage(ActorCell.scala:526) ~[akka-actor_2.11-2.4.17.jar:?]
    at akka.actor.ActorCell.invoke(ActorCell.scala:495) ~[akka-actor_2.11-2.4.17.jar:?]
    at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257) ~[akka-actor_2.11-2.4.17.jar:?]
    at akka.dispatch.Mailbox.run(Mailbox.scala:224) ~[akka-actor_2.11-2.4.17.jar:?]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149
You can fix this problem by updating the Microsoft Visual C++ 2010 Redistributable Package libraries in question:
Important: When deciding whether to download the 32-bit or 64-bit version of the MS Visual C++ libraries, you should use the version that matches the OS architecture. Even if your node is running a 64-bit OS, it's possible that you have 64-bit or 32-bit (or both) MS Visual C++ libraries installed.
  • If you have 64-bit MS Visual C++ installed, update your node with the 64-bit libraries.
  • If you have 32-bit MS Visual C++ installed, update your node with the 32-bit libraries.
  • If you have both 64-bit and 32-bit MS Visual C++ installed, DataStax recommends that you uninstall the version that does not match your system. For example, if your OS is 64-bit, uninstall the 32-bit (x86) Visual C++. Doing so avoids a potential issue where the wrong version may be found and used by Studio.

To determine the installed MS Visual C++ architecture (x64 or x86, or both), open Settings, Apps & features, and search for "c++".

Starting Studio on Windows 7

While running Studio on the Microsoft Windows 7 operating system, out-of-date libraries can prevent system-specific JNI libraries from being loaded correctly. The result is the following stack trace:

leveldbjni-64-
1-6036870325998847314.8: Can't find dependent libraries]
        at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182)
        at org.fusesource.hawtjni.runtime.Library.load(Library.java:140)
        at org.fusesource.leveldbjni.JniDBFactory.<clinit>(JniDBFactory.java:48)
        at com.rbmhtechnology.eventuate.log.leveldb.LeveldbEventLog.<init>(Level dbEventLog.scala:97)
        at com.rbmhtechnology.eventuate.log.leveldb.LeveldbEventLog$$anonfun$7.apply(LeveldbEventLog.scala:358)
        at com.rbmhtechnology.eventuate.log.leveldb.LeveldbEventLog$$anonfun$7.apply(LeveldbEventLog.scala:358)
        at akka.actor.TypedCreatorFunctionConsumer.produce(IndirectActorProducer.scala:87)
You can fix this problem by updating the Microsoft Visual C++ 2010 Redistributable Package libraries in question:
Important: When deciding whether to download the 32-bit or 64-bit version of the MS Visual C++ libraries, you should use the version that matches the OS architecture. Even if your node is running a 64-bit OS, it's possible that you have 64-bit or 32-bit (or both) MS Visual C++ libraries installed.
  • If you have 64-bit MS Visual C++ installed, update your node with the 64-bit libraries.
  • If you have 32-bit MS Visual C++ installed, update your node with the 32-bit libraries.
  • If you have both 64-bit and 32-bit MS Visual C++ installed, DataStax recommends that you uninstall the version that does not match your system. For example, if your OS is 64-bit, uninstall the 32-bit (x86) Visual C++. Doing so avoids a potential issue where the wrong version may be found and used by Studio.

To determine the installed MS Visual C++ architecture (x64 or x86, or both), open Settings, Apps & features, and search for "c++".