Re: RE: Citrix activConsole.exe Memory errors
Hi John
ok - first of all - you had a Technology Audit from the Software company ? Nothing wrong with the fox guarding the chickens....
Now, as for your issue - and everyone elses issue with Citrix / Terminal Server Invalid Overwrite or Read Errors - this should explain why this is happening.
First of all, OneWorld Client was designed from the beginning to be a single-user program - it was not designed to have TAM files being shared (hence why JDE is so scared over users running toolset on the Citrix Servers) - and it was only B732 when the jdecache hierachial caching system came into effect (ie use of cursors, in a similar vein to how databases work). However, a lot of issues have been assosiated with jdecache - and, as usual, the application developers often do not follow the rules that the toolset developers set down. Hence, often you see a lot of "memory leaks" because the application developer forgot to close the cache correctly.
Now, JDE uses memory like any other program, but the JDECache routines are locating memory on the client session and are requesting areas in memory so they can populate it with data etc. The same occurs with any type of JDE Variable.
However, occassionally if a user opens up many copies of the SAME APPLICATION - and if there is sufficient enough of a DELAY, then the application will mistakenly provide the same memory address to two different requesting processes inside the same session.
This happens on ALL client types - FAT or Citrix/TSE - butit is usually far more pronounced an issue with a terminal server under large load - mainly because there is a high enough utilization of memory for the terminal server to provide a higher delay between the memory request and consequent write.
Because almost all memory writes are keyed by application name - this will only happen if the user opens, for example, P4210 twice. It is possible for business functions underneath two different applications to perform the same issue - because business functions are shared between applications - but the key is to try and REDUCE the times that this might occur rather than eliminate it entirely (which would require a full rewrite of Oneworld memory foundation code).
It is my experience that the following helps :
1. Up to date code, which will usually eliminate some bad application coding to do with cache (The most common SARs are centered on cache and memory issues). Updates and Upgrades help - as do some Service Packs - I noted at a recent customer that SP20 significantly reduced the number of issues as opposed to SP19.1
2. Faster Architecture Design - using 2700DDR memory in your architecture would actually help far more than 60ns DIMM memory ! Of course, this is important only at the time that you need to renew your citrix farm. One customer I have replaced 50 Dual Xeon 550 MHz terminal servers with 1GHz PIII processor powered machines - same number - and the number of issues became significantly lower.
3. Map Master Business Functions to the server - this only helps because the Application Server architecture IS designed to be "pseudo" multi-user through its messaging layer - and also significantly less processes running in parallel on a powerful application server helps here. I've never seen this issue on a Unix box or an AS400 ! However, I understand if you do NOT map business functions - since JDE have still yet to come up with the CORRECT mapping set (ie - DEFAULT BSFN APPSVR). I would therefore NOT do this just because it "seems" to help
4. Educate users to NOT run multiple versions of the same application. If a user is still processing an EndDoc() through P4210 - starting up a second version of P4210 to enter another order is NOT going to help the stability - cache memory can easily be shared without the user knowing. This is the most important factor in reducing the error - by educating the user, you'll significantly reduce the number of issues.
Lastly, if a user gets one Invalid Overwrite or Read error - they need to close their SESSION - ie LOG OUT of Citrix and restart, since it is often the case that the error will return if that memory address is allocated again.
Hope this helps !
