Closed JulianAffaire closed 4 years ago
Can you please upload your sample to GitHub? I'd have to debug it. In the meantime you can debug it yourself by starting WireMockHttpServerStub#start
and if the if (configuration.configurer.isAccepted(wireMockConfiguration)) {
condition is met and that your code gets executed.
I uploaded a sample in my personnal repo: https://github.com/JulianAffaire/services-stub
When I run the debug mode on the application I can see that the COnfiguration is readed. So Everythings seem ok but wiremock seems to not start with those parameters (I compared with the use of Wiremock FatJar).
Thanks
I debugued and it seems the configuration is weel registered by wiremock. But there is a big difference in term of performance between using stubrunner VS Standalone Wiremock Fat Jar (same wiremock configuration). Using stubrunner when I test with lot of request per seconds it's slowing down quickly. Is there a raison? Thank you
Ok, so the main problem is solved, right?
As for the performance, I have no idea really, it's hard to track those things. Stub Runner just runs WireMock stubs and does nothing else, I have no idea what could impact the performance.
No it's not, because of this big difference between performance. Is there a way to be sure wiremock is really using those parameters when using StubRunner?
I debugued and it seems the configuration is weel registered by wiremock.
I really don't understand what else I can do.
Can you please provide steps for me to understand what is currently not working and what in your opinion should be done for this to start working. Also, the question is: how did you measure the performance?
Ok, I started Stubrunner with the project in copy : https://github.com/JulianAffaire/services-stub Then I used JMeter to test the performances of the Stub. I noticed that is slowing down really quickly :(.
Otherwise, I started Wiremock Fat Jar (http://wiremock.org/docs/running-standalone/)
java -jar wiremock-standalone-2.25.1.jar --no-request-journal --container-threads 100 --jetty-acceptor-threads 10 --jetty-accept-queue-size 100 --jetty-header-buffer-size 16384 --async-response-enabled true --async-response-threads 20
Then, with a script I recorded in it the Stubs :
for filename in ./services-stub/build/stubs/META-INF/com.myapp.service/services-stub/1.0.0/mappings/**/*.json; do
curl -X POST -H "Content-Type: application/json" -d @"$filename" http://localhost:8083/__admin/mappings/new
done
With Wiremock Fat Jar the test with Jmeter is really much better.
So I try to understand this gap :( . If I can do something to use stubrunner instead of Wiremock Fat Jar. Because Stubrunner is really easy to use with SpringBoot.
Are you able to confirm that with a configuration like that in Stubrunner Wiremock is really using my custom configuration? I know it's tricky it's why I asked :)
Thank you
I saw Stubrunner is using wiremock-standalone-2.20.0.jar Maybe the wiremock version is the problem? Is there a way to upgrade it?
You can try to use the latest Hoxton.RC1 release train version (Contract 2.2.0.RC1) where we've bumped WireMock to the latest available version. You can also set the property wiremock.version
in your build to a given WireMock version.
You could run a performance test against the same version of wiremock-standalone and see if there is a difference in performance.
The problem was the wiremock version :) It seems similar now in term of performance. In my gradle file I added:
compile 'org.springframework.cloud:spring-cloud-starter-contract-stub-runner:2.2.0.RC1'
compile 'com.github.tomakehurst:wiremock-standalone:2.25.1'
Thank you for the support.
No problem
Hi,
I tried to launch stubrunner as standalone thanks to spring boot :
You can see I added "httpServerStubConfigurer" :
In debug mode I can see this configuration is well executed but wiremock seems to not use those custom parameters :( . Is there an other way to customize Wiremock configuration ?
Thanks, Julian