ConfigurationLoader isn't thread safe due to its use of ConfigSlurper #423
Comments
Yes, |
Out of curiosity, why did you go for parallelizing your suite using threads instead of using multiuple test JVMs (like when setting |
Mostly due to resource constraints. Forking seemed to use considerably more On Sat, Feb 20, 2016, 3:53 PM Marcin Erdmann notifications@github.com
|
Thanks for the explanation. Hopefully the changes I made based on your reports will enable you to get better efficiency. Btw, you can work around this issue by changing your config script to be a resource instead of a class - it will be parsed from text every time essentially creating a new script class with every call. |
I appreciate all your help with this, I'll look into making it a resource. On Sun, Feb 21, 2016, 6:40 AM Marcin Erdmann notifications@github.com
|
Running Specifications using 1 thread per spec results in seemingly random failures when loading GebConfig.groovy. With 5 threads I rarely saw the issue, but over 5 I was able to reproduce roughly 50% of the time.
In debugging the issue it seems that ConfigSlurper itself is not thread-safe when used on a Class. I made a quick project that demonstrates the problem. You may need to run the test multiple times to have it fail, but eventually it will.
https://github.com/schillingr/groovy-configslurper-not-thread-safe
I solved this locally by placing a synchronized block around the ConfigurationLoader call in GebSpec which I'm running tests on now.
The text was updated successfully, but these errors were encountered: