Hi, a follow-up question on this old thread: Would you all consider exporting a def file from a production system something that should be done in a change window? Are there risks or possible performance issues associated with this?
Thanks, David Durling University of Georgia > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing > Sent: Wednesday, April 04, 2012 1:23 PM > To: arslist@ARSLIST.ORG > Subject: Re: Production changes (spin-off of RE: Effects of flushing midtier > cache) > > I'm not intimately familiar with what adding groups, regardless of the usage > of the group, does....but it's my understanding that it causes some sort of > re- > caching to happen at the server level > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of David Durling > Sent: Wednesday, April 04, 2012 10:57 AM > To: arslist@ARSLIST.ORG > Subject: Re: Production changes (spin-off of RE: Effects of flushing midtier > cache) > > LJ, > > Thanks for your response. How about adding groups that aren't used for > permissions (except dynamically in field 112 or dynamic group fields)? Even > adding a notification group should be considered an off-hours change? > > Thanks, > > David > > David Durling > University of Georgia > > > -----Original Message----- > > From: Action Request System discussion list(ARSList) > > [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing > > Sent: Monday, April 02, 2012 12:54 PM > > To: arslist@ARSLIST.ORG > > Subject: Re: Production changes (spin-off of RE: Effects of flushing > midtier > > cache) > > > > David, > > In general, I have always considered making changes in production to > > be either a scheduled situation, or an emergency thing. Any change > > going to production needs to first be developed in Dev, moved to Test > > via standard procedures, tested in test to ensure the functionality is > > working properly....then moved to Prod in the same manner it was moved > > to Test....so this essentially means that you are never using Dev > > Studio in Test/Prod with exception of importing already developed > > stuff. Adding users is standard operating procedures....but adding > > groups should not be > as > > that causes re-caching of stuff on the server as well...it's almost > analogous to > > doing code changes (but not 100% the same). > > > > -----Original Message----- > > From: Action Request System discussion list(ARSList) > > [mailto:arslist@ARSLIST.ORG] On Behalf Of David Durling > > Sent: Monday, March 26, 2012 2:58 PM > > To: arslist@ARSLIST.ORG > > 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:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza > > > Sent: Monday, March 26, 2012 4:19 PM > > > To: arslist@ARSLIST.ORG > > > 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: arslist@ARSLIST.ORG > > > 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 durl...@uga.edu > > 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" > > __________________________________________________________ > __________________ > ___ > 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" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
