[Date Prev] [Date Next] [Prev in Thread] [Next in Thread] [Date Index] [Thread Index]

Re: Code sync/timing issues?

Hi Abhijit,

That isn't in the ar.conf file, so it should be picking up the default value?  Interesting that it doesn't seem to be reliably working.  I will discuss with my colleagues.



On 3 April 2017 at 04:34, Abhijit Hendre <abhihendre@gmail.com> wrote:
Could you please check below parameter in ar.cfg or are.conf


It's description per BMC docs is as below -

Number of seconds before the latest cache is made available to all threads. 
Valid values: 0 to 3600 seconds. If this option is set to 0, 
every API call gets the latest cache (that is, the cache is copied for every administrator call). 
Setting the option to 0 causes slower performance for cache operations.

The default value is 5 seconds. The recommended value is 300 (5 minutes).

On 31-Mar-2017 3:56 PM, "Dave Barber" <daddy.barber@gmail.com> wrote:

We've recently moved our in-house applications from Remedy 7.6 (running on Solaris/Oracle - 2 user facing servers, with one of those handling admin functions) to Remedy 9.1.02 (running on RHL/Oracle - 2 x user facing servers, 1 x admin/integration server).

On the "old" servers, we never had any issues with code sync - amend a filter, and it was pretty much updated on both production servers right away.

On the new servers, we're experiencing inconsistent delays - amend a filter on the admin/integration server, and it can be anything up to 90 minutes before that filter update is reflected on the other two production servers.  Similar issues have been experienced on forms too.

The application is not (yet) updated for the mid-tier, so access is still via the WUT.  Any suggestions?

(We're expecting the mid-tier update to be ready later in the year)


Dave Barber
_ARSlist: "Where the Answers Are" and have been for 20 years_
_ARSlist: "Where the Answers Are" and have been for 20 years_

_ARSlist: "Where the Answers Are" and have been for 20 years_