Debug message spam from tinkerpop server 3.7
Right now, when connecting to my local tinkerpop server, I am getting incredible amounts of debug log spam, and I am unsure how to configure to reduce it.
The docs talk about being able to set environment variables in a bin/gremlin-server.conf next to the server start script, and I have done that, but they only list valid environment variables no examples of usage. If I treat it like a .env file, I would expect something like
DEBUG=False to do the trick but this does not seem to be the case? It may be relevant that I am running this on windows, and therefore using the .bat and not the .sh. I feel like I am missing something obvious, but I am not sure what I should be looking at next?Solution:Jump to solution
I have configured the logback.xml in both the server and console directories to ERROR level and verified it suppresses all output from both at launch. but as soon as I connect to the server, that seems to be overridden.
However, I have found a workable solution running everything in docker(identical configs across the board), so I am going to chalk this up to windows weirdness and leave it. thanks for taking the time to look at this though....
2 Replies
I assume the Gremlin Console isn't finding the logback.xml file. This could be an issue related to windows. maybe @Yang Xia or @Kennh know what's happening there for windows?
looks like you also have a jar conflict. i'd delete this manually:
C:/apache/gremlin-console-3.7/ext/neo4j-gremlin/lib/slf4j-nop-1.7.25.jar
unfortunately, there's not much we can do about plugins conflicting
assuming gremlin.bat is finding the logback.xml file perhaps there's a problem with the environment variable? maybe just edit the file directly?
change the root "level" configuration to "INFO" and see if that cleans things up while we wait to hear if others can recreate the problemSolution
I have configured the logback.xml in both the server and console directories to ERROR level and verified it suppresses all output from both at launch. but as soon as I connect to the server, that seems to be overridden.
However, I have found a workable solution running everything in docker(identical configs across the board), so I am going to chalk this up to windows weirdness and leave it. thanks for taking the time to look at this though.