Re: Automate Cache Flush - RANT
You obviously didn't read the text of this thread. :) Perhaps you meant to post this to the main Automate Cache Flush thread? - http://www.javasystemsolutions.com/arslist/view/89045563 What is engineering going to do to relieve the effort and time spent by your customers in managing this flush process? It is too cumbersome, slow, and painful as it stands today. Please refer to the start of this thread - Automate Cache Flush - RANT - http://www.javasystemsolutions.com/arslist/view/89045588 Regards, Andrew Goodall Software Engineer 2 | Development Services | jcpenney . www.jcp.com -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of SUBSCRIBE arslist Jimmy Wu Sent: Monday, March 05, 2012 4:36 PM To: arslist@ARSLIST.ORG Subject: Re: Automate Cache Flush - RANT Yes, Remedy eng is watching on this list. Actually it is not difficult to do the automate cache flush at all. You can create a jsp file (say flushAllCache.jsp) like below and put it in mid-tier/shared directory, then you can involve the Flush command by this dos prompt (Unix version could be different, but similar) start http://mid-tier_host:port#/arsys/shared/flushAllCache.jsp Regards, Jimmy. =flushAllCache.jsp %@ page contentType=text/html;charset=UTF-8 language=java % %@ page import=com.remedy.arsys.share.Cache % %@ page import=com.remedy.arsys.prefetch.PrefetchTask % % Cache.flush(false, null); //PluginFactory.cleanup(); PrefetchTask.schedule(PrefetchTask.PREFETCH_DELAY); //restart prefetch on cache flush % html head All Server caches flushed. /head bodytitleBMC Remedy Mid Tier - Flush Mid-Tier Cache/title/body /html ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are font face=monospacesize=-3brThe information transmitted is intended only for the person or entity to which it is addressed and brmay contain confidential and/or privileged material. If the reader of this message is not the intendedbrrecipient, you are hereby notified that your access is unauthorized, and any review, dissemination,brdistribution or copying of this message including any attachments is strictly prohibited. If you are notbrthe intended recipient, please contact the sender and delete the material from any computer.br ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Automate Cache Flush - RANT
That’s more or less the caching architecture used for the fat client.. Great thoughts nonetheless.. wonder why it wasn't extended to the thin client.. Joe -Original Message- From: John Baker Sent: Sunday, March 04, 2012 4:18 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Automate Cache Flush - RANT Andrew, I don't understand why this problem hasn't been solved either, given it's not difficult to solve. At JSS, we have to restart AR System and Mid Tier when performing webex installations of SSO Plugin, and we often spend more time waiting for AR System to restart than we do installing the product. Whilst we can't fix AR System, I did ponder how best to resolve Mid Tier's caching issues and stumbled upon a solution when I recently wrote to ARSlist suggesting workflow should be cached as flat files. Every form has a set of dependencies and a last modified time, and therefore each form should be held locally as a javascript file. Consider the home page; the Javascript on my Mid Tier is served by the following URL: http://host:8080/arsys/forms/192.168.0.54/Home+Page/Default+Admin+View/form.js/3d2a292f.js?format=html (The URL is bizarre; format=html yet the content is Javascript?) You can login to Mid Tier, go to the home page, open another tab and paste in this URL to see the JS: http://host:8080/arsys/forms/192.168.0.54/Home+Page/Default+Admin+View/form.js I've looked at the contents of my Mid Tier and I can not find this JS file, so I can only assume it's being generated on the fly and hence the workflow is being held in memory. And that seems to describe your problem: Mid Tier is loading all of ITSM into memory, which is extremely inefficient and results in huge VM sizes. The solution is remarkably simple: Build a local cache of Javascript files for each form/view as a user navigates ITSM. Once the Javascript file has been written to disc, it only needs to check the last update time on a form and associated workflow before serving the Javascript (in development mode), or simply serve it without checking for workflow changes in production. With such a small change in design, you would see the following benefits: * Instant Mid Tier start up times, no pre-caching, low memory footprint (like 256Mb VMs), much better performance, etc. * Cached Javascript could be moved from Mid Tier to Mid Tier, so your problem with 2+ Mid Tiers would go away. * Transparency. You can delete a form's Javascript confident that it has been removed from the cache (because Mid Tier would notice it wasn't there and rebuild it). * Provision for a decent debugger. If the workflow to Javascript engine is improved, so well formed and readable Javascript is written, you could attach Firebug or one of many Javascript debuggers and start debugging workflow with the same level of precision as developers using other platforms. Sure, this is possible right now, but you can't go and modify the Javascript. * Writing workflow without writing workflow: If you've got local Javascript, dab hands would be able to quickly try out changes without having to get out developer studio. When they're happy with the changes, they can enter them as normal. The irony is that BMC are 90% of the way there because they've got all the pieces of the puzzle: they just need to re-write the caching routine again to store files locally, and none of this is a terribly difficult task. John -- SSO Plugin for BMC ITSM, ITBM, Dashboards and Analytics http://www.javasystemsolutions.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Automate Cache Flush - RANT
Yes, Remedy eng is watching on this list. Actually it is not difficult to do the automate cache flush at all. You can create a jsp file (say flushAllCache.jsp) like below and put it in mid-tier/shared directory, then you can involve the Flush command by this dos prompt (Unix version could be different, but similar) start http://mid-tier_host:port#/arsys/shared/flushAllCache.jsp Regards, Jimmy. =flushAllCache.jsp %@ page contentType=text/html;charset=UTF-8 language=java % %@ page import=com.remedy.arsys.share.Cache % %@ page import=com.remedy.arsys.prefetch.PrefetchTask % % Cache.flush(false, null); //PluginFactory.cleanup(); PrefetchTask.schedule(PrefetchTask.PREFETCH_DELAY); //restart prefetch on cache flush % html head All Server caches flushed. /head bodytitleBMC Remedy Mid Tier - Flush Mid-Tier Cache/title/body /html ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Automate Cache Flush - RANT
I hope BMC is reading this! Sent from my iPad On Mar 4, 2012, at 1:18 AM, John Baker jba...@javasystemsolutions.com wrote: Andrew, I don't understand why this problem hasn't been solved either, given it's not difficult to solve. At JSS, we have to restart AR System and Mid Tier when performing webex installations of SSO Plugin, and we often spend more time waiting for AR System to restart than we do installing the product. Whilst we can't fix AR System, I did ponder how best to resolve Mid Tier's caching issues and stumbled upon a solution when I recently wrote to ARSlist suggesting workflow should be cached as flat files. Every form has a set of dependencies and a last modified time, and therefore each form should be held locally as a javascript file. Consider the home page; the Javascript on my Mid Tier is served by the following URL: http://host:8080/arsys/forms/192.168.0.54/Home+Page/Default+Admin+View/form.js/3d2a292f.js?format=html (The URL is bizarre; format=html yet the content is Javascript?) You can login to Mid Tier, go to the home page, open another tab and paste in this URL to see the JS: http://host:8080/arsys/forms/192.168.0.54/Home+Page/Default+Admin+View/form.js I've looked at the contents of my Mid Tier and I can not find this JS file, so I can only assume it's being generated on the fly and hence the workflow is being held in memory. And that seems to describe your problem: Mid Tier is loading all of ITSM into memory, which is extremely inefficient and results in huge VM sizes. The solution is remarkably simple: Build a local cache of Javascript files for each form/view as a user navigates ITSM. Once the Javascript file has been written to disc, it only needs to check the last update time on a form and associated workflow before serving the Javascript (in development mode), or simply serve it without checking for workflow changes in production. With such a small change in design, you would see the following benefits: * Instant Mid Tier start up times, no pre-caching, low memory footprint (like 256Mb VMs), much better performance, etc. * Cached Javascript could be moved from Mid Tier to Mid Tier, so your problem with 2+ Mid Tiers would go away. * Transparency. You can delete a form's Javascript confident that it has been removed from the cache (because Mid Tier would notice it wasn't there and rebuild it). * Provision for a decent debugger. If the workflow to Javascript engine is improved, so well formed and readable Javascript is written, you could attach Firebug or one of many Javascript debuggers and start debugging workflow with the same level of precision as developers using other platforms. Sure, this is possible right now, but you can't go and modify the Javascript. * Writing workflow without writing workflow: If you've got local Javascript, dab hands would be able to quickly try out changes without having to get out developer studio. When they're happy with the changes, they can enter them as normal. The irony is that BMC are 90% of the way there because they've got all the pieces of the puzzle: they just need to re-write the caching routine again to store files locally, and none of this is a terribly difficult task. John -- SSO Plugin for BMC ITSM, ITBM, Dashboards and Analytics http://www.javasystemsolutions.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.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
Re: Automate Cache Flush
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 stra...@unt.edu 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:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Friday, March 02, 2012 4:02 PM To: arslist@ARSLIST.ORG 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:arslist@ARSLIST.ORG] On Behalf Of strauss Sent: Friday, March 02, 2012 3:52 PM To: arslist@ARSLIST.ORG 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:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Friday, March 02, 2012 1:20 PM To: arslist@ARSLIST.ORG 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
Re: Automate Cache Flush
I tried that too and had a single html developed for all the servers with buttons on the html to execute it for each server.. I thought it was handy too. Something that took about 3 minutes for each server (launch the configuration login, login into the server, navigate to the caching page, cache) now takes a couple of seconds.. Happy about it too so thanks as well.. Joe From: Doug Blair Sent: Saturday, March 03, 2012 9:11 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Automate Cache Flush ** 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 stra...@unt.edu 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:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Friday, March 02, 2012 4:02 PM To: arslist@ARSLIST.ORG 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:arslist@ARSLIST.ORG] On Behalf Of strauss Sent: Friday, March 02, 2012 3:52 PM To: arslist@ARSLIST.ORG 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
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 tel:%2B61%20469747355 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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Automate Cache Flush - RANT
On a similar note... There's got to be a better design that would not need to utilize this form of caching in the first palace. We go through this nightmare everytime we deploy - it's a headache. We have 2 active mid tier servers (Windows/Tomcat) active to users. So everytime we deploy we have to disable one from the load balancer, flush cache and then wait 1 hour for it to complete the rebuild. So that's at least 2 hours of my life down the drain everytime we deploy. I already have to deploy after hours, so having to wait for the caching to complete really gets under my skin. We've found we can't leave a mid tier server active to users during the rebuild due to slowness as a result of CPU consumption for the rebuild. I hate to think what this would be like if I had more than 2 active web servers. I've seen plenty of other enterprise web apps where all you have to do is drop in the applicable objects (jsp ,jar, aspx, xml, html etc..) then you're done. That's it...why can't BMC make this process cleaner and more efficient? In my mind it would be great if the objects in Dev Studio represented as objects on the web layer that could be pushed by themselves or all as a whole. E.g. if I was making a change to HPD:Helpdesk and added an active link, then the objects at the web layer for HPD:Helpdesk and the new active link would be pushed - that's it done. Regards, Andrew Goodall Software Engineer 2 | Development Services | jcpenney . www.jcp.com http://www.jcp.com/ 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 Intervalhave had several such situations in the past, so our standing practice is to flush the web cache every time we do a deploy :-) 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 tel:%2B61%20469747355 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_ font face=monospacesize=-3brThe information transmitted is intended only for the person or entity to which it is addressed and brmay contain confidential and/or privileged material. If the reader of this message is not the intendedbrrecipient, you are hereby notified that your access is unauthorized, and any review, dissemination,brdistribution or copying of this message including any attachments is strictly prohibited. If you are notbrthe intended recipient, please contact the sender and delete the material from any computer.br ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Automate Cache Flush - RANT
The problem that I see (the reason for the re-cache) is that the item that sits in the cache is NOT a web app.they built translators to translate Remedy code into HTML/JavaScript. Because of this translation process, they either need to store a copy in a translated cache, or pull it 'on the fly'..on the fly is how it used to work, and we all complained about the speed.so they now allow for caching.but the more 'client side' objects you have, the larger the cache needs to be, and the longer it takes to cache. There are only a few things that can be done (that I can see at least) to correct this 1 - Make fewer things needing to be cached. This involves simplifying the user interface so that there aren't thousands of fields on every form, less forms, less fields, less active links 2 - Make the translation easier to perform. This would require storing the information in a different way in the DB so it required less 'change', or making the translation process more efficient so that it can do it quicker with less resources There was a 'Sync Server' option added some releases ago (don't remember what version), but this process apparently goes through and compares the cache with the server, and only modifies the structures that have been modified. This in theory would prevent the need to rebuild the entire cache, just the modified pieces, thus making #2 above true.but I've heard people having problems with it, so I don't know how well that's working I personally feel that #1 is the best option.with less objects to synchronize, less time is needed.and we all know (others better than myself) how complex ITSM is. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Andrew C Goodall Sent: Friday, March 02, 2012 8:14 AM To: arslist@ARSLIST.ORG Subject: Re: Automate Cache Flush - RANT ** On a similar note. There's got to be a better design that would not need to utilize this form of caching in the first palace. We go through this nightmare everytime we deploy - it's a headache. We have 2 active mid tier servers (Windows/Tomcat) active to users. So everytime we deploy we have to disable one from the load balancer, flush cache and then wait 1 hour for it to complete the rebuild. So that's at least 2 hours of my life down the drain everytime we deploy. I already have to deploy after hours, so having to wait for the caching to complete really gets under my skin. We've found we can't leave a mid tier server active to users during the rebuild due to slowness as a result of CPU consumption for the rebuild. I hate to think what this would be like if I had more than 2 active web servers. I've seen plenty of other enterprise web apps where all you have to do is drop in the applicable objects (jsp ,jar, aspx, xml, html etc..) then you're done. That's it.why can't BMC make this process cleaner and more efficient? In my mind it would be great if the objects in Dev Studio represented as objects on the web layer that could be pushed by themselves or all as a whole. E.g. if I was making a change to HPD:Helpdesk and added an active link, then the objects at the web layer for HPD:Helpdesk and the new active link would be pushed - that's it done. Regards, Andrew Goodall Software Engineer 2 | Development Services | jcpenney . www.jcp.com http://www.jcp.com/ _ 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
Re: Automate Cache Flush - RANT
Thanks LJ for your input. FYI - We've tried the sync but have not found it reliable. Part of the problem with the sync is that is does not easily identify to the admin the progress of the snyc and when it has completed; and don't tell me to scan the midtier or tomcat logs :-) I'll live in hope that this process is re-designed and improved in the near future. Regards, Andrew Goodall Software Engineer 2 | Development Services | jcpenney . www.jcp.com http://www.jcp.com/ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Friday, March 02, 2012 9:45 AM To: arslist@ARSLIST.ORG Subject: Re: Automate Cache Flush - RANT The problem that I see (the reason for the re-cache) is that the item that sits in the cache is NOT a web app...they built translators to translate Remedy code into HTML/JavaScript. Because of this translation process, they either need to store a copy in a translated cache, or pull it 'on the fly'on the fly is how it used to work, and we all complained about the speed...so they now allow for caching...but the more 'client side' objects you have, the larger the cache needs to be, and the longer it takes to cache. There are only a few things that can be done (that I can see at least) to correct this 1 - Make fewer things needing to be cached. This involves simplifying the user interface so that there aren't thousands of fields on every form, less forms, less fields, less active links 2 - Make the translation easier to perform. This would require storing the information in a different way in the DB so it required less 'change', or making the translation process more efficient so that it can do it quicker with less resources There was a 'Sync Server' option added some releases ago (don't remember what version), but this process apparently goes through and compares the cache with the server, and only modifies the structures that have been modified. This in theory would prevent the need to rebuild the entire cache, just the modified pieces, thus making #2 above true...but I've heard people having problems with it, so I don't know how well that's working I personally feel that #1 is the best option...with less objects to synchronize, less time is needed...and we all know (others better than myself) how complex ITSM is. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Andrew C Goodall Sent: Friday, March 02, 2012 8:14 AM To: arslist@ARSLIST.ORG Subject: Re: Automate Cache Flush - RANT ** On a similar note... There's got to be a better design that would not need to utilize this form of caching in the first palace. We go through this nightmare everytime we deploy - it's a headache. We have 2 active mid tier servers (Windows/Tomcat) active to users. So everytime we deploy we have to disable one from the load balancer, flush cache and then wait 1 hour for it to complete the rebuild. So that's at least 2 hours of my life down the drain everytime we deploy. I already have to deploy after hours, so having to wait for the caching to complete really gets under my skin. We've found we can't leave a mid tier server active to users during the rebuild due to slowness as a result of CPU consumption for the rebuild. I hate to think what this would be like if I had more than 2 active web servers. I've seen plenty of other enterprise web apps where all you have to do is drop in the applicable objects (jsp ,jar, aspx, xml, html etc..) then you're done. That's it...why can't BMC make this process cleaner and more efficient? In my mind it would be great if the objects in Dev Studio represented as objects on the web layer that could be pushed by themselves or all as a whole. E.g. if I was making a change to HPD:Helpdesk and added an active link, then the objects at the web layer for HPD:Helpdesk and the new active link would be pushed - that's it done. Regards, Andrew Goodall Software Engineer 2 | Development Services | jcpenney . www.jcp.com http://www.jcp.com/ 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 Intervalhave had several such situations in the past, so our standing practice is to flush the web cache every time we do a deploy :-) 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
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 Intervalhave had several such situations in the past, so our standing practice is to flush the web cache every time we do a deploy :) 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.ORGmailto: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.commailto: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.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of SriSamSri Appecherla Sent: Thursday, March 01, 2012 4:14 PM To: arslist@ARSLIST.ORGmailto: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 469747355tel:%2B61%20469747355 On Fri, Mar 2, 2012 at 9:51 AM, LJ LongWing lj.longw...@gmail.commailto: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.comhttp://www.wwrug.com ARSlist: Where the Answers Are_ _attend WWRUG12 www.wwrug.comhttp://www.wwrug.com ARSlist: Where the Answers Are_ _attend WWRUG12 www.wwrug.comhttp://www.wwrug.com ARSlist: Where
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
Re: Automate Cache Flush
What about if you do the Flush Cache button and then do the Sync Cache (for the server you wish to load up) button? Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of strauss Sent: Friday, March 02, 2012 11:05 AM 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 Intervalhave had several such situations in the past, so our standing practice is to flush the web cache every time we do a deploy :) 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.ORGmailto: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.commailto: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.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of SriSamSri Appecherla Sent: Thursday, March 01, 2012 4:14 PM To: arslist@ARSLIST.ORGmailto: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 469747355tel:%2B61%20469747355 On Fri, Mar 2, 2012 at 9:51 AM, LJ LongWing lj.longw...@gmail.commailto:lj.longw...@gmail.com wrote: ** I'm wanting to automate the cache flush and didn't find anything
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: straussmailto:stra...@unt.edu Sent: Friday, March 02, 2012 12:04 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORGmailto: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
Re: Automate Cache Flush
Sorry the mode swap didn’t work for you….all I know is that in one of our dev machines, we started getting thread crashes for users that weren’t even with the company any more….finally narrowed it down to that option, set it back to ‘Off’ for us and the server stopped crashing. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of strauss Sent: Friday, March 02, 2012 11:47 AM 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 mailto:stra...@unt.edu 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
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: 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
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:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Friday, March 02, 2012 1:20 PM To: arslist@ARSLIST.ORG 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: straussmailto:stra...@unt.edu Sent: Friday, March 02, 2012 1:46 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORGmailto: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.ORGmailto: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
Re: Automate Cache Flush
Are you talking of the Mid-Tier Cache? Or the AR System Cache? If you are talking of the AR System cache its possible to do that running the arsignal command with the –g option. If you are talking of the Mid-Tier cache, I do not think there is any documented method of doing it.. Joe From: LJ LongWing Sent: Thursday, March 01, 2012 5:51 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Automate Cache Flush ** 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. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Automate Cache Flush
Looking specifically for the MidTier Cache…I would like to be able to hit a URL and have it do it….all without human interaction. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Thursday, March 01, 2012 4:04 PM To: arslist@ARSLIST.ORG Subject: Re: Automate Cache Flush ** Are you talking of the Mid-Tier Cache? Or the AR System Cache? If you are talking of the AR System cache its possible to do that running the arsignal command with the –g option. If you are talking of the Mid-Tier cache, I do not think there is any documented method of doing it.. Joe From: LJ LongWing mailto:lj.longw...@gmail.com Sent: Thursday, March 01, 2012 5:51 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Automate Cache Flush ** 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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Automate Cache Flush
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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Automate Cache Flush
I’ve wondered every now and then about that too.. But have not been hard pressed for it so never really followed on to find out. Like everyone else I login into the config and do it manually. That’s the only way I believe it is done with no command line option or a url to parse that does it automatically.. I wish there was too.. If you stumble on a way to do it, I’d love to know what your resolution is... Cheers Joe From: LJ LongWing Sent: Thursday, March 01, 2012 6:25 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Automate Cache Flush ** Looking specifically for the MidTier Cache…I would like to be able to hit a URL and have it do it….all without human interaction. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Thursday, March 01, 2012 4:04 PM To: arslist@ARSLIST.ORG Subject: Re: Automate Cache Flush ** Are you talking of the Mid-Tier Cache? Or the AR System Cache? If you are talking of the AR System cache its possible to do that running the arsignal command with the –g option. If you are talking of the Mid-Tier cache, I do not think there is any documented method of doing it.. Joe From: LJ LongWing Sent: Thursday, March 01, 2012 5:51 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Automate Cache Flush ** 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. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
