Thanks both,
Using yet another GFSH command (*export stack-traces*) when the system is
already a distributed deadlock doesn't seem right :-). On the other hand,
*jstack* and *jcmd* both work as expected, but my goal was to make *KILL
-QUIT / KILL -3* work, it's easier and widely known. I'll keep w
Sorry, my info on redirecting of stdout and stderr was stale (circa GemFire
7.0). Now that the code base is an Apache project, I believe redirecting of
stdout and stderr no longer occurs. However, it does shut off the Log4j2
ConsoleAppender to stdout when the LogWriterAppender is activated and turn
Hi Juan,
Thanks for the detailed analysis.
I did some digging too and cannot see why the QUIT signal might be getting
lost. I'll do some more investigation...
Just for reference, you can still use the 'jstack' tool to get thread dumps
although they just show on the terminal where you run the com
Hello again,
Regarding my last question from the original email (unformatted jetty
logging when enabling --*redirect-output*), it looks like the offending
library within the *geode-pulse.war* is *commons-logging-x.x.jar.* The
library is configured as *providedCompile* in *build.gradle* and, by
def
By default Geode redirects stdout and stderr to the value of the log-file
property when the Cache starts. If log-file is set to "" then it won't
redirect them.
When we changed GemFire to use Log4J2 internally, we tried to leave stdout
and stderr alone such that the LogWriterAppender would append l
Hello Geode devs,
Currently GEODE is "swallowing" all output sent to stdout and stderr by
default and there's no way of changing this behavior when starting members
through *gfsh*.
This, between other things, prevents users, between other things, from
playing around with *System.out.println()* dur
