Hello, Susan: The JSS SSO Plugin records user access including client type, browser, remote IP, and length of session time.
More generally, every six months or so, I tend to add my two pence to the current Mid Tier cache thread, which is that the current cache model is not optimum. This is how I think it currently works: 1. Workflow (forms, active links etc) is loaded into local caches within Mid Tier using ehcache (google). It is persisted on disk and also loaded into memory. 2. When a request is made to load a form, HTML and accompanying Javascript is generated each time from the cached objects. There are a number of problems with this approach, not least that loading workflow into memory as Java objects is incredibly memory and CPU intensive, hence why Mid Tier and ITSM requires huge heap sizes and some Mid Tiers can take minutes to start. Also doing it each time Mid Tier starts means there's excessive consumption of AR System resources, in particular when people "flush the cache" rather than picking off workflow related to a particular form. The output of this process is an HTML and Javascript file, and hence there is a better way: 1. User makes request for /arsys/forms/appserver/Form. 2. Mid Tier requries the Javascript file to drive the workflow. Therefore, it looks for a file called appserver-Form.js n disk and serves if present. 3. If not, it walks the Form for all related workflow using a workflow analyser, loads from AR System and creates the Javascript file. Some will be cached, lots will be thrown away. 4. Mid Tier serves newly created Javascript file. 5. Workflow can be held in memory or ejected at this point. Most will not be needed again. (Repeat for local cached HTML.) There are of course some complications, ie some workflow will require loading on demand, but this avoids gigabytes of it being loaded into memory and converted into Javascript on every access to a form. On subsequent requests, Mid Tier is doing little more than serving the HTML and Javascript from local cached files, which incidentally, can easily be deleted by the administrator There are also other benefits. This is how 'developer' mode works: 1. User makes request for /arsys/forms/appserver/Form. 2. Mid Tier checks last modified timestamp on appserver-Form.js. 3. If timestamp different to the timestamp cached with appserver-Form.js then it deletes appserver-Form.js and re-creates. If not, file is served. So even the overhead of running in a "always rebuild if changed" mode is only a dent on performance. There's good news! I've mostly hacked up a solution to the above, but there's some Mid Tier internal code I can't access/modify. However, if I can sit down and make a reasonable attempt at resolving the problem in a few hours, surely someone in BMC could create a proof of concept for 'community testing'? If someone at BMC wishes to work with me to resolve it, I'm happy to do the coding for free :) John -- JSS SSO Plugin for the BMC product set http://www.javasystemsolutions.com/jss/ssoplugin _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
