D
dbeavon
Guest
Another update on this topic (hopefully the final one). Our automated builds are now using the "SAVE INTO" option as suggested by @frank.meulblok. So far so good. This allows us to avoid the concurrency conflicts (... which Progress is now acknowledging in their documentation as "unpredictable behavior".) There are only two additional considerations I would mention. Firstly - none of the ABL "COMPILE" sessions will ever benefit from the R-code produced by *another* session, since the workers are all saving into their own independent directories that are specified by "SAVE INTO". This allows them to avoid concurrency conflicts, but causes the overall duration of the builds to last a bit longer. Synchronization is performed at the very end, in order to merge all the results together. Secondly it is important to note that the "SAVE INTO" option will *not* create the folder structure to receive compiled outputs when compiling P-code. But it *will* create the folder structure when compiling OOABL (ie. CLS files). This was an unfortunate "gotcha". So when we use the "SAVE INTO" option, we need to proactively create the folders that are going to receive the compiled outputs. Hopefully the gradle plugin will allow for compiling large amounts of ABL/OOABL code in parallel. Maybe they will be able to learn from this thread, and from the Progress support case as well. One important lesson we have learned is that Progress needs to test their gradle stuff on Windows as well as Linux. That will ensure that it will account for the slight differences in the way that the COMPILE statement interacts with each of the two file systems.
Continue reading...
Continue reading...