Troubleshooting

Tomcat unable to bind port (error in log file)

Occasionally if the Drillbridge server is not shut down properly it will leave a process running and using the port that Drillbridge wants to operate on. This can prevent Drillbridge from starting properly. To fix this on a Windows system, just start the Task Manager, look for a process named java.exe, and stop it. Then start up the Drillbridge server.

Class Unsupported Error

As of version 1.5.0, Drillbridge requires Java 1.7 or greater. Java version 1.8 is recommended. If you have Java 1.6 or older on the PATH or otherwise set of the default version of Java to use, you may find a "Class Unsupported Error" message when attempting to start Drillbridge. TO fix this you must upgrade Java.

Specifying a different Java than what is on the path

It may be necessary to specify a version of Java that is 1.7 or greater but is not located on the PATH. This might happen when you need to leave your default Java alone, but install Java 1.7+ for the purposes of running Drillbridge. This can be easily accomplished with a simple configuration change.

First, install Java onto your machine. The default directory on Windows will usually be under the C:\Program Files directory structure. This works but our preference is to install all JREs/JDKs underneath C:\Java, such that there is C:\Java\jre1.7, C:\Java\jdk1.8, and so on.

With Java 1.7+ installed, next we need to edit the wrapper.conf file located in the Drillbridge config folder (this folder is in the folder where you installed Drillbridge). Edit the line with the setting marked 'wrapper.java.config'. By default it will have a value simply of 'java'.

You may change this to a fully qualified java.exe location. For example, if you installed a Java 1.8 (such as the JRE or JDK) and your install folder is the following:

# C:\Java\jdk1.8

Then the Java executable will be in the following location:

# C:\Java\jdk1.8\bin

And therefore, the full command to invoke this version of Java from any folder would be:

# C:\Java\jdk1.8\bin\java

You can test this by tying this in a command prompt and verifying that Java runs:

# C:\Java\jdk1.8\bin\java.exe -version

Once you verify that your specific command successfully runs Java, simply update your wrapper.java.command setting to reflect this:

# wrapper.java.command=C:\Java\jdk1.8\bin\java.exe

Be sure you do not include the -v parameter as that is used purely to report the version. The command entered in the config file will now be used to launch Drillbridge.

Drill to Bottom on a dimension containing spaces in the name

Proper care has to be taken when setting up a drill-to-bottom token on a dimension containing spaces. In this case the "name" field on the token MUST match the dimension name and contain spaces. The variable name you reference inside of the expression of the token, however, should be the dimension name but with all spaces replaced with underscores. If your drill-to-bottom dimension is named "Cost Centers" then the variable name would be #Cost_Centers

Java java.io.tmpdir Issue

Stack trace contains "The system cannot find the path specified" or "Unable to start embedded container; nested exception is org.springframework.boot.context.embedded.EmbeddedServletContainerException: Unable to create Tomcat tempdir. java.io.tmpdir is set to `C:\Windows\system32\config\systemprofile\AppData\Local\Temp\`" (or similar).

This seems to be an issue with the Windows security model. Drillbridge needs a temporary directory to run the web app in, but it is unable to write to the folder that Windows gives it. This can be fixed by manually specifying the temporary directory to use.

Stop Drillbridge, open up your wrapper.conf configuration file, and find this line:

# Java Additional Parameters
#wrapper.java.additional.1=

You can leave those two lines commented but add in a new line:

wrapper.java.additional.1=-Djava.io.tmpdir=D:/Drillbridge/drillbridge-X.Y.Z/tmp

Instead of D:/Drillbridge, though, change it to the path of your Drillbridge installation, and then create a new folder, /tmp, inside of it. Then try starting Drillbridge again. It seems that the problem itself is that the user running Drillbridge does not have write access to the normal Java temp folder, so we are just forcing it to a location that we know we have access to: a new folder inside of the Drillrbridge folder.