D
dbeavon
Guest
We are predominantly using Windows infrastructure. I'm waiting for PASOE docker containers to come to Windows. I'm very eager for that. I think the hold-up is that Progress still needs to certify PASOE on "windows core". Here are the discussions and the KB: community.progress.com/.../36953 community.progress.com/.../38719 community.progress.com/.../37317 knowledgebase.progress.com/.../000041790 Alternatively we could probably use LCOW or something like that for hosting PASOE by itself in a Linux OS which is dedicated to PASOE: docs.microsoft.com/.../linux-containers But we'd lose quite a lot if we ever had to move PASOE over to Linux. On Windows we can use the "CLR bridge" and this essentially gives us most of the libraries/packages that we need in the .Net ecosystem. It all works in-process within the msagents and is very fast. We use it for REST, LDAP, FTP, Newtonsoft JSON, XML DOM, XPATH queries, ODBC queries, emailing, system.diagnostics.process, and much more! The syntax for using the CLR bridge takes a bit of effort, but the functionality is what matters. Before moving to Windows from HPUX, many of these types of things had to somehow funnel thru OS-COMMAND or UNIX or whatever. That approach leaves a lot to be desired. Back to the memory issues.... Given the continual growth of memory, I think it is safe to say that the _mproapsv's would eventually crash one way or the other. Nobody lives forever. If we simply used an external task to kill them the _mproapsv's after they reached 5 GB then that would also solve the problem too! (And more importantly prevent a system-wide emergency.) PASOE seems pretty resilient to the death of its msagents. The only problem is the possibility that there will be sessions that are active at the moment of death. The related PASOE clients would receive an unfriendly communication failure and the database transactions would be rolled back. To avoid that problem we could take that server out of the load-balancer ("gracefully") and wait for the activity to subside before killing the _mproapsv. We've discussed the use of load-balancers, scheduled tasks, docker, and kubernetes, and/or manual intervention. This is all a bit overkill for solving this simple problem. PASOE itself could very easily mark the msagent process with a "contaminated" / "do-not-use" flag - and then launch another new process in the ABL application to take over for the future client requests. Once the msagents with the "contaminated" flag had only IDLE sessions in them ... then PASOE could finally kill those process, (in a way that is similar to what it does with the "resource timeout" that it has today.)
Continue reading...
Continue reading...