0

While using WireMock to mock an endpoint that is expected to return JSON, I have come across a problem where it will not return the expected JSON. Querying WireMock for its stubs will reveal the correct JSON at the expected endpoint.

While running several datapoints against my theory I typically get 7 successfully passed tests before this problem occurs and the test fails. However, adding a sleep of about 5 seconds at the top of the theory allows all of the tests to pass. Wrapping the contents of the test in a loop will have it run one datapoint several times, which eventually fails. Adding in the sleep will allow it to run further, but eventually it serves up a null.

Is this a known issue? Is there a suitable workaround?

Tott
  • 11
  • 1
  • 4
  • How can we help if you show no code.. – Javant Aug 16 '16 at 20:05
  • @Javant The problem seems to only manifest itself in the full project. Every small proof of concept test I write that uses the same pipeline succeeds. I'd have to provide the entire project, which I am unable to do. – Tott Aug 17 '16 at 11:50
  • Are you adding the stub dynamically (is there a memory leak possibility)? Can you identify the failing requests? See if manually querying with them can reproduce the problem. If not, try to simulate a high load scenario with the same request. – Eugene A Aug 18 '16 at 15:49
  • @EugeneA The stub is added dynamically, but the number of times the stub is added doesn't matter. That is, clearing the stubs and readding them in the Before, the BeforeClass, or the theory itself doesn't change its behavior. The failing request is the eighth, unless sleeps are added. This is true even on another computer that runs the datapoints in a different order (meaning it fails on a different datapoint). – Tott Aug 18 '16 at 16:07
  • Try running Wiremock in a debug mode and see if this null produces an exception in the logs. If it does, it should not be hard to debug Wiremock and see what are the conditions, leading to the null response. – Eugene A Aug 19 '16 at 08:46

1 Answers1

1

Turns out it was Hystrix's Short Circuit. Each test case was stubbing one of three endpoints, with the other two failing. After the seventh test that was 21 calls and 2/3rds of them failing. Short Circuit cuts in after 20 calls where half of them fail.

hystrix.command.default.circuitBreaker.requestVolumeThreshold=100

This will stop it from skipping straight to the fallback.

Tott
  • 11
  • 1
  • 4