Automate Cache Flush - RANT

[John Baker]

Andrew,

I don't understand why this problem hasn't been solved either, given it's not 
difficult to solve. At JSS, we have to restart AR System and Mid Tier when 
performing webex installations of SSO Plugin, and we often spend more time 
waiting for AR System to restart than we do installing the product. Whilst we 
can't fix AR System, I did ponder how best to resolve Mid Tier's caching issues 
and stumbled upon a solution when I recently wrote to ARSlist suggesting 
workflow should be cached as flat files.

Every form has a set of dependencies and a last modified time, and therefore 
each form should be held locally as a javascript file. Consider the home page; 
the Javascript on my Mid Tier is served by the following URL:

http://host:8080/arsys/forms/192.168.0.54/Home+Page/Default+Admin+View/form.js/3d2a292f.js?format=html

(The URL is bizarre; format=html yet the content is Javascript?)

You can login to Mid Tier, go to the home page, open another tab and paste in 
this URL to see the JS:

http://host:8080/arsys/forms/192.168.0.54/Home+Page/Default+Admin+View/form.js

I've looked at the contents of my Mid Tier and I can not find this JS file, so 
I can only assume it's being generated on the fly and hence the workflow is 
being held in memory. And that seems to describe your problem: Mid Tier is 
loading all of ITSM into memory, which is extremely inefficient and results in 
huge VM sizes.

The solution is remarkably simple: Build a local cache of Javascript files for 
each form/view as a user navigates ITSM. Once the Javascript file has been 
written to disc, it only needs to check the last update time on a form and 
associated workflow before serving the Javascript (in development mode), or 
simply serve it without checking for workflow changes in production.

With such a small change in design, you would see the following benefits:

* Instant Mid Tier start up times, no "pre-caching", low memory footprint (like 
256Mb VMs), much better performance, etc. 

* Cached Javascript could be moved from Mid Tier to Mid Tier, so your problem 
with 2+ Mid Tiers would go away. 

* Transparency. You can delete a form's Javascript confident that it has been 
removed from the cache (because Mid Tier would notice it wasn't there and 
rebuild it). 

* Provision for a decent debugger. If the workflow to Javascript engine is 
improved, so well formed and readable Javascript is written, you could attach 
Firebug or one of many Javascript debuggers and start debugging workflow with 
the same level of precision as developers using other platforms. Sure, this is 
possible right now, but you can't go and modify the Javascript.

* Writing workflow without writing workflow: If you've got local Javascript, 
dab hands would be able to quickly try out changes without having to get out 
developer studio. When they're happy with the changes, they can enter them as 
normal. 

The irony is that BMC are 90% of the way there because they've got all the 
pieces of the puzzle: they just need to re-write the caching routine again to 
store files locally, and none of this is a terribly difficult task.


John

-- 
SSO Plugin for BMC ITSM, ITBM, Dashboards and Analytics
http://www.javasystemsolutions.com

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"

Re: Automate Cache Flush - RANT

[Andrew C Goodall]

On a similar note...

 

There's got to be a better design that would not need to utilize this
form of caching in the first palace.

We go through this nightmare everytime we deploy - it's a headache.

 

We have 2 active mid tier servers (Windows/Tomcat) active to users. So
everytime we deploy we have to disable one from the load balancer, flush
cache and then wait 1 hour for it to complete the rebuild. So that's at
least 2 hours of my life down the drain everytime we deploy.

I already have to deploy after hours, so having to wait for the caching
to complete really gets under my skin.

We've found we can't leave a mid tier server active to users during the
rebuild due to slowness as a result of CPU consumption for the rebuild.
I hate to think what this would be like if I had more than 2 active web
servers.

 

I've seen plenty of other enterprise web apps where all you have to do
is drop in the applicable objects (jsp ,jar, aspx, xml, html etc..) then
you're done. That's it...why can't BMC make this process cleaner and
more efficient?

 

In my mind it would be great if the objects in Dev Studio represented as
objects on the web layer that could be pushed by themselves or all as a
whole. E.g. if I was making a change to HPD:Helpdesk and added an active
link, then the objects at the web layer for HPD:Helpdesk and the new
active link would be pushed - that's it done.

 

Regards,

 

Andrew Goodall

Software Engineer 2 | Development Services |  jcpenney . www.jcp.com
  



From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
Sent: Friday, March 02, 2012 8:06 AM
To: arslist@ARSLIST.ORG
Subject: Re: Automate Cache Flush

 

I had one of my servers that was restored from production, and 2 days
later, some form changes we had made in the release were still not
sync'd on that server...a quick flush of the cache made everything
right...so there is obviously something not working properly in the
Check Intervalhave had several such situations in the past, so our
standing practice is to flush the web cache every time we do a deploy
:-)

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of SriSamSri Appecherla
Sent: Thursday, March 01, 2012 5:13 PM
To: arslist@ARSLIST.ORG
Subject: Re: Automate Cache Flush

 

** 

LJ,

 

Automatic flush based on Definition Change Check Interval parameter
works well for me :)


Regards,
SriSamSri Appecherla
Mobile# +61 469747355

On Fri, Mar 2, 2012 at 10:29 AM, LJ LongWing 
wrote:

** 

Yes, but anyone that has worked with the product for a sufficiently long
time knows that doesn't work properly.  I have a migration process that
I fire and when the process is over, I want it to automatically flush
the cache on the configured web servers.

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of SriSamSri Appecherla
Sent: Thursday, March 01, 2012 4:14 PM


To: arslist@ARSLIST.ORG
Subject: Re: Automate Cache Flush

 

** 

 

Hi LJ,

 

The cache is automatically flushed based on Definition Change Check
Interval  parameter in the mid tier config page under Cache Settings.


Regards,
SriSamSri Appecherla
Mobile# +61 469747355  

On Fri, Mar 2, 2012 at 9:51 AM, LJ LongWing 
wrote:

** 

I'm wanting to automate the cache flush and didn't find anything in the
manuals about how to go about automating it...any suggestions are
appreciated. 

_attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_


_attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ 

_attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_


_attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ 

_attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_
The information transmitted is intended 
only for the person or entity to which it is addressed and may contain 
confidential and/or privileged material. If the reader of this message is not 
the intendedrecipient, you are hereby notified that your access is 
unauthorized, and any review, dissemination,distribution or copying of this 
message including any attachments is strictly prohibited. If you are notthe 
intended recipient, please contact the sender and delete the material from any 
computer.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"

Re: Automate Cache Flush - RANT

[LJ LongWing]

The problem that I see (the reason for the re-cache) is that the item that
sits in the cache is NOT a web app.they built translators to translate
Remedy code into HTML/JavaScript.  Because of this translation process, they
either need to store a copy in a translated cache, or pull it 'on the
fly'..on the fly is how it used to work, and we all complained about the
speed.so they now allow for caching.but the more 'client side' objects you
have, the larger the cache needs to be, and the longer it takes to cache.

 

There are only a few things that can be done (that I can see at least) to
correct this

 

1 - Make fewer things needing to be cached.  This involves simplifying the
user interface so that there aren't thousands of fields on every form, less
forms, less fields, less active links

2 - Make the translation easier to perform.  This would require storing the
information in a different way in the DB so it required less 'change', or
making the translation process more efficient so that it can do it quicker
with less resources

 

There was a 'Sync Server' option added some releases ago (don't remember
what version), but this process apparently goes through and compares the
cache with the server, and only modifies the structures that have been
modified.  This in theory would prevent the need to rebuild the entire
cache, just the modified pieces, thus making #2 above true.but I've heard
people having problems with it, so I don't know how well that's working

 

I personally feel that #1 is the best option.with less objects to
synchronize, less time is needed.and we all know (others better than myself)
how complex ITSM is.

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Andrew C Goodall
Sent: Friday, March 02, 2012 8:14 AM
To: arslist@ARSLIST.ORG
Subject: Re: Automate Cache Flush - RANT

 

** 

On a similar note.

 

There's got to be a better design that would not need to utilize this form
of caching in the first palace.

We go through this nightmare everytime we deploy - it's a headache.

 

We have 2 active mid tier servers (Windows/Tomcat) active to users. So
everytime we deploy we have to disable one from the load balancer, flush
cache and then wait 1 hour for it to complete the rebuild. So that's at
least 2 hours of my life down the drain everytime we deploy.

I already have to deploy after hours, so having to wait for the caching to
complete really gets under my skin.

We've found we can't leave a mid tier server active to users during the
rebuild due to slowness as a result of CPU consumption for the rebuild. I
hate to think what this would be like if I had more than 2 active web
servers.

 

I've seen plenty of other enterprise web apps where all you have to do is
drop in the applicable objects (jsp ,jar, aspx, xml, html etc..) then you're
done. That's it.why can't BMC make this process cleaner and more efficient?

 

In my mind it would be great if the objects in Dev Studio represented as
objects on the web layer that could be pushed by themselves or all as a
whole. E.g. if I was making a change to HPD:Helpdesk and added an active
link, then the objects at the web layer for HPD:Helpdesk and the new active
link would be pushed - that's it done.

 

Regards,

 

Andrew Goodall

Software Engineer 2 | Development Services |  jcpenney . www.jcp.com
<http://www.jcp.com/>   

  _  

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
Sent: Friday, March 02, 2012 8:06 AM
To: arslist@ARSLIST.ORG
Subject: Re: Automate Cache Flush

 

I had one of my servers that was restored from production, and 2 days later,
some form changes we had made in the release were still not sync'd on that
server.a quick flush of the cache made everything right.so there is
obviously something not working properly in the Check Interval..have had
several such situations in the past, so our standing practice is to flush
the web cache every time we do a deploy J

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of SriSamSri Appecherla
Sent: Thursday, March 01, 2012 5:13 PM
To: arslist@ARSLIST.ORG
Subject: Re: Automate Cache Flush

 

** 

LJ,

 

Automatic flush based on Definition Change Check Interval parameter works
well for me :)


Regards,
SriSamSri Appecherla
Mobile# +61 469747355

On Fri, Mar 2, 2012 at 10:29 AM, LJ LongWing  wrote:

** 

Yes, but anyone that has worked with the product for a sufficiently long
time knows that doesn't work properly.  I have a migration process that I
fire and when the process is over, I want it to automatically flush the
cache on the configured web servers.

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of SriSamSri Appecherla
Sent: Thursday, March 01, 2012 4:1

Re: Automate Cache Flush - RANT

[Andrew C Goodall]

Thanks LJ for your input. 

 

FYI - We've tried the sync but have not found it reliable. Part of the
problem with the sync is that is does not easily identify to the admin
the progress of the snyc and when it has completed; and don't tell me to
scan the midtier or tomcat logs :-)

 

I'll live in hope that this process is re-designed and improved in the
near future.

 

Regards,

 

Andrew Goodall

Software Engineer 2 | Development Services |  jcpenney . www.jcp.com
<http://www.jcp.com/> 



From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
Sent: Friday, March 02, 2012 9:45 AM
To: arslist@ARSLIST.ORG
Subject: Re: Automate Cache Flush - RANT

 

The problem that I see (the reason for the re-cache) is that the item
that sits in the cache is NOT a web app...they built translators to
translate Remedy code into HTML/JavaScript.  Because of this translation
process, they either need to store a copy in a translated cache, or pull
it 'on the fly'on the fly is how it used to work, and we all
complained about the speed...so they now allow for caching...but the
more 'client side' objects you have, the larger the cache needs to be,
and the longer it takes to cache.

 

There are only a few things that can be done (that I can see at least)
to correct this

 

1 - Make fewer things needing to be cached.  This involves simplifying
the user interface so that there aren't thousands of fields on every
form, less forms, less fields, less active links

2 - Make the translation easier to perform.  This would require storing
the information in a different way in the DB so it required less
'change', or making the translation process more efficient so that it
can do it quicker with less resources

 

There was a 'Sync Server' option added some releases ago (don't remember
what version), but this process apparently goes through and compares the
cache with the server, and only modifies the structures that have been
modified.  This in theory would prevent the need to rebuild the entire
cache, just the modified pieces, thus making #2 above true...but I've
heard people having problems with it, so I don't know how well that's
working

 

I personally feel that #1 is the best option...with less objects to
synchronize, less time is needed...and we all know (others better than
myself) how complex ITSM is.

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Andrew C Goodall
Sent: Friday, March 02, 2012 8:14 AM
To: arslist@ARSLIST.ORG
Subject: Re: Automate Cache Flush - RANT

 

** 

On a similar note...

 

There's got to be a better design that would not need to utilize this
form of caching in the first palace.

We go through this nightmare everytime we deploy - it's a headache.

 

We have 2 active mid tier servers (Windows/Tomcat) active to users. So
everytime we deploy we have to disable one from the load balancer, flush
cache and then wait 1 hour for it to complete the rebuild. So that's at
least 2 hours of my life down the drain everytime we deploy.

I already have to deploy after hours, so having to wait for the caching
to complete really gets under my skin.

We've found we can't leave a mid tier server active to users during the
rebuild due to slowness as a result of CPU consumption for the rebuild.
I hate to think what this would be like if I had more than 2 active web
servers.

 

I've seen plenty of other enterprise web apps where all you have to do
is drop in the applicable objects (jsp ,jar, aspx, xml, html etc..) then
you're done. That's it...why can't BMC make this process cleaner and
more efficient?

 

In my mind it would be great if the objects in Dev Studio represented as
objects on the web layer that could be pushed by themselves or all as a
whole. E.g. if I was making a change to HPD:Helpdesk and added an active
link, then the objects at the web layer for HPD:Helpdesk and the new
active link would be pushed - that's it done.

 

Regards,

 

Andrew Goodall

Software Engineer 2 | Development Services |  jcpenney . www.jcp.com
<http://www.jcp.com/>  



From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
Sent: Friday, March 02, 2012 8:06 AM
To: arslist@ARSLIST.ORG
Subject: Re: Automate Cache Flush

 

I had one of my servers that was restored from production, and 2 days
later, some form changes we had made in the release were still not
sync'd on that server...a quick flush of the cache made everything
right...so there is obviously something not working properly in the
Check Intervalhave had several such situations in the past, so our
standing practice is to flush the web cache every time we do a deploy
:-)

 

From: Action Request System dis

Re: Automate Cache Flush - RANT

[Joel Atwood]

I hope BMC is reading this!

Sent from my iPad

On Mar 4, 2012, at 1:18 AM, John Baker  wrote:

> Andrew,
> 
> I don't understand why this problem hasn't been solved either, given it's not 
> difficult to solve. At JSS, we have to restart AR System and Mid Tier when 
> performing webex installations of SSO Plugin, and we often spend more time 
> waiting for AR System to restart than we do installing the product. Whilst we 
> can't fix AR System, I did ponder how best to resolve Mid Tier's caching 
> issues and stumbled upon a solution when I recently wrote to ARSlist 
> suggesting workflow should be cached as flat files.
> 
> Every form has a set of dependencies and a last modified time, and therefore 
> each form should be held locally as a javascript file. Consider the home 
> page; the Javascript on my Mid Tier is served by the following URL:
> 
> http://host:8080/arsys/forms/192.168.0.54/Home+Page/Default+Admin+View/form.js/3d2a292f.js?format=html
> 
> (The URL is bizarre; format=html yet the content is Javascript?)
> 
> You can login to Mid Tier, go to the home page, open another tab and paste in 
> this URL to see the JS:
> 
> http://host:8080/arsys/forms/192.168.0.54/Home+Page/Default+Admin+View/form.js
> 
> I've looked at the contents of my Mid Tier and I can not find this JS file, 
> so I can only assume it's being generated on the fly and hence the workflow 
> is being held in memory. And that seems to describe your problem: Mid Tier is 
> loading all of ITSM into memory, which is extremely inefficient and results 
> in huge VM sizes.
> 
> The solution is remarkably simple: Build a local cache of Javascript files 
> for each form/view as a user navigates ITSM. Once the Javascript file has 
> been written to disc, it only needs to check the last update time on a form 
> and associated workflow before serving the Javascript (in development mode), 
> or simply serve it without checking for workflow changes in production.
> 
> With such a small change in design, you would see the following benefits:
> 
> * Instant Mid Tier start up times, no "pre-caching", low memory footprint 
> (like 256Mb VMs), much better performance, etc. 
> 
> * Cached Javascript could be moved from Mid Tier to Mid Tier, so your problem 
> with 2+ Mid Tiers would go away. 
> 
> * Transparency. You can delete a form's Javascript confident that it has been 
> removed from the cache (because Mid Tier would notice it wasn't there and 
> rebuild it). 
> 
> * Provision for a decent debugger. If the workflow to Javascript engine is 
> improved, so well formed and readable Javascript is written, you could attach 
> Firebug or one of many Javascript debuggers and start debugging workflow with 
> the same level of precision as developers using other platforms. Sure, this 
> is possible right now, but you can't go and modify the Javascript.
> 
> * Writing workflow without writing workflow: If you've got local Javascript, 
> dab hands would be able to quickly try out changes without having to get out 
> developer studio. When they're happy with the changes, they can enter them as 
> normal. 
> 
> The irony is that BMC are 90% of the way there because they've got all the 
> pieces of the puzzle: they just need to re-write the caching routine again to 
> store files locally, and none of this is a terribly difficult task.
> 
> 
> John
> 
> -- 
> SSO Plugin for BMC ITSM, ITBM, Dashboards and Analytics
> http://www.javasystemsolutions.com
> 
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"

Re: Automate Cache Flush - RANT

[Joe Martin D'Souza]

That’s more or less the caching architecture used for the fat client.. Great 
thoughts nonetheless.. wonder why it wasn't extended to the thin client..


Joe

-Original Message- 
From: John Baker
Sent: Sunday, March 04, 2012 4:18 AM Newsgroups: 
public.remedy.arsystem.general

To: arslist@ARSLIST.ORG
Subject: Automate Cache Flush - RANT

Andrew,

I don't understand why this problem hasn't been solved either, given it's 
not difficult to solve. At JSS, we have to restart AR System and Mid Tier 
when performing webex installations of SSO Plugin, and we often spend more 
time waiting for AR System to restart than we do installing the product. 
Whilst we can't fix AR System, I did ponder how best to resolve Mid Tier's 
caching issues and stumbled upon a solution when I recently wrote to ARSlist 
suggesting workflow should be cached as flat files.


Every form has a set of dependencies and a last modified time, and therefore 
each form should be held locally as a javascript file. Consider the home 
page; the Javascript on my Mid Tier is served by the following URL:


http://host:8080/arsys/forms/192.168.0.54/Home+Page/Default+Admin+View/form.js/3d2a292f.js?format=html

(The URL is bizarre; format=html yet the content is Javascript?)

You can login to Mid Tier, go to the home page, open another tab and paste 
in this URL to see the JS:


http://host:8080/arsys/forms/192.168.0.54/Home+Page/Default+Admin+View/form.js

I've looked at the contents of my Mid Tier and I can not find this JS file, 
so I can only assume it's being generated on the fly and hence the workflow 
is being held in memory. And that seems to describe your problem: Mid Tier 
is loading all of ITSM into memory, which is extremely inefficient and 
results in huge VM sizes.


The solution is remarkably simple: Build a local cache of Javascript files 
for each form/view as a user navigates ITSM. Once the Javascript file has 
been written to disc, it only needs to check the last update time on a form 
and associated workflow before serving the Javascript (in development mode), 
or simply serve it without checking for workflow changes in production.


With such a small change in design, you would see the following benefits:

* Instant Mid Tier start up times, no "pre-caching", low memory footprint 
(like 256Mb VMs), much better performance, etc.


* Cached Javascript could be moved from Mid Tier to Mid Tier, so your 
problem with 2+ Mid Tiers would go away.


* Transparency. You can delete a form's Javascript confident that it has 
been removed from the cache (because Mid Tier would notice it wasn't there 
and rebuild it).


* Provision for a decent debugger. If the workflow to Javascript engine is 
improved, so well formed and readable Javascript is written, you could 
attach Firebug or one of many Javascript debuggers and start debugging 
workflow with the same level of precision as developers using other 
platforms. Sure, this is possible right now, but you can't go and modify the 
Javascript.


* Writing workflow without writing workflow: If you've got local Javascript, 
dab hands would be able to quickly try out changes without having to get out 
developer studio. When they're happy with the changes, they can enter them 
as normal.


The irony is that BMC are 90% of the way there because they've got all the 
pieces of the puzzle: they just need to re-write the caching routine again 
to store files locally, and none of this is a terribly difficult task.



John

--
SSO Plugin for BMC ITSM, ITBM, Dashboards and Analytics
http://www.javasystemsolutions.com 


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"

Re: Automate Cache Flush - RANT

[SUBSCRIBE arslist Jimmy Wu]

Yes, Remedy eng is watching on this list.
Actually it is not difficult to do the automate cache flush at all. You can 
create a jsp file (say flushAllCache.jsp) like below and put it in 
/shared directory, then you can involve the "Flush" command by this 
dos prompt (Unix version could be different, but similar)

start "" "http://:/arsys/shared/flushAllCache.jsp

Regards,

Jimmy.

=flushAllCache.jsp

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ page import="com.remedy.arsys.share.Cache" %>
<%@ page import="com.remedy.arsys.prefetch.PrefetchTask" %>
<%
Cache.flush(false, null);
//PluginFactory.cleanup();
PrefetchTask.schedule(PrefetchTask.PREFETCH_DELAY); //restart prefetch on 
cache flush
%>


All Server caches flushed.

  BMC Remedy Mid Tier - Flush Mid-Tier Cache


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"

Re: Automate Cache Flush - RANT

[Andrew C Goodall]

You obviously didn't read the text of this thread. :) 
Perhaps you meant to post this to the main "Automate Cache Flush"
thread? - http://www.javasystemsolutions.com/arslist/view/89045563

What is engineering going to do to relieve the effort and time spent by
your customers in managing this flush process? It is too cumbersome,
slow, and painful as it stands today.

Please refer to the start of this thread - "Automate Cache Flush - RANT"
- http://www.javasystemsolutions.com/arslist/view/89045588


Regards,
 
Andrew Goodall
Software Engineer 2 | Development Services |  jcpenney . www.jcp.com  

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of SUBSCRIBE arslist Jimmy Wu
Sent: Monday, March 05, 2012 4:36 PM
To: arslist@ARSLIST.ORG
Subject: Re: Automate Cache Flush - RANT

Yes, Remedy eng is watching on this list.
Actually it is not difficult to do the automate cache flush at all. You
can create a jsp file (say flushAllCache.jsp) like below and put it in
/shared directory, then you can involve the "Flush" command by
this dos prompt (Unix version could be different, but similar)

start "" "http://:/arsys/shared/flushAllCache.jsp

Regards,

Jimmy.

=flushAllCache.jsp

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ page import="com.remedy.arsys.share.Cache" %>
<%@ page import="com.remedy.arsys.prefetch.PrefetchTask" %>
<%
Cache.flush(false, null);
//PluginFactory.cleanup();
PrefetchTask.schedule(PrefetchTask.PREFETCH_DELAY); //restart
prefetch on cache flush
%>


All Server caches flushed.

  BMC Remedy Mid Tier - Flush Mid-Tier Cache



___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
The information transmitted is intended 
only for the person or entity to which it is addressed and may contain 
confidential and/or privileged material. If the reader of this message is not 
the intendedrecipient, you are hereby notified that your access is 
unauthorized, and any review, dissemination,distribution or copying of this 
message including any attachments is strictly prohibited. If you are notthe 
intended recipient, please contact the sender and delete the material from any 
computer.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"