GemFire sample integration test fails with JAVA_TOOL_OPTIONS env variable #669
Comments
|
@jxblum Do you have any idea on this one? |
|
@vpavic (cc'ing @rwinch) - I think it is safe to say the In fact, this (GemFire "client/server") test is susceptible to same failure as the Recently, I posted the exact same Stack Trace here. I am closing this as a duplicate! |
|
@jxblum I wouldn't agree with your assesment. I've got a machine that's got So that's 100% reproducibility. |
|
@vpavic - Right, agreed/understood. For some reason (which is not apparent with the details you provided above) your environment configuration is definitely leading to the same failure and "cause" captured in #672. So while you are able to reproduce this problem 100% of the time with "seemingly" only the following Java System properties set ( Having said that, let me shed more light on what might possibly be causing your problems. First, understand that in no way does GemFire use the HTTP protocol between cache clients and servers (much less for any other type of communications... membership, P2P, WAN, etc); hopefully, the reason for this is obvious. GemFire exclusively uses TCP/IP-based This is not to say you won't find components in GemFire (e.g. Gfsh or Pulse) that do use HTTP and are affected by these Java HTTP proxy System properties, but these components are independent of the client/server infrastructure and protocols (i.e. these tools have and use their own communications infrastructure). According to... http://docs.oracle.com/javase/8/docs/technotes/guides/net/proxies.html In order for the HTTP proxy configuration settings to have any effect, an "HTTP" connection would need to be made, which in turn would summon the HTTP protocol handler that would take these HTTP proxy configuration settings into account. The only Java class I am aware of that handles the HTTP protocol/scheme is GemFire does not use In fact, GemFire does all of its Under-the-hood, GemFire's So, what does this mean? Well, I just tested locally using the Specifically, I set the NOTE: to get this output, I needed to turn up GemFire logging (to "config") and send the log entries to a file. I have created a branch (gh-669) in my Spring Session clone with the necessary build configuration and class file changes. Now, you will notice that I have additionally set the Additionally, you will notice that the As it turns out, these settings had NO effect whatsoever! The So, how would GemFire take PROXY configuration settings into account? A user would have to specifically provide a This provider could have been installed in the JDK/JRE ( Either way, I am convinced this is not a problem with the sample or GemFire in this case. |
jxblum
added
status: declined
|
Thank you for the detailed write up @jxblum. I'd like to stress one more time that my issues are not due to proxy related JVM system properties, but rather to the presence of Proxy is the reason I need to use I'll try to gather more information about what actually happens in these two scenarios. |
|
Thanks @vpavic for the additional feedback/clarification.
That is bizarre. While the GemFire does care about "
Right, my apologies for the misunderstanding. I incorrectly assumed the (HTTP) Proxy settings were causing an issue when I saw the client/server communication problems, and specifically, the darn So, I just set the And, whaddya know... BOOM! I'll have a look. Thanks @vpavic. |
|
So, looking at the output from the test... It is clearly tripping on the So, I turned on logging and tried to get both the GemFire client and server to spit out log files (at log-level, " So, I then tried to run the So, this tells me there is something wrong with Gradle (Groovy?) and specifically with the way in which the GemFire Server is forked. I.e. perhaps there is something funky about I also verify by commenting out this line in the build.gradle file, to prevent the GemFire Server JVM process from being terminated after test completion. No GemFire Server JVM process was found using either Why (how) do I always seem uncover the damnedest problems? GAH!!! |
jxblum
removed
the
status: declined
|
Argh, it also does not seem to let go of the Is there no way to avoid this other than a reboot? |
|
Another update... Seems to be just a problem with forking and launching a (Spring Boot-based) GemFire Server. I just tested with a simple Java class... ... and it runs I could not get it to print out " I suspect all that Groovy's Next, I am going to try to fork and launch a GemFire Server just using the GemFire API in a simple Java main class. |
|
Yet another update... After creating a Java class that uses GemFire's native Java API to launch a GemFire Server, and getting Another thing... Actually, I was WRONG about forking and launching the simple It does NOT run when the See here... Then... NOTE: I renamed the " No " I then unset Hah! Hello... " Note, in every run I was careful to cleanup any processes and log files. If you are not careful to kill the I would have been seriously pissed if I had to reboot my machine just to clear that crap out! Unfortunately, I haven't been able to get (<BEEP>, <BEEPIN>, <BEEP>) Gradle/Groovy to log anything useful, yet. (errrrr!) |
…uild changes to test spring-projectsgh-669.
|
Well, I am currently at a loss! It's 0 to 10 and Groovy/Gradle is winning. I need to go drink, errr, I mean sleep this one off. If either of you fancy to take a stab at this, I put my changes on my gh-669 branch. I will probably pick this up tomorrow along with wrapping up #714 (I hope). Cheers, |
…uild changes to test spring-projectsgh-669.
…uild changes to test spring-projectsgh-669.
…uild changes to test spring-projectsgh-669.
|
Yay! I finally figured this one out! Turns out the process handling logic I had in the Gradle build scripts for the GemFire samples (e.g. I created a separate project (groovy-gradle-examples) containing a similar Gradle build script to run an integration test (client) against a server process forked by my Gradle build script. By simply not closing the input, output and error streams of the Get spit out on the command-line when the I will be checking in a fix for this problem shortly. |
|
That's great news @jxblum! 👍 The special variable info (i.e. the "Picked up" message) is printed to
😄 Well, I actually need that environment variable available to all processes hence the export via |
|
Thanks @vpavic.
Right. I also noticed that it prints red in my IDE, which is only the case for stderr output. I would say it is questionable (arguable) whether "that" should have caused the entire process to fail though. Not retaining resources where they are not needed (used) is valid (particularly in In-Memory based Distributed Systems) and IMO, this is not any different than setting Log Level to OFF, well for some logging frameworks anyway. Anyhow, I have seen dumber things I reckon. |
…A_TOOL_OPTIONS env var Fixes spring-projectsgh-669
…A_TOOL_OPTIONS env var Fixes spring-projectsgh-669
|
That is awesome! Thanks for the feedback @vpavic; much appreciated. Glad to lay this issue to rest. |
This consequently causes the project build to fail.
If I don't export the
JAVA_TOOL_OPTIONSenvironment variable then everything runs fine.I guess this is related to that fact that JVM prints information about special variable, such as
JAVA_TOOL_OPTIONSor_JAVA_OPTIONS, tostderr. For example:/cc @jxblum since this is GemFire related you might want to take a look.
Here's the relevant build output:
Other relevant information about environment:
The text was updated successfully, but these errors were encountered: