Thanks, Joe & Chris & Andrew (& others) - Except for the mid-tier flush - which I'm not sure about in all my users' cases, I'm pretty sure my users don't experience outages from these changes in general. We are well under 100 logged-in users at any given time.
In addition to performance issues during changes, I was also thinking in terms of what could go wrong. Years ago, for instance, on ARS 4.x, I remember some operation wrecked access to one of our major Remedy forms where a fellow had to go into sqlplus or something and rename a T-table in order to recover the form. And of course a change could be implemented that simply doesn't work properly because of not being tested first. That's the kind of thing I'm most concerned with - something unexpected that actually breaks functionality or disrupts user sessions, not so much things that seem to cause a (in my case small) slowness in performance. I do appreciate the comments on standard practices. Thanks! David > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Joe Martin D'Souza > Sent: Monday, March 26, 2012 5:20 PM > To: [email protected] > Subject: Re: Production changes (spin-off of RE: Effects of flushing midtier > cache) > > I hit the send button too early.. > > Changes to Filters & Filter Guides, Escalations would not impact the mid-tier > server in any way.. They would however impact the caching of the AR Server > itself.. which could again have an impact on the usability of the AR Server > which the mid tier is connected to... Think of it like a train with two > cars.. if > the first one is moving smoothly but the second hits its brakes, it could > impact the first car too although it has not hit any brakes.. > > Changes to Forms, Active Links, Menus, Active Link Guides, Web Services, > Flashboard objects, adding new Permission Groups or changing their existing > type would impact both the AR Server and the Mid-Tier. (Both cars having > their brakes pressed..) > > Data loads to group form should be avoided if you can. Group caching can > impact both the AR Server and the Mid-Tier as it would need to be cached if > the group added is a permission group. > > So yes it is standard not to promote anything to production from the dev or > test environment to production during production hours. > > Again - the bottom-line is, you are the best judge to know if it would be OK > for your users to face a little outage.. > > -----Original Message----- > From: David Durling > Sent: Monday, March 26, 2012 4:58 PM Newsgroups: > public.remedy.arsystem.general > To: [email protected] > Subject: Production changes (spin-off of RE: Effects of flushing midtier > cache) > > Joe brought up an issue I already had questions relating to, being: what > workflow IS okay to change on a production AR server during production > hours? > > For instance, if I have an app on a production box that is being tested by > users and is not itself "production", am I endangering other things on > production by making changes to it during production hours? (Besides > flushing the mid tier cache, that is.) > > Or do people have categories of changes - like rewording text in an email > filter or on a form, or adding an item to a character menu - that they > consider > have an acceptable level of risk to do during normal hours? Or is it standard > to just not touch anything with Developer Studio unless it's an emergency or > a change window? > > Related question: Are updating groups or using the Data Import tool (on a > reasonable, limited basis) considered normal production procedures? > > Thanks for any insights on this, > > David > > David Durling > University of Georgia > > > -----Original Message----- > > From: Action Request System discussion list(ARSList) > > [mailto:[email protected]] On Behalf Of Joe Martin D'Souza > > Sent: Monday, March 26, 2012 4:19 PM > > To: [email protected] > > Subject: Re: Effects of flushing midtier cache > > > > When would you need to flush cache? The obvious answer is when there > > is a workflow change on production.. Changes to workflow are done > > whenever there is need for code change for enhancement or bug fixes.. > > The general industry practice is to manage these changes in a change > > window, where there is a scheduled outage, which is typically > > scheduled on weekends or the least productive hours of an > > organization. So cache should be flushed during these changes. > > > > That being said, there may be emergency changes that were a result of > > a part or whole system being rendered unusable pending that change. On > > such an event it would be ok to flush your cache after fixing whatever > > the problem/bug/enhancement was. > > > > Yes flushing cache during production hours may cause a brief negative > > impact on users using the system at the time of the change. > > > > Joe > > > > -----Original Message----- > > From: David Durling > > Sent: Monday, March 26, 2012 3:48 PM Newsgroups: > > public.remedy.arsystem.general > > To: [email protected] > > Subject: Effects of flushing midtier cache > > > > Hi, > > > > I'm one of those that has found it necessary to use the "flush cache" > > button > > in the mid tier config when sometimes certain changes aren't picked up > > at the regular cache check interval. > > > > Do you all consider a flush of the mid tier cache to be unintrusive - > > something that can be done during production hours? Or is it > > something that should be done off-hours? > > > > On our server I don't notice performance issues in using it, and in > > what little testing I've done, user sessions seem to be uninterrupted. > > (I'm not sure about floating users on the web, though - if there's > > anything to consider > > there.) > > > > I'm on ARS 7.5 patch 007 with mid tier 7.5 patch 007 with apache/tomcat. > > > > Thanks, > > > > David > > > > --- > David Durling [email protected] > Enterprise IT Services 706-542-0223 > University of Georgia > > __________________________________________________________ > _____________________ > 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"
