We tried an ARSignal about 2 months ago and took our entire production suite down for a solid 30 minutes.
With load balanced front ends, we've just found it much easier / safer to restart AR services once we determine a filter, active link, or form modification needs to be pushed out to our users. And yes, 9.1 restarts are horribly slow compared to 7.6.04. What used to take us 1 hour for monthly server maintenance takes 2 or more hours now. Ridiculous. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Dave Barber Sent: Friday, March 31, 2017 9:20 AM To: [email protected] Subject: Re: [Non-DoD Source] Re: Code sync/timing issues? ** Ryan, I'm intrigued by the "unintended consequences" of running arsignal. Rebooting the two servers wouldn't take long (although restart of services is way slower on 9.1 compared to our old 7.6 instances), but would mean that what was previously a minor code change potentially becomes a loss of resilience or an outage. Regards Dave On 31 March 2017 at 13:42, Nicosia, Ryan J. CTR USSOCOM HQ <[email protected] <mailto:[email protected]> > wrote: You can run arsignal but there are usually unintended consequences for users who are connected so I would advise against it. In our experience, the only sure way to get updates from primary admin server to the rest of the servers in the server group is to cycle AR services on those servers. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected] <mailto:[email protected]> ] On Behalf Of Dave Barber Sent: Friday, March 31, 2017 8:08 AM To: [email protected] <mailto:[email protected]> Subject: [Non-DoD Source] Re: Code sync/timing issues? ** Misi, I thought it worth mentioning about the client just in case there were any questions; overall these new servers run well .... until we make code changes. At which point we have a variably long wait before the changes are available to users. One of my colleagues was wondering if there is some arsignal option that can be manually triggered for force the other servers to re-cache. Regards Dave On 31 March 2017 at 11:40, Misi Mladoniczky <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]> > > wrote: ** Hi, Sounds like something is seriously wrong... Mid-Tier has nothing to do with it, as it is a client. Filters are run on the server. I presume that the admin server should signal the other servers to re-cache as soon as the change has been committed to the DB. Best Regards - Misi, RRR AB, [CAUTION] [CAUTION] http://www.rrr.se (ARSList MVP 2011) Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13) * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs Find these products, and many free tools and utilities, at [CAUTION] [CAUTION] http://rrr.se March 31, 2017 12:24 PM, "Dave Barber" <[email protected] <mailto:[email protected]> <mailto:%22dave%20barber%22%20%[email protected] <mailto:22dave%2520barber%2522%2520%[email protected]> %3E> > wrote: ** All, 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) Regards 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_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at [CAUTION] www.arslist.org "Where the Answers Are, and have been for 20 years" _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
