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]> 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]] On Behalf Of Dave Barber > Sent: Friday, March 31, 2017 8:08 AM > To: [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]> > > 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] 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] http://rrr.se > > > March 31, 2017 12:24 PM, "Dave Barber" <[email protected] > <mailto:%22dave%20barber%22%20%[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 www.arslist.org > "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"
