Re: Production changes (spin-off of RE: Effects of flushing midtier cache)

2012-06-05 Thread David Durling
So for one of our more complicated forms, I'd probably keep exports down to < 
500 objects by exporting active links & filters separately.  Maybe that should 
do it.

Thanks,

David

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Goodall, Andrew C
Sent: Tuesday, June 05, 2012 10:24 AM
To: arslist@ARSLIST.ORG
Subject: Re: Production changes (spin-off of RE: Effects of flushing midtier 
cache)

**
Good point :)

Regards,

Andrew C. Goodall
Software Engineer
Development Services
ago...@jcpenney.com<mailto:ago...@jcpenney.com>
jcpenney
6501 Legacy Drive
Plano, TX 75024
jcp.com

From: Action Request System discussion list(ARSList) 
[mailto:arslist@arslist.org]<mailto:[mailto:arslist@arslist.org]> On Behalf Of 
Rick Cook
Sent: Tuesday, June 05, 2012 9:23 AM
To: arslist@arslist.org<mailto:arslist@arslist.org>
Subject: Re: Production changes (spin-off of RE: Effects of flushing midtier 
cache)

**

True, Andrew, but it will still be tying up the Admin thread.

Rick
On Jun 5, 2012 10:21 AM, "Goodall, Andrew C" 
mailto:ago...@jcp.com>> wrote:
Exporting - no, not to my knowledge. Ideally your admin ARS server should not 
be forward facing to end users anyway.

Regards,

Andrew C. Goodall
Software Engineer
Development Services
ago...@jcpenney.com<mailto:ago...@jcpenney.com>
jcpenney
6501 Legacy Drive
Plano, TX 75024
jcp.com<http://jcp.com>


-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@arslist.org<mailto:arslist@arslist.org>] On Behalf Of David 
Durling
Sent: Tuesday, June 05, 2012 9:18 AM
To: arslist@arslist.org<mailto:arslist@arslist.org>
Subject: Re: Production changes (spin-off of RE: Effects of flushing midtier 
cache)

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


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"


Re: Production changes (spin-off of RE: Effects of flushing midtier cache)

2012-06-05 Thread Goodall, Andrew C
Good point J

 

Regards,

 

Andrew C. Goodall

Software Engineer

Development Services

ago...@jcpenney.com

jcpenney

6501 Legacy Drive

Plano, TX 75024

jcp.com

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@arslist.org] On Behalf Of Rick Cook
Sent: Tuesday, June 05, 2012 9:23 AM
To: arslist@arslist.org
Subject: Re: Production changes (spin-off of RE: Effects of flushing
midtier cache)

 

** 

True, Andrew, but it will still be tying up the Admin thread.

Rick

On Jun 5, 2012 10:21 AM, "Goodall, Andrew C"  wrote:

Exporting - no, not to my knowledge. Ideally your admin ARS server
should not be forward facing to end users anyway.

Regards,
 
Andrew C. Goodall
Software Engineer
Development Services
ago...@jcpenney.com
jcpenney
6501 Legacy Drive
Plano, TX 75024
jcp.com


-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@arslist.org] On Behalf Of David Durling
Sent: Tuesday, June 05, 2012 9:18 AM
To: arslist@arslist.org
Subject: Re: Production changes (spin-off of RE: Effects of flushing
midtier cache)

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, doesbut 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 properlythen moved to Prod in the same manner it was
moved
> > to Testso 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 proceduresbut 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 to

Re: Production changes (spin-off of RE: Effects of flushing midtier cache)

2012-06-05 Thread Rick Cook
True, Andrew, but it will still be tying up the Admin thread.

Rick
On Jun 5, 2012 10:21 AM, "Goodall, Andrew C"  wrote:

> Exporting - no, not to my knowledge. Ideally your admin ARS server should
> not be forward facing to end users anyway.
>
> Regards,
>
> Andrew C. Goodall
> Software Engineer
> Development Services
> ago...@jcpenney.com
> jcpenney
> 6501 Legacy Drive
> Plano, TX 75024
> jcp.com
>
>
> -Original Message-
> From: Action Request System discussion list(ARSList) [mailto:
> arslist@arslist.org] On Behalf Of David Durling
> Sent: Tuesday, June 05, 2012 9:18 AM
> To: arslist@arslist.org
> Subject: Re: Production changes (spin-off of RE: Effects of flushing
> midtier cache)
>
> 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, doesbut 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 properlythen moved to Prod in the same manner it was moved
> > > to Testso 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 proceduresbut 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 -
>

Re: Production changes (spin-off of RE: Effects of flushing midtier cache)

2012-06-05 Thread Tommy Morris
I think that it is safe to do an export without a change window. You are not 
actually changing anything and the impact is tiny. That is as long as you are 
not exporting a huge application. The activity will still take some I/O so the 
larger the file the more impactful it may be depending up on your system.

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of David Durling
Sent: Tuesday, June 05, 2012 9:18 AM
To: arslist@ARSLIST.ORG
Subject: Re: Production changes (spin-off of RE: Effects of flushing midtier 
cache)

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, doesbut 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 properlythen moved to Prod in the same 
> > manner it was moved to Testso 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 
> > proceduresbut 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
> >
> 

Re: Production changes (spin-off of RE: Effects of flushing midtier cache)

2012-06-05 Thread Rick Cook
Depends on the size of the export and your system.  I would say that if it
is more than a few forms and its few hundred associated objects, a
performance hit could be noticeable.

Rick
On Jun 5, 2012 10:19 AM, "David Durling"  wrote:

> 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, doesbut 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 properlythen moved to Prod in the same manner it was moved
> > > to Testso 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 proceduresbut 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 insig

Re: Production changes (spin-off of RE: Effects of flushing midtier cache)

2012-06-05 Thread Goodall, Andrew C
Exporting - no, not to my knowledge. Ideally your admin ARS server should not 
be forward facing to end users anyway.

Regards,
 
Andrew C. Goodall
Software Engineer
Development Services
ago...@jcpenney.com
jcpenney
6501 Legacy Drive
Plano, TX 75024
jcp.com


-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@arslist.org] On Behalf Of David Durling
Sent: Tuesday, June 05, 2012 9:18 AM
To: arslist@arslist.org
Subject: Re: Production changes (spin-off of RE: Effects of flushing midtier 
cache)

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, doesbut 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 properlythen moved to Prod in the same manner it was moved
> > to Testso 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 proceduresbut 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(ARS

Re: Production changes (spin-off of RE: Effects of flushing midtier cache)

2012-06-05 Thread David Durling
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, doesbut 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 properlythen moved to Prod in the same manner it was moved
> > to Testso 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 proceduresbut 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 practic

Re: Production changes (spin-off of RE: Effects of flushing midtier cache)

2012-04-04 Thread LJ LongWing
I'm not intimately familiar with what adding groups, regardless of the usage
of the group, doesbut 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
> properlythen moved to Prod in the same manner it was moved to
> Testso 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 proceduresbut 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 fou

Re: Production changes (spin-off of RE: Effects of flushing midtier cache)

2012-04-04 Thread David Durling
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
> properlythen moved to Prod in the same manner it was moved to
> Testso 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 proceduresbut 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?
> >

Re: Production changes (spin-off of RE: Effects of flushing midtier cache)

2012-04-02 Thread LJ LongWing
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
properlythen moved to Prod in the same manner it was moved to Testso
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 proceduresbut 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"


Re: Production changes (spin-off of RE: Effects of flushing midtier cache)

2012-03-26 Thread David Durling
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:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
> Sent: Monday, March 26, 2012 5:20 PM
> To: arslist@ARSLIST.ORG
> 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: 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 

Re: Production changes (spin-off of RE: Effects of flushing midtier cache)

2012-03-26 Thread Joe Martin D'Souza

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: 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"


Re: Production changes (spin-off of RE: Effects of flushing midtier cache)

2012-03-26 Thread Joe Martin D'Souza

The short answer is none..

Anything that may cause the server to re-cache its definitions, should not 
be promoted to the production server during peak hours of usage.


But then there you might have other things to consider..

1) Have portions of the system been rendered unusable as a result of a bug 
or enhancement request?? Is it preventing majority of the users to not be 
able to perform business critical functions?
2) Will not performing the change ASAP lead you to a point where you would 
be saying yes to 1) soon enough so you want to take a preventive action??
3) How strong really is your user-base? If you have a user base of less than 
maybe 500, there may not be that much impact.


So the impact this action would make is really a combination of various 
factors which you would be a better judge than any of us here..


But if you can afford it, it’s a change best kept for the least productive 
hour of the week, and done after informing the users of potential outage 
during that window so that the few who would be on, would be aware..


Joe

-Original Message-
From: David Durling
Sent: Monday, March 26, 2012 4:58 PM Newsgroups: 
public.remedy.arsystem.general

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"


Production changes (spin-off of RE: Effects of flushing midtier cache)

2012-03-26 Thread David Durling
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"