Details
Major Description
This is a performance issue with grapes. I have two groovy files:
- A httpServer.groovy (attached) which runs an embedded jetty server and responds to http post requests
- A httpClient.groovy (attached) which runs HttpBuilder and does a http post to the server in the other script
both groovy files download dependencies using @Grab annotations and they both work.
Weirdness ensues in the following scenario:
- I have network connectivity enabled
- I delete my grapes cache
- I start the server script and wait of it to come up
- I run an infinite bash while loop which executes the client script and collects timings: 'while true ; do time groovy -d httpClient.groovy ; done'
Console logs of both client and server runs attached. It turns out that the client script takes about 4 seconds to run two times and then every third time it takes 25-30 seconds to run. I've verified this over hundreds of runs and it does not seem like a random occurrence of say network congestion or cpu load. In the attached console logs we can see that the server takes 1-5ms to handle requests, but the client script trundles along in a sequence of 4s, 4s, 25s, 4s, 4s, 25s etc.
If I turn off my nic the timings become deterministic: 4s, 4s, 4s
I have also tried running against the RC2 release of the http-builder package with identical results. As I believe the snapshot and RC2 versions are served by different remote repos, this would lower the probability that this is a remote repo issue. I also removed my ~/.groovy/grapeConfig.xml before the test.
So a couple of questions:
- what is going on here
- is there any way to force debug logging for grapes during script execution to find out what it is actually doing
I suspect this issue might be caused by the check-for-new-version-every-time snapshot jar handling logic. If so, maybe it would be a good idea to have an extra parameter to the grab annotation:
@Grab(..., checkmodified=false)
just as we do for repositories in the grapeConfig.xml file. This would basically instruct the resolver to not check the remote repos for a new version of this particular jar once one matching the version is in the local cache...even if the version has 'SNAPSHOT' or 'RC2' at the end. As we don't always have control over 3rd party versioning (http-builder latest stable is for example RC2 which I suspect is treated the same way as a snapshot release), it would be nice to be able to force your script to run in 4 seconds insted of 30. Grapes gurus, you'll probably have a better solution, but figured I'd throw it out there.
In summary, the above behavior makes calling the http-builder from groovy using grapes useless for me as the 30s delay is not acceptable in my current context. Any ideas or suggestions would be most welcome.