Don:
Jamie's problem is well known for long distance RPC traffic. I attended a briefing on the Riverbed traffic shaping device and RPC is very 'chatty' and the longer the connection, the longer it takes to transfer information. The ultimate solution is to not use RPC, but that is not available right now. The second solution is to force the MT server to 'pre-cache' information AFTER the cache is flushed. The way that BMC does updates is to wait until a form is requested and then send over form data from the ARS server to the MT server. This is very slow the first time a form is called for. Add a long and slow connection and this makes things much, much worse. And I agree that the method used by MT 6.3 + needs work so that the system will update whenever a form is changed, not wait for a user to call for the form.
James McKenzie
L-3 GSI
________________________________
From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Don McClure
Sent: Tuesday, October 17, 2006 7:58 AM
To: [email protected]
Subject: Re: Mid Tier - Long Applet Load Time
**
Hi Jamie,
Rick Cook mentions complete new architecture; subject re-work includes a change in use of java.
Specifically, MT 5.1.2 and earlier relied on client-side java, with some JRE version-specific issues.
Example: MT 5.1.2 would not work with Java 1.5.01 mentioned in your architecture, at least in
our environment.
Last information I had on MT 6.3: MT is server-side _javascript_ only, not relying on any java at
the client at all, so the server dataflow and memory-management concerns are quite different.
Also, the 'freshness' indicator in MT is not that reliable, so MT cannot necessarily discern an
ARS-side change without that cache-flush action (forcing a retrieve of current form constructions).
HTH...
dwm
Don W. McClure, P.E.
Systems Engineer
University of North Texas
[EMAIL PROTECTED]
940.565.3287
