It sounds like I need to test one of my mid-tiers using the old prefetchConfig.xml technique that has worked so well for us on mid-tier 7.1 (patch 002 or later). A null password is exactly what our 263,000 customer records have to cause them to use AREA for authentication (the 300 support staff store passwords directly in ARS since they are using login IDs that exist nowhere else). Any mid-tier impersonation call with a blank password is going to trigger a lookup on LDAP using the OOTB AREA integration. It's BMC's mid-tier and BMC's AREA plugin; don't these teams ever talk to each other? We'll see what they do with the Issues I have open, as well.
Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jiri Pospisil Sent: Friday, July 15, 2011 3:52 AM To: arslist@ARSLIST.ORG Subject: Re: Possible issues with 7.6.04.01 Pre-Load Regarding your point no. 2, I have seen the same issue in our environment (though we are on 7.6.03 version), i.e. AREA plugin thread crashing when mid-tier was pre-loading its cache. The cause was user impersonation calls being issued by mid-tier as these have the password set to NULL (as oppose to something or an empty string) and our custom plugin for authentication was not able to cope with that. Had to update the custom authentication plugin code to check for NULL values in password and then all worked fine. At the end, I turned the pre-loading off as well as cache persistence. Pre-loading put so much load on the production box, that users could hardly do anything for a while. Persistent cache was getting corrupt on a regular basis and only way to rebuild it was to flush the cache and restart Tomcat. Our environment is 7.6.03 running apache/tomcat bundled with the install on MS Windows Server 2003. Hope this is of some help. Regards Jiri Pospisil LCH Clearnet -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of strauss Sent: 14 July 2011 20:02 To: arslist@ARSLIST.ORG Subject: Possible issues with 7.6.04.01 Pre-Load Just wondering what other sites working on 7.6.04.01 are seeing with regards to pre-loading in the mid-tier. Environment: mid-tier 7.6.04.01 on Tomcat 6.0.32 on JVM 1.6.0_24 x64 on Win2K3 R2 x64 - Pre-Production mid-tier has 2 quad-core i7s and 12 gb RAM and is running several ARS-related apps as well - Admin mid-tier is directly on the AR Server, which has 2 quad-core i7s and 24 gb RAM and is running several other ARS-related apps Preload is running on both mid-tiers, for FQDN on the Admin box and both FQDN and short name on the Pre-Prod box (FQDN seems to be a requirement to make the Atrium Core Console work, plus we prefer using it for DNS reasons) Two problems that we are seeing appear to be related to the Preload process and form caching: 1. Dialog boxes using Display Only Forms are VERY sluggish loading and saving. The HPD:Help Desk Dialog form takes up to a minute to open and display, and another minute to save and close (versus 8 seconds on our 7.1 mid-tier at the very worst - but on 7.0.03 it is really a view of the actual HPD:Help Desk regular form!). Opening CTM:People Search (another display only form) takes 20-30 seconds to open - enough that our support staff do not want to rely on it to search for Login Name and want me to extend that particular required customization back to HPD:Help Desk and now HPD:Help Desk Dialogs the way it is in 7.0. Most of the other dialogs opened from the Quick Actions links have the same problem - they take at least 20 or 30 seconds to load, versus response times of no greater than 8 seconds for similar functions on our 7.1 mid-tier (on MUCH older hardware). On that system, a comprehensive prefetch configuration is the key to performance. The 7.6.04.01 preload for consoles and regular forms seems to work fine, but for dialogs using display only forms it is terrible. Our support staff testing the product do not think that this is acceptable for production use. 2. Starting the tomcat (after the AR Server has started or has been running a while), triggering a preload from persistent cache, has crashed the AREA plugin thread several times now as it thrashes through all sorts of failures to prefetch on various high-use forms (including those with poor response times) on various usernames of people actively testing the system. The authentication service then remains down until ARS is restarted, effectively blocking ALL non-support staff from logging in to ITSM or Kinetic Request. Related problems?; probably. Impact?; we will not go live until they are solved. Just wondered what others were seeing out there... I have issues open on both items. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" ************************************************************************************************* This email is intended for the named recipient(s) only. Its contents are confidential and may only be retained by the named recipient(s) and may only be copied or disclosed with the consent of LCH.Clearnet Limited and/or LCH.Clearnet SA. If you are not an intended recipient please delete this e-mail and notify postmas...@lchclearnet.com. LCH.Clearnet Limited, LCH.Clearnet SA and each other member of the LCH.Clearnet Group accept no liability, including liability for negligence, in respect of any statement in this email. The contents of this email are subject to contract in all cases, and LCH.Clearnet Limited and/or LCH.Clearnet SA makes no contractual commitment save where confirmed by hard copy. Cet e-mail et toutes les pièces jointes (ci-après le "message") sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, est interdite, sauf autorisation expresse de LCH.Clearnet Limited et/ou LCH.Clearnet SA. Si ce message vous a été adressé par erreur, merci de le détruire et d'en avertir immédiatement postmas...@lchclearnet.com. LCH.Clearnet Limited, LCH.Clearnet SA et les autres entités du groupe LCH.Clearnet Group, ne peuvent en aucun cas être tenues responsables au titre de ce message à moins qu’il n’ait fait l’objet d’un contrat signé. LCH.Clearnet Limited, Registered Office: Aldgate House, 33 Aldgate High Street, London EC3N 1EA. Recognised as a Clearing House under the Financial Services & Markets Act 2000. Reg in England No.25932 Telephone: +44 20 7426 7000 Internet: http://www.lchclearnet.com LCH.Clearnet SA, Siège Social, 18 rue du Quatre Septembre, 75002 Paris, Chambre de Compensation conformément au Code Monétaire et Financier. ************************************************************************************************* _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
