D
dbeavon
Guest
That is an interesting KB. Thanks for pointing it out. Its odd that parsing XML would have a concurrency problem. I guess you need to be careful when picking your third-party libraries (... says the person who pulls dependencies from very questionable nuget packages 
I like the part that describes what's wrong (ie. the "XML/ICU transcoder"). It sounds like they stole that from the star-trek technobabble generator: Star Trek Technobabble How *many* concurrent XML requests are you making before you are impacted? We do quite a bit of work with XML and I had not noticed this (or at least, not as much as some of our other bottlenecks). Does it cause a problem when reading XML from under five ABL sessions per process? The reason I'm asking is because it seems to me that limiting the number of threads per msagent is reasonable . (Or at least I'd say the default configuration was EXTREMELY unrealistic... I believe they were originally allowing !200! concurrent ABL sessions per msagent process.) If it isn't the third-party XML library, then you might still end up hitting a different type of in-process bottleneck. For example we were having trouble with concurrent use of the CLR bridge, and they can't blame any third-party for that (... there are no bugs in Microsoft's .Net framework! ;-) Another workaround that comes to mind is that you could use your ABL code in PASOE to launch the "_progres -b" for the sake of the XML alone. You'd pass it the xml via the temp directory or something like that Then you would have the entire process all to yourself while reading the XML. It sounds like the XML part of your workload is a big enough thing that it may warrant an out-of-process solution. Ie. the overhead of launching independent processes may be small relative to how long it takes to process the XML. (I don't know if there are legal/licensing consequences for starting a _progres session from a PASOE server. That was a question I had posted a few weeks , but I think it might be better to ask a Progress salesrep .)
Continue reading...
I like the part that describes what's wrong (ie. the "XML/ICU transcoder"). It sounds like they stole that from the star-trek technobabble generator: Star Trek Technobabble How *many* concurrent XML requests are you making before you are impacted? We do quite a bit of work with XML and I had not noticed this (or at least, not as much as some of our other bottlenecks). Does it cause a problem when reading XML from under five ABL sessions per process? The reason I'm asking is because it seems to me that limiting the number of threads per msagent is reasonable . (Or at least I'd say the default configuration was EXTREMELY unrealistic... I believe they were originally allowing !200! concurrent ABL sessions per msagent process.) If it isn't the third-party XML library, then you might still end up hitting a different type of in-process bottleneck. For example we were having trouble with concurrent use of the CLR bridge, and they can't blame any third-party for that (... there are no bugs in Microsoft's .Net framework! ;-) Another workaround that comes to mind is that you could use your ABL code in PASOE to launch the "_progres -b" for the sake of the XML alone. You'd pass it the xml via the temp directory or something like that Then you would have the entire process all to yourself while reading the XML. It sounds like the XML part of your workload is a big enough thing that it may warrant an out-of-process solution. Ie. the overhead of launching independent processes may be small relative to how long it takes to process the XML. (I don't know if there are legal/licensing consequences for starting a _progres session from a PASOE server. That was a question I had posted a few weeks , but I think it might be better to ask a Progress salesrep .)Continue reading...