Settings & Troubleshooting
To open the Settings dialog, click on on the top right of your screen. Currently, the following settings are available:
- Show Gremlin Step Documentation On Editor Side: If enabled, whilst writing a query in the query editor, autocomplete suggestions will be complemented with the corresponding Apache TinkerPop™ documentation as found on https://tinkerpop.apache.org/docs/current/reference/#graph-traversal-steps.
- Show Warning Before Executing Query using Drop Step: When executing a query resulting in the deletion of elements in your graph, displays a warning prompt to confirm that you want to proceed.
- Code Editor Font Size: The font size in pixel of the Gremlin query editor
- Enable Query Editor Smart Autocomplete: Enabled by default, determines if autocomplete suggestions should be shown whilst typing a query. If disabled, the Gremlin Step Documentation on the editor's side will also not show.
OpenAI settings allow configuring how to connect to the OpenAI API and which GPT model to use when using the Text To Gremlin functionality. The following settings are available:
- OpenAI Secret API Key: Required to use OpenAI functionality on G.V(). Your OpenAI Secret Key to connect to the OpenAI API.
- OpenAI Model: The OpenAI GPT Model to use to generate Gremlin queries.
Gremlint settings affect the behaviour of the format button in the Query Editor. The following settings are available:
- Place Dots After Line Break: Determines whether to break between steps before or after the dot
- Indentation: Determines the length of indentation to be used in formatting, where indentation unit is a space
- Max Line Length: Determines the maximum allowed length of a line before breaking it
- Enable Dark Mode: Allows toggling between "dark" and "light" modes for the user interface.
- Logging Level: Allows specifying the logging level in place. For more information on logging, see the Troubleshooting section below.
G.V() collects log data based on the Logging Level specified above for troubleshooting purposes. The logs are not sent anywhere outside of your device, but may be useful for the purpose of investigation in case of any unexpected issue occuring during use of the software. The logs will be stored at the following locations, depending on your operating system:
- Windows: %USERPROFILE%\AppData\Roaming\gdotv\logs\main.log
- macOS: ~/Library/Logs/gdotv/main.log
- Linux: ~/.config/gdotv/logs/main.log
If you encounter issues whilst using G.V(), please email email@example.com.
G.V() Failing To Start
In some rare cases a corporate proxy or firewall, or sometimes an antivirus can interfere with G.V()'s functionality and prevent it from starting correctly.
See below a list of troubleshooting steps you can take immediately to resolve the issue - it should take 15 minutes maximum. Alternatively you can also contact us directly at firstname.lastname@example.org for assistance.
G.V() runs an HTTP Web Service on your device on a random port and effectively acts as the "back end" of G.V(). This web service is only available on your device and not across the network, and runs on the "localhost" hostname. This service will be refered to moving forward as the "G.V() Backend"
When this issue occurs, you will see the following screen:
Click on Show Diagnostics Information to display further details to assist with troubleshooting.
The Diagnostics Information will display the port number the Java backend is using as well as a localhost URL you can try in your browser to test if a firewall/corporate proxy is blocking the service. The url will be in the following format:
The port is randomly allocated on startup and may differ at every try so when troubleshooting always make sure to check the Diagnostics Information first to find the port number in use.
The first troubleshooting step we advise you to take is to navigate to the URL in the Diagnostics Information described above on your usual browser on the same device. If the G.V() Backend is running as intended, it will display a simple text message on your browser stating the following:
G.V() Backend is ready
If the URL cannot be reached at all, this suggests the G.V() Backend could not be started at all. In this case, follow the troubleshooting instructions under Troubleshooting G.V() Java Process not starting.
If the URL can be reached but is not displaying the text message above, this suggests that the G.V() Backend started successfully but something is blocking access to the endpoint on your device on your browser and likely on the gdotv process too. In this situation, follow the instructions under Troubleshooting Corporate Proxy and Firewall issues.
If the URL can be reached and displays the success message shown above, this suggests that the G.V() Backend started successfully but something is preventing the gdotv process itself from accessing it. In this case, follow the instructions under follow the instructions under Troubleshooting Corporate Proxy and Firewall issues.
The G.V() software runs two processes:
- gdotv: The main gdotv process which uses the ElectronJS framework. At startup, this process spawns the G.V() backend process described below. The gdotv process connects over HTTP to the Web Service ran by the java process during runtime.
- a java process that points to the JDK Path displayed in the Diagnostics Information, running the JAR Path also shown in the Diagnostics information. This process is a child of gdotv and is connected to by gdotv over HTTP. This process shuts when gdotv is shut.
Troubleshooting G.V() Java Process not starting
G.V() bundles its own optimized Java Development Kit (JDK) to ensure that the correct version of Java is used to run the G.V() Java Backend process. All the executables under the JDK (as well as G.V()'s own executables) are all signed using G.V()'s Extended Validation Code Signing Certificate for Windows and G.V()'s Apple Developer Certificate for MacOS and should be trusted on the device by default.
It is however possible that a corporate antivirus (AV) software may interfere with the JDK nonetheless, albeit highly unlikely. The Diagnostics Information dialog will display information about the JDK path that you can use to test if the executable is indeed getting blocked by AV software under the "JDK Path" line item.
Additionally, the Diagnostics Information will display the path of the "JAR" file of the G.V() Backend. The JAR file is the compiled Java Package used to run the G.V() Backend
To test that the JDK is allowed to run on your device, copy the value of the "JDK Path" line item and paste it in a command line interface/terminal of your choice on the device, then press enter. If the JDK is running as intended and not getting blocked, it should display a "Usage" message on your terminal.
We recommend that you use the values of the JDK and JAR Path line items in the "Diagnostics Information" error dialog to check if any AV or other security software is reporting the blocking of these binaries and take action to have them allowed.
Troubleshooting Corporate Proxy and Firewall issues
If you suspect a corporate proxy is responsible for G.V() failing to connect to its Backend, you should investigate whether any software is interfering with the gdotv process itself on your device. In the Diagnostics Information, a line-item called last gdotv application readiness check response shows the exact output of the HTTP connectivity test from the gdotv process to the G.V() Backend.
If the output shows an HTTP status code that isn't 2xx or 5xx, this strongly indicates a corporate proxy interference. In this instance, you should provide this information to your proxy team to lift the block from the gdotv process to localhost HTTP services hosted on your device.
If the output shows an HTTP status code of 2xx or 5xx, this indicates another issue which may require further investigation. In this instance, contact us at email@example.com for assistance.