D
dbeavon
Guest
I definitely agree with you. Did you discover the article after experiencing the performance problem first-hand? What symptoms do you see? A bunch of sessions that are stuck at the same point in the call stack for long periods of time? How many sessions? I'd like to be on the lookout for this before we get bitten ourselves. >> ... highly probable that we could have all 5 threads running READ-XML .. Yes, but still not nearly as bad as having 100 or 200 threads lining up for a chance to use that READ-XML method. We have already limited the number of ABL sessions (per _mproapsv) to 25 and maybe that is why we haven't noticed this particular bottleneck (yet). We have more _mproapsv processes running, but it seems like a fairly reasonable trade-off ... and any redundant memory usage is a fairly minor issue for us, relatively speaking. >> It seems to me that this is a bug ... I agree. The problem with performance-related bugs is how to prioritize them. I think they want us to request an "enhancement to the product" for the purpose of voting. I would definitely vote for this, but I wouldn't want the work to come in front of some other bug fixes that I'm waiting to see in OE 11.7.5. (Things that are causing programs to fail altogether). Workarounds are par for the course. XML functionality has always been limited in ABL. Eg. we still can't do basic things with XML such as an xpath search. We are very accustomed to hopping outside of our ABL code for tons of other critical functionality (sending SMTP emails, making LDAP queries, interacting with messaging brokers, and so on). This is not altogether a new problem. Do you run PASOE on linux or windows? Here is another possible workaround in the KB if you are running PASOE on windows. knowledgebase.progress.com/.../000041926 That KB article has a sample of how to use the CLR bridge and process your XML with the System.Xml namespace. Technically this is hopping outside of ABL as well, but not all the way out of the _mproapsv process. I've found that the CLR bridge takes a minimal amount of time to be initialized within a PASOE ABL session, and, afterwards, it is much faster to use these namespaces than any comparable ABL code. If you are on linux this won't be an option (then again, perhaps linux will get a .Net core bridge one day).
Continue reading...
Continue reading...