D
dbeavon
Guest
Thanks Evan. I appreciate this summarization of the support case. It is helpful for others to hear it straight from Progress, if they ever encounter this. I do understand the larger points related to the difficulties supporting multiple OS'es, the need to invest your resources wisely, the fact that this is not a recent regression, and especially the explanation that customers should wean themselves away from risky compilation in production. (We especially appreciate the last point, and that is why we very do large, concurrent compilations of our ABL code as part of an automated build ... the place where we encountered this concurrency problem to begin with). I know you did spend a lot of time on this issue for me and I appreciate it, especially given the fact that it probably impacts customers infrequently. I do have a few comments. First of all we assume that this is an infrequent issue, but I would submit that we don't know how exactly often this issue bites your customers. Many of them may still be compiling r-code directly into their production PROPATH's. The issue causes the AVM-hosting process to unexpectedly crash. There is not really an approachable error message (like "your session failed because of partially compiled code".) If there were better errors/symptoms from the AVM then a customer might use that to open support cases. And you might hear from customers a lot more than you do. As it is now, I would suspect that most customers flail about, recompile, restart, and the problem randomly goes away. They shrug and move on. My next comment is that it should be clearly defined how this stuff is supposed to work in the first place. If you don't define the "right" behavior then of course you can argue that all is well no matter how they work. IE. If things behave one way in UNIX then that is what is "right" for UNIX. If it behaves a totally different way on Windows then that is "right" for Windows. I'm reminded of programming-by-coincidence (see Programming by Coincidence | The Pragmatic Bookshelf ) ... Fred doesn’t know why the code is failing because he didn’t know why it worked in the first place. It seemed to work, given the limited “testing” that Fred did, but that was just a coincidence. Finally, my last comment is that you should probably clearly state in the documentation of the COMPILE statement that it isn't fully supported when performed in production (where a PROPATH is shared by active sessions). There should be a LARGE warning about how it creates risks for other sessions - risks that are created by the behavior of the Progress runtime itself, and they go beyond the changing of custom method signatures in ABL. I suspect it won't stop anyone from doing what they are doing, but at least they'll know it isn't advisable. Thanks again for spending time on this. I think I can do some things to work around the issue for now.
Continue reading...
Continue reading...