The sync shouldn't have any affect on logging in. Even if the server isn't finished syncing yet the login process shouldn't care. If syncing was as hard on a system as a cache rebuild then I could see timeout issues occurring. You could probably tail the Mid Tier logs to see what is happening during a sync (depending on your logging settings). I have tailed the log when flushing cache but not syncing cache.
The only way I know of seeing if a person is using MT or WUT is either 1) using workflow to capture it (in a record) or 2) watching access logs on the web server. I guess one other kind of goofy way is to tail the aruser.log. Since 7.6.04 or so when a user is using WUT there is a ton of logins recorded vs. when a user is using MT. If you see the same person logging in every few seconds then they are using WUT. On our environment where WUT is primarily used the aruser.log grows very rapidly. I choose always allow as well for pop-up blockers. Basically you want to trust any page MT is going to throw at you. It has been so long since I have read the message that I don't even remember what it say. Clicking the always allow happens from muscle memory at this point :) Jason On Fri, Oct 11, 2013 at 7:24 AM, Susan Palmer <[email protected]> wrote: > ** > I tried sync cache last night and it seemed a bit faster but still took at > least 10-15 min. > > I have noticed that after a sync I have issues logging back into mid-tier > which I assume means the sync is not done. Is there a place to watch what > it's doing? > > Different question: Can you see who is logged on via the mid-tier as > opposed to client tool. License review just shows everyone. > > Different question: Pop-up blockers. A bit confusing, it says 'don't > have pop-ups active, then later it say it wants pop-ups. I actually had > misread the 'don't allow' message wrong initially and had chosen 'always > allow' and didn't see any ill effects of that. > > Thanks, > Susan > > > On Fri, Oct 11, 2013 at 9:12 AM, Brittain, Mark <[email protected]>wrote: > >> ** >> Sync cache is disabled/grayed out so the only option I have is Flush >> Cache. >> >> ------------------------------ >> *From:* Action Request System discussion list(ARSList) [ >> [email protected]] On Behalf Of Joe D'Souza [[email protected]] >> *Sent:* Thursday, October 10, 2013 5:13 PM >> >> *To:* [email protected] >> *Subject:* Re: Another Mid-tier cache question >> >> ** >> >> Like LJ said its best left off on production as your changes to >> Production if your company follows a proper change process is minimal. And >> you Sync the cache whenever there is a genuine change in the cache. >> >> >> >> Joe >> >> >> ------------------------------ >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> [email protected]] *On Behalf Of *ravi rai >> *Sent:* Thursday, October 10, 2013 5:07 PM >> *To:* [email protected] >> *Subject:* Re: Another Mid-tier cache question >> >> >> >> LJ, >> >> We do Quarterly releases.After each release we do manual flush Cache . >> >> Is is safe to turn this option off. >> >> It might resolve cache corruption issues which we encounter almost every >> alternate week >> >> >> >> Ravi >> >> >> ------------------------------ >> >> Date: Thu, 10 Oct 2013 14:57:48 -0600 >> From: [email protected] >> Subject: Re: Another Mid-tier cache question >> To: [email protected] >> >> ** >> >> Mark, >> >> I agree with Joe....but look at it this way....this check box tells the >> Mid-Tier server to periodically check your Remedy server for definition >> changes. How often are definition changes made in your production >> server?....Weekly? Monthly? Quarterly? You likely don't need an >> automated 'check' to be turned on in production as it doesn't change very >> often...and when it does, you can manually hit the 'sync' button. >> >> >> >> Regarding the app server being behind a load balancer...no, that won't >> affect things because regardless of which app node the mid-tier gets the >> cache from, it should be 'correct' :) >> >> >> >> On Thu, Oct 10, 2013 at 2:45 PM, Joe D'Souza <[email protected]> wrote: >> >> ** >> >> I won’t pretend to answer this question for you – but this is my guess.. >> >> >> >> From what it looks like, this functionality performs a periodic check on >> the AR Server, to check for changes in definitions, and collects that >> information. This will in my opinion have some impact on performance. >> >> >> >> So as long as that interval is relatively high, and set in such a way >> that it occurs in periodic cycles when users are usually not online, it >> should be fine. My guess is that when this box is checked and the interval >> is defined, there is probably a definition check that happens that instant, >> followed next by the interval that is defined. So if this is done lets say >> at 11:00 PM when most users are usually offline in that time zone, and the >> interval is set for 86400 for the next check to happen at 11:00 PM the next >> night, you might not have too much to worry about. >> >> >> >> I would however not be comfortable doing it every few minutes, as it MAY >> impact the performance of that particular mid-tier server in that load >> balanced configuration.. >> >> >> >> Cheers >> >> >> >> Joe >> ------------------------------ >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> [email protected]] *On Behalf Of *Brittain, Mark >> *Sent:* Thursday, October 10, 2013 4:34 PM >> *To:* [email protected] >> *Subject:* Another Mid-tier cache question >> >> >> >> Hi All, >> >> >> >> Is it safe to use Definition Change Check (Peform Check) with load >> balancers? When the dev and production ITSM servers were installed Perform >> Check was no selected. Don't know why it was done that way. >> >> >> >> Later when I applied a patch to the mid-tier servers, BMC Support said I >> should select Perform Check. I did this on the development server which has >> one ar server, one mid-tier and no load balancers, but did >> not select Perform Check on production which is a VIP > load balanced to >> two mid-tiers which are load balanced to two ars servers in a server group. >> >> >> >> Particularly with small changes I really like using change check/perform >> check on dev and would like to use on the production servers. Since I don't >> know why this was not originally set up that way I figured I would ask the >> group first. >> >> >> >> ARS 7.6.06 SP3 >> >> Mid-Tier 7.6.06 SP4 >> >> >> >> Thanks >> >> Mark >> >> _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_ >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> ------------------------------ >> This e-mail is the property of NaviSite, Inc. It is intended only for the >> person or entity to which it is addressed and may contain information that >> is privileged, confidential, or otherwise protected from disclosure. >> Distribution or copying of this e-mail, or the information contained >> herein, to anyone other than the intended recipient is prohibited. >> >> ------------------------------ >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or subject to >> copyright belonging to Time Warner Cable. This E-mail is intended solely >> for the use of the individual or entity to which it is addressed. If you >> are not the intended recipient of this E-mail, you are hereby notified that >> any dissemination, distribution, copying, or action taken in relation to >> the contents of and attachments to this E-mail is strictly prohibited and >> may be unlawful. If you have received this E-mail in error, please notify >> the sender immediately and permanently delete the original and any copy of >> this E-mail and any printout. >> _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"
