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 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 :-) 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"_ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If the reader of this message is not the intended recipient, you are hereby notified that your access is unauthorized, and any review, dissemination, distribution or copying of this message including any attachments is strictly prohibited. If you are not the intended recipient, please contact the sender and delete the material from any computer. _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"
