Troubleshoot DataStax Studio 6.8

For additional assistance and troubleshooting information, see the DataStax Enterprise Help Center.

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

Out of memory error (OOM)

Studio crashes during runtime or startup and the following stack trace is observed in the log:

Exception in thread "Thread-0" java.lang.OutOfMemoryError: Java heap space
        at java.util.Arrays.copyOfRange(Unknown Source)
        at java.lang.String.<init>(Unknown Source)
        at java.lang.String.substring(Unknown Source)
        at com.datastax.studio.server.Bootstrap$ProgressBarTraditional.run(Bootstrap.java:638)
Uncaught error from thread [Studio-eventuate.log.dispatchers.read-dispatcher-43]: Java heap space, shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for for ActorSystem[Studio]
java.lang.OutOfMemoryError: Java heap space

Fix this problem by increasing the max heap allocation (-Xmx) for Studio’s Java Virtual Machine (JVM). For more, see Specify JVM settings for DataStax Studio.

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:

A running datacenter with DSE Analytics nodes enabled.
Enabled AlwaysOn SQL on every Analytics node in the datacenter.
Modify the replication factor for all Analytics nodes, if necessary.
Set the native_transport_address in cassandra.yaml to an IP address that is accessible by the AlwaysOn SQL clients. This address depends on your network topology and deployment scenario.
Configured AlwaysOn SQL for security, if authentication is enabled.

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). To change the listen IP address, see Configuring 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. To troubleshoot this issue, run hostname to get your machine name, and then add the following to /etc/hosts:

127.0.0.1 macbook-name ::1 macbook-name

This resets the time to a more appropriate duration of less than one second.

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

Prior to Oracle Java 8u161, the Java Cryptography Extension (JCE) Unlimited Strength Policy was not enabled by default. On older versions of Oracle Java, the policy files are required to ensure support for all encryption algorithms. See Oracle’s instructions on Enabling Unlimited Cryptographic Policy for Java to install the policy files for Studio’s Java Virtual Machine.

Notebook needs troubleshooting

When you export a notebook, you can specify actions for the notebook. Depending on your use case, you can choose to include cell code and results or cell code only. For either of these actions, you can also select whether you want to include diagnostics. Exporting a notebook with diagnostics might include sensitive information, but credentials aren’t included in the export.

Studio UI behaves strangely after upgrade

If you upgrade Studio while running an older version of Studio in an open browser, browser caching can cause the UI to behave unexpectedly. You can solve this problem by force reloading the index.html page. For example, on Chrome, navigate to the top-level index.html page for Studio, right-click anywhere on the page, and then select Reload.

Startup issues with Studio on Windows

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

Windows 10
Windows 7

[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

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.

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, you could have 64-bit, 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 version.
If you have 32-bit MS Visual C++ installed, update your node with the 32-bit version.
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++.