D
dbeavon
Guest
>> What about my previous suggestion from Oct 3 2019 ? I remember reading that but was less open to the idea at the time. I had always heard that the crashing of the AVM wasn't an acceptable outcome under any circumstance, so I was fairly convinced that Progress would want to own up to this and fix it themselves. (IE I don't see why the compile of every single file shouldn't work internally like a SAVE INTO that saves to a temp file and renames it when finished. The operation should be atomic and other active clients shouldn't observe intermediate WIP outputs..) Moreover the issue is not unique to me. Progress conceded that there is a potential for this to happen any time a COMPILE w/SAVE happens in a multi-user environment. The compiling client has the potential to negatively impact the executing clients. Given that Progress is a dynamic platform, this is how many customers have always done it ("this is the way mando") and they have never told us otherwise nor given us any cautionary warnings about the unintended consequences of it. Until a few years ago we always compiled all our code in-place within our production PROPATH (not on an isolated build server as we do today.) Now that I know Progress wants me to do the heavy lifting, and work around the issue myself, I agree that SAVE INTO is a real great option. (I'm glad you reminded me because I was contemplating the use of redundant copies of our entire source from our repo). Your option lets me use a single copy of the source and compile the results to a location that is outside the PROPATH so it shouldn't cause concurrency conflicts. Unfortunately the compile operations will never take advantage of pre-compiled r-code and there will be a lot of redundant work being done, but that seems unavoidable.
Continue reading...
Continue reading...