Dr Strauss et al, I tried a version of Thilio's JavaScript / HTML buttons against 7.6.4.02 (our midtiers are on Windows VM's, AR servers on Solaris) and the cache flushed AND rebuilt. All the cache files went to zero length, and filled up again with no external connects. Have not tested with SP3 yet.
While the cache is reloading a user request will cause and non-yet-cached objects to be fetched from the AR server as needed. A little slower for the unlucky first requester, but reasonably responsive. Handy little function, Thilio! Thank you! Doug -- Doug Blair +1 224-558-5462 Sent from my iPad2 Auto-corrected typos, misspellings and non-sequiturs are gratefully attributed to Steve Jobs :-) On Mar 2, 2012, at 4:16 PM, strauss <[email protected]> wrote: > ** > Maybe – per all of the latest best practices for 7.6.x mid-tier documents I > only check Pre-Load for the initial startup, since it maxes out the web > server for 30 minutes and puts some load on the AR server (less than 7.1 > did). When the pre-load completes, I un-check the box. I have not tried a > Sync with it checked. > > I just noticed another cute SP3 feature; if you pre-load the mid-tier and > then un-check pre-load, and then restart Tomcat, then login again to the > Configuration Tool, the Cache shows object counts of ZERO even though all of > the \cache files are still present (all 1.03 gb of them). When you log into > the mid-tier normally and open the Incident Console, the object count of > cached objects goes up by ONLY the form(s) you have accessed since the > restart. Open an incident and the go up some more. Opening consoles and > forms is noticeable slower than before the Tomcat restart but is still > acceptable (10 sec versus 3 sec for Incident Console, 8 sec versus 1 sec for > Incident). > > I tried what you said – turn Pre-Load back on for the server, then Sync, and > nothing changes. No form fields are added until you actually go “touch” the > form in a mid-tier session. > > TOTALLY different behavior than SP1. > > Christopher Strauss, Ph.D. > Call Tracking Administration Manager > University of North Texas Computing & IT Center > http://itsm.unt.edu/ > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Grooms, Frederick W > Sent: Friday, March 02, 2012 4:02 PM > To: [email protected] > Subject: Re: Automate Cache Flush > > ** > I just thought of something … Is your Server set for Pre-Load in the AR > Server settings page of the Mid-Tier config (maybe it needs it for the Sync > button to work)? > > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of strauss > Sent: Friday, March 02, 2012 3:52 PM > To: [email protected] > Subject: Re: Automate Cache Flush > > ** > Testing now with all 7.6.04.0300 components – if I flush the cache on the > mid-tier it does NOT trigger a prefetch. It sits there with most of the > \cache files at zero length until you log in to the mid-tier. From login > until the Incident Management Console appears (our home page) is over 2 > minutes (normally 3 seconds on a freshly pre-loaded mid-tier). Cache files > like Form fields.data which usually sit at around 600 mb after a pre-load, > are only at 67 mb. Clearly not everything has been returned to the cache > like it used to be on Sp1. Loading an Incident from the console was about 3 > minutes (normally about 1 second!!). I guess it’s time to go back to the old > prefetch_config.xml file to kick-start the system after moving from SP1 to > SP3!? > > The only thing Sync Cache appears to do is check the validity/currency of the > existing cached data, which if zeroed out by a flush, remains at zero. The > file Form fields.data was not updated by a Sync (about half of the files – > the small ones and Sync*.* ones, were updated). On another SP3 mid-tier that > had been sitting for a day or so, Sync made NO CHANGE to ANY file in the > \cache. > > BTW, thanks for the javascript Bill – it works just fine on 7.6.04 mid-tiers > where login.jsp is slightly more parameterized: > > <input name="<%=Params.USERNAME%>" maxlength="<%=Params.USERNAME_LENGTH%>" > id="username-id" value="<%=com.remedy.arsys.share.HTMLWriter.escape(name)%>" > onChange="javascript:this.value=this.value.toLowerCase();" class="loginfield" > size="30" type="text"> > > Christopher Strauss, Ph.D. > Call Tracking Administration Manager > University of North Texas Computing & IT Center > http://itsm.unt.edu/ > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Joe Martin D'Souza > Sent: Friday, March 02, 2012 1:20 PM > To: [email protected] > Subject: Re: Automate Cache Flush > > ** > I was used to seeing the prefetch trigger immediately too which led me to > think that there is a problem the first time I noticed it on 7.6.03. But then > when I noticed I could log into the MT I attributed it to some sort of a (for > better or worse) new design maybe.. > > Just for kicks I flushed our development cache at 2:09:20 EST and its already > 2:15:XX EST and the only items that got an Object Count relatively quick, is > the ActorViews and ActorViewsMapping with values 15 and 13 respectively.. > > Now its about 2:18:XX EST and I saw the first signs of Active Links, Field > maps, Forms, Form fields, Form images etc. being populated.. That was > probably when a user logged in.. > > I did a test just before lunch where it was all on 0’s for over 30 minutes.. > > Joe > > > From: strauss > Sent: Friday, March 02, 2012 1:46 PM > Newsgroups: public.remedy.arsystem.general > To: [email protected] > Subject: Re: Automate Cache Flush > > ** > I don’t remember that from 7.6.03, but it’s been over a year since I was > testing that version. I am used to seeing (on MANY 7.6.04.01 mid-tiers) the > flush cache actually trigger the prefetch (like the dialog box says it will) > on a server that has any cache already – usually from a preload. It looks > like now (7.6.04.03) you have to preload again after the flush to get it to > go, or log in as a user and only get a partial prefetch pertinent to that > user. No, clicking on Sync after Flush had no effect. > > BTW, changing the 'Authentication Chaining Mode' to Off does NOT stop the > thread deaths on the AR Server (and yes I restarted the AR server just in > case), but it adds an entirely new dysfunctional family of ERROR (623) > Authentication Failed errors to the mid-tier logs for the improper user name, > as well as a lot of RPC timeout errors. While this is going on, the mid-tier > is unusable. It was so bad on the last two tests that I finally stopped the > tomcat. > > BTW, the only way I have seen to clear out the improper form login names from > a mid-tier (the Jsmith versus jsmith variety) is to remove that server > completely from the server list, then add it back. When LDAP lets Jsmith log > in, it permanently poisons the cache. > > I’m not getting anywhere with the SP3 mid-tier and SP1 AR Server, so I will > switch over to a complete SP3 environment and do the same sort of testing. > > Christopher Strauss, Ph.D. > Call Tracking Administration Manager > University of North Texas Computing & IT Center > http://itsm.unt.edu/ > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Joe Martin D'Souza > Sent: Friday, March 02, 2012 11:47 AM > To: [email protected] > Subject: Re: Automate Cache Flush > > ** > I noticed that in 7.6.03 too – for some reason the customer I am at is using > 7.6.03 despite the general BMC Support advise not to stay there and move up > to 7.6.04. It’s a project they wish to embark on later. > > Anyways the cache items sit at 0 until a user logs in even if that means a > user may or may not log in for an hour... I could run a quick test again to > verify it.. > > Joe > > From: strauss > Sent: Friday, March 02, 2012 12:04 PM > Newsgroups: public.remedy.arsystem.general > To: [email protected] > Subject: Re: Automate Cache Flush > > ** > It looks like something changed in 7.6.04 SP3 – now when you click Flush > Cache it does zero out all of the files in the \cache folder like SP1, but it > no longer starts an immediate, complete prefetch – just sits there with > nothing in the cache. It did not prefetch until I tried to log in as support > staff to that mid-tier, at which point the user gets a spinner for several > minutes and the mid-tier finally BEGINS to prefetch the cache from persistent > file. Subsequent actions like opening an Incident from the console trigger > additional prefetch activity – while the user watches the stupid “Loading” > spinner. And this is somehow an improvement?.....NOT! The entire point of > preloading and prefetching is so that the users NEVER see a delay in loading > forms in the mid-tier. Now I REALLY don’t know what settings to use on the > mid-tier caching. > > I am going to test your note about 'Authentication Chaining Mode' = off as > well. We have used that set to ARS – AREA since version 5.1.2 (2003) and 7.1 > (2008) and used it on 7.6.04 in 2011 and knew of no reason to change it. > Someone in support mentioned that to me last month (setting it to off), but I > blew it off because he was also telling me that our LDAP server shouldn’t > have whitespace in the name of a path (Directory Users) that has existed in > LDAP since it was installed (Novell Identity Manager – in production since at > least 2002). > > 5. I have noticed that LDAP Authentication doesn't work if we have given any > WHITESPACE in AREA-LDAP entries in ar.cfg file. Though you have not given any > WHITESPACE in AREA-LDAP entries, but unfortunately we have one WHITESPACE in > below entry (ou=Directory Users). > AREA-LDAP-Bind-User: uid=<username>,ou=Directory Users,o=unt It might be > single structure name on LDAP Server, but while defining the same structure > name in ar.cfg file, unfortunately a single WHITESPACE comes. > To avoid this issue, kindly rename the structure name on LDAP Server so that > it does not contain any WHITESPACE. > > Somehow I don’t think our directory services people are going to change their > decade old LDAP server configuration, which they tell me meets normal LDAP > standards, just because BMC has figured out how to choke on it. They > actually laughed at the comment. > > Back to testing… if the 'Authentication Chaining Mode' setting is actually > the problem now, with 7.6.04 mid-tiers, then I don’t expect that applying SP3 > is going to have anything to do with correcting it. > > Christopher Strauss, Ph.D. > Call Tracking Administration Manager > University of North Texas Computing & IT Center > http://itsm.unt.edu/ > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of LJ LongWing > Sent: Friday, March 02, 2012 8:06 AM > To: [email protected] > Subject: Re: Automate Cache Flush > > ** > I had one of my servers that was restored from production, and 2 days later, > some form changes we had made in the release were still not sync’d on that > server…a quick flush of the cache made everything right…so there is obviously > something not working properly in the Check Interval….have had several such > situations in the past, so our standing practice is to flush the web cache > every time we do a deploy J > > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of SriSamSri Appecherla > Sent: Thursday, March 01, 2012 5:13 PM > To: [email protected] > Subject: Re: Automate Cache Flush > > ** > LJ, > > Automatic flush based on Definition Change Check Interval parameter works > well for me :) > > Regards, > SriSamSri Appecherla > Mobile# +61 469747355 > > On Fri, Mar 2, 2012 at 10:29 AM, LJ LongWing <[email protected]> wrote: > ** > Yes, but anyone that has worked with the product for a sufficiently long time > knows that doesn’t work properly. I have a migration process that I fire and > when the process is over, I want it to automatically flush the cache on the > configured web servers. > > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of SriSamSri Appecherla > Sent: Thursday, March 01, 2012 4:14 PM > > To: [email protected] > Subject: Re: Automate Cache Flush > > ** > > Hi LJ, > > The cache is automatically flushed based on Definition Change Check Interval > parameter in the mid tier config page under Cache Settings. > > Regards, > SriSamSri Appecherla > Mobile# +61 469747355 > > On Fri, Mar 2, 2012 at 9:51 AM, LJ LongWing <[email protected]> wrote: > ** > I’m wanting to automate the cache flush and didn’t find anything in the > manuals about how to go about automating it…any suggestions are appreciated. > > > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
