Hoverfly has not become healthy in 10 seconds while running on an environment connected to a VPN about hoverfly-java HOT 13 CLOSED

from hoverfly-java.

Hi @Lin-Liang I can't reproduce this issue, please check out my repo using spring boot 2.2.0 and hoverfly-jave-junit5 https://github.com/tommysitu/springboot-demo

from hoverfly-java.

feel free to reopen if you have any issue again.

from hoverfly-java.

Hi,
I am actually having what it seems the same issue.

My environment is MacOS 10.15.7, AdoptOpenJDK 1.8.0_272, Junit 5.7.0, Hoverfly-Java 0.13.1

The only way I am able to make the test successfully run is to set a breakpoint somewhere in the code during the HoverFly lib initialization, for example HoverFly.java:534, and then make the test complete.
From Maven I cannot do that and in fact after the wait of 10 seconds I get the message that no tests are run.

Nov 02, 2020 11:12:40 AM io.specto.hoverfly.junit.core.TempFileManager copyHoverflyBinary
INFO: Selecting the following binary based on the current operating system: hoverfly_OSX_amd64
Nov 02, 2020 11:12:40 AM io.specto.hoverfly.junit.core.TempFileManager copyHoverflyBinary
INFO: Storing binary in temporary directory /var/folders/s6/f_cvf0kd06bcw4rrkdshnf400000gp/T/hoverfly.1108941060597213755/hoverfly_OSX_amd64
Nov 02, 2020 11:12:40 AM io.specto.hoverfly.junit.core.Hoverfly startHoverflyProcess
INFO: Executing binary at /var/folders/s6/f_cvf0kd06bcw4rrkdshnf400000gp/T/hoverfly.1108941060597213755/hoverfly_OSX_amd64
Nov 02, 2020 11:12:40 AM io.specto.hoverfly.junit.core.LoggingOutputStream log
INFO: Default proxy port has been overwritten port=51169
Nov 02, 2020 11:12:40 AM io.specto.hoverfly.junit.core.LoggingOutputStream log
INFO: Default admin port has been overwritten port=51170
Nov 02, 2020 11:12:40 AM io.specto.hoverfly.junit.core.LoggingOutputStream log
INFO: Using memory backend 
Nov 02, 2020 11:12:40 AM io.specto.hoverfly.junit.core.LoggingOutputStream log
INFO: Proxy prepared... Destination=. Mode=simulate ProxyPort=51169
Nov 02, 2020 11:12:40 AM io.specto.hoverfly.junit.core.LoggingOutputStream log
INFO: current proxy configuration destination=. mode=simulate port=51169
Nov 02, 2020 11:12:40 AM io.specto.hoverfly.junit.core.LoggingOutputStream log
INFO: serving proxy 
Nov 02, 2020 11:12:40 AM io.specto.hoverfly.junit.core.LoggingOutputStream log
INFO: Admin interface is starting... AdminPort=51170
Nov 02, 2020 11:12:50 AM io.specto.hoverfly.junit.core.Hoverfly cleanUp
INFO: Destroying hoverfly process
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.629 s - in c.r.l.c.CTTests

Any help is appreciated, I'd like to "advocate" the tool in the team but I need to show I can make it work as it should.
Many thanks!

from hoverfly-java.

Hey @rovio-alessandro, tbh I haven't come across this myself. I wonder if it's to do with using company laptop with some admin restrictions which block the running of hovefly binary in the system temp folder. A couple of people did have this issue who contacted before via the main hoverfly project.

Maybe you can try putting a break point here: https://github.com/SpectoLabs/hoverfly-java/blob/master/src/main/java/io/specto/hoverfly/junit/core/Hoverfly.java#L535

and then go to http://localhost:{admin-port}/api/health and see if your hoverfly is running?

If not, it would be hoverfly issue rather than hoverfly-java.

In the log you can also find the location of the binary, for example
/var/folders/s6/f_cvf0kd06bcw4rrkdshnf400000gp/T/hoverfly.1108941060597213755/hoverfly_OSX_amd64

Try starting and stopping it from command line to see if it works.

from hoverfly-java.

Jey @tommysitu, thanks for the reply.
I initially thought about my company laptop having some restrictions due to maybe some firewall configuration or something along that line, but that doesn't fit with the scenario with the breakpoint set from my IDE; my expectations would be that if such block on the execution of the binary or the aforementioned limit on the connectivity to some port exists, that would be in place regardless the type of execution I choose for the test, as either run or debug should behave the same way.
Connecting to the health api for hoverfly with the breakpoint set at the line you gave me made the server reply with
{"message":"Hoverfly is healthy"}.
If I try to do that with the test executed in "run mode" during the 10 seconds before the library gives up, the server doesn't replay anything but just hangs there until the process exists.
So in that sense you might be right, hoverfly-java most likely has nothing to do with the issue.
Running the binary from the command line works as expected.

I'll keep investigating, thanks again for your feedback and for the effort you put in the project.

BR,
Alessandro

from hoverfly-java.

no problem, could you try one more thing please? If you can clone this project and run the test https://github.com/tommysitu/springboot-demo, we can rule out that it's not to do with your environment.

Also if you can replicate the issue on that project, it will be easier for me to debug.

from hoverfly-java.

@rovio-alessandro thanks for trying it out, and you had a very interesting finding. I'll reopen this issue and investigate, as you are giving me a really good direction!

from hoverfly-java.

I've been seeing this exact issue in the past, where hoverfly would fail to start within the 10-second deadline while connected to a FortiClient VPN server.

I've recently upgraded macOS to 11.6.1 (from 11.5.x), to FortiClient 6.4.0, and using openjdk version "11.0.12" 2021-07-20.

I'm happy to report that the issue on my machine has gone away and that hoverfly Java integration now works without a hitch with/without a FortiClient VPN connection.

from hoverfly-java.

Fantastic @rud . Thanks for sharing!

from hoverfly-java.

Another cause of failures is that older versions are incompatible with M1 Macs. Our pom.xml references v 0.10.3 and a special version is needed to replace that in our ~/.m2/repository. I imagine that the latest version of 0.14.0 doesn't have this issue but AFAIK we can't upgrade to it yet.

from hoverfly-java.

@oehm-smith unfortunately we don't support that version any more, it's using a very old version of hoverfly < v1

from hoverfly-java.

Oh yeah I know @tommysitu - its just what we are using on our project and currently outside my scope to change.

from hoverfly-java.