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: arslist@ARSLIST.ORG 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:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Friday, March 02, 2012 11:47 AM To: arslist@ARSLIST.ORG 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: arslist@ARSLIST.ORG 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:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Friday, March 02, 2012 8:06 AM To: arslist@ARSLIST.ORG 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:arslist@ARSLIST.ORG] On Behalf Of SriSamSri Appecherla Sent: Thursday, March 01, 2012 5:13 PM To: arslist@ARSLIST.ORG 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 <lj.longw...@gmail.com> 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:arslist@ARSLIST.ORG] On Behalf Of SriSamSri Appecherla Sent: Thursday, March 01, 2012 4:14 PM To: arslist@ARSLIST.ORG 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 <lj.longw...@gmail.com> 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"_ _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _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"