With the current state of mid-tier, the pre-fetch is only "necessary" if you
don't want your first Incident Management user to experience a 1.5 MINUTE delay
waiting for the console to load for the first time. The same applies to any
other module, so I consider a full pre-fetch of all of the installed apps, as
best as I can design it in the xml file, to be a _requirement_ for any
production 7.x server running ITSM 7. I only clear the cache and restart to
force a pre-fetch when I have migrated new fields or active links into
production, and only during maintenance periods since having a live user
working in mid-tier during the 24 minute pre-fetch seems to result in a lower
quality cache file (I have no empirical proof of that - just a queasy feeling).
I do not allow the mid-tier to sense updates and change the cache - in my
experience through 7.1 patch 002 that would dump the entire pre-fetch and my
boss would get to see the 1.5 minute delay the next morning, first thing. I
don't know if that has been fixed in a later patch, but the post 002 patches
have been so buggy that I have avoided them. Patch 005 is in pre-release - I'm
being told that it fixes a problem with sensing a form change falsely that I am
seeing with the TMS:Task form right now ("A form definition has been changed,
so unable to retrieve data. Please contact administrator (ARERR 9352)") - so I
will have to consider deploying it once it is released.
BTW, have you put in an enhancement request for mid-tier cache file sharing in
a clustered environment? That sounds like what you are looking for, and is
exactly the sort of thing you should be able to do when clustering. Right now
we have no control at all over where the cache file(s) get stored. Since I
only have one mid-tier, I have no experience with the issues you get into once
you cluster. We are designed to limit dependencies rather than to scale for
higher loads, so putting my mid-tiers behind a university F5 (which have a
history of failing at inopportune times) doesn't make my services more
reliable, it just introduces another break point for them to fail that is
beyond my control.
Christopher Strauss, Ph.D.
Call Tracking Administration Manager
University of North Texas Computing & IT Center
http://itsm.unt.edu/
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
> Sent: Wednesday, September 24, 2008 12:12 PM
> To: [email protected]
> Subject: Re: Remedy mid-tier precache XML code
>
> Chris,
>
> Exactly. The Mid-Tier would not need to go get the objects (again) on
> startup. ( So what value would the prefetch really have at that
> point?)
>
> I would also note that to my knowledge when you choose to "flush the
> cache" (which is unfortunately needed some times) then the persistent
> cache is "wiped clean" and the prefetch is NOT used to get it back to
> a "starting point" either. You have to stop the Mid-Tier and start it
> to trigger the prefetch stuff.
>
> So if prefetch is only used on startup, and a persistent cache trumps
> fetching all those objects again then I just do not see the usefulness
> of the prefetch. I guess it might help after you flush the cache and
> restart the Mid-Tier. ( However that has for a long time felt more
> like a workaround to various bugs in the Mid-Tier than a standard
> practice that we should be doing. )
>
> In my shiny (dream) universe....
>
> I tend to think that it would be "better" if the Mid-Tier(s) could
> talk to each other and propagate changes to their caches between
> themselves. So when the first Mid-Tier sees that "Object X" changed it
> warns the others in the cluster, gets the new def, fixes it's cache
> and then "shares" it's cache with the other Mid-tiers. ( You know,
> like the Admin thread does for the worker threads in the AR System
> server.)
> ) The load on the ARS server(s) is lower on NodeN startup conditions
> from Mid-Tiers and the user experience might be more consistent.
> ) Dealing with self caching clusters where one of the nodes is
> "stuck with a bad cache" can be difficult to identify in the first
> place. Example: Some users see the field, others do not. Heck, even
> knowing which Mid-tier the user was using behind the load balancer can
> be an adventure if your not doing Mid-Tier logging and grepping
> through those files.
> ) No "Prefetch" is needed. The first Mid-Tier to start up uses it's
> persistent cache, if any, and the next Mid-tier get's a copy of the
> then current cache from the first one. (Already updated based based on
> user activity.)
>
> But maybe it is just me...
>
> --
> Carey Matthew Black
> Remedy Skilled Professional (RSP)
> ARS = Action Request System(Remedy)
>
> Love, then teach
> Solution = People + Process + Tools
> Fast, Accurate, Cheap.... Pick two.
>
>
>
>
> On Wed, Sep 24, 2008 at 12:36 PM, strauss <[EMAIL PROTECTED]> wrote:
> > My understanding is that the persistence (which finally actually
> worked in 7.1.00.002) is the feature whereby the pre-fetched cache (and
> possibly plus anything fetched after that - I'm not sure of that) is
> retained in a file so that if you restart tomcat (or it crashes and
> restarts), the persistent cache file is re-read in less than one minute
> as opposed to the 24 minutes that it normally takes to build it from
> scratch on my system.
> >
> > Christopher Strauss, Ph.D.
> > Call Tracking Administration Manager
> > University of North Texas Computing & IT Center
> > http://itsm.unt.edu/
> >
> >> -----Original Message-----
> >> From: Action Request System discussion list(ARSList)
> >> [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
> >> Sent: Wednesday, September 24, 2008 11:04 AM
> >> To: [email protected]
> >> Subject: Re: Remedy mid-tier precache XML code
> >>
> >> All,
> >>
> >> In general, I thought the general idea of a "prefetch" was eclipsed
> by
> >> the idea of a persistent cache that was only updated as needed? You
> >> know like what the User Tool is designed to do.(Starting in v7.1 of
> >> the Mid-Tier.)
> >>
> >> Or am I mixing metaphor here?
> >>
> >> I personally dislike the idea that when a Mid-Tier (or AR Server)
> >> starts up it has to "suck down" all of this application definition.
> It
> >> seems to me that in a cluster configuration that behavior can lead
> to
> >> some DB performance issues if you have enough nodes starting up at
> the
> >> same time. (And thus effect existing nodes and users that are not
> >> currently starting up.)
> >>
> >> --
> >> Carey Matthew Black
> >> Remedy Skilled Professional (RSP)
> >> ARS = Action Request System(Remedy)
> >>
> >> Love, then teach
> >> Solution = People + Process + Tools
> >> Fast, Accurate, Cheap.... Pick two.
> >>
> >>
> >>
> >> On Wed, Sep 24, 2008 at 11:50 AM, Axton <[EMAIL PROTECTED]>
> wrote:
> >> > What would be nice would be if the mid-tier kept a count of the
> >> > forms/number of times accessed by various 'group sets', then gave
> the
> >> > option to automatically generate/update the prefetch xml file
> based
> >> on
> >> > the stored data. Would be even nicer if there were a knob to
> enable
> >> > the automatic update of the prefetch xml file based on the stored
> >> data
> >> > on a periodic basis, say when the servlet container was stopped.
> May
> >> > be too progressive an idea though.
> >> >
> >> > Axton Grams
> >>
> >>
> _______________________________________________________________________
> >> ________
> >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> >> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> >
> >
> _______________________________________________________________________
> ________
> > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> > Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> >
>
> _______________________________________________________________________
> ________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
