[Dspace-tech] Do I need to remove the Cocoon cache files every time I make a change that affects the XMLUI?

Discussion:

Galewsky, Dan

2011-06-16 18:47:33 UTC

Recently I was changing the browse indices for my Dspace 1.7.2 installation in my dspace.cfg -- for example :

webui.browse.index.1 = datecreated:metadata:dc.date.created:date

The problem I ran into was that even after restarting Tomcat and my browser - my changes did not show up in the user interface.

After a bit of research I ran across an article that recommended removing the Cocoon cache files in Tomcat:

rm /usr/local/tomcat/work/Catalina/localhost/_/cache-dir/cocoon-ehcache.data
rm /usr/local/tomcat/work/Catalina/localhost/_/cache-dir/cocoon-ehcache.index

When I removed these cache files - and restarted Tomcat - the changes that I had expected to see in the UI actually showed up.

So - my question - do I need to remove these files in order for changes like this to show up?

What about if I just removed the cache files every time I restarted Tomcat - would this be a bad idea? After our Dspace is in production - Tomcat is not restarted all that often.

Thanks for any insights...

--Dan Galewsky
Texas Digital Library/University of Texas

Pottinger, Hardy J.

2011-06-16 19:30:35 UTC

Permalink

Hi, Dan, it was good to meet you at OR11. I don't know the "official"
answer to this, but I do know my "voodoo" answer is, yes, I make it a
habit to clear the Cocoon cache if I ever change anything in the XMLUI. I
do it often enough that I'd like to develop a button for the XMLUI admin
control panel so I can clear the cache, taking advantage of the native
Cocoon clearcache method, while Tomcat is up. Though, manually deleting
the files works great, and I often need to reboot Tomcat as part of the
development process anyway, so I just take a moment, while Tomcat is down,
to delete the Cocoon cache files.

Perhaps someone with a deeper understanding of Cocoon can respond with
something more nuanced than my answer. But I'd say, it can't hurt, if
you're developing using XMLUI, to empty the cache files pre-emptively.
They are, after all, just cache files, most likely in a development
environment. So, no big deal to delete 'em.

--
HARDY POTTINGER <***@umsystem.edu>
University of Missouri Library Systems
http://lso.umsystem.edu/~pottingerhj/
"No matter how far down the wrong road you've gone,
turn back." --Turkish proverb

Post by Galewsky, Dan
Recently I was changing the browse indices for my Dspace 1.7.2
webui.browse.index.1 = datecreated:metadata:dc.date.created:date
The problem I ran into was that even after restarting Tomcat and my
browser - my changes did not show up in the user interface.
After a bit of research I ran across an article that recommended removing
rm
/usr/local/tomcat/work/Catalina/localhost/_/cache-dir/cocoon-ehcache.data
rm
/usr/local/tomcat/work/Catalina/localhost/_/cache-dir/cocoon-ehcache.index
When I removed these cache files - and restarted Tomcat - the changes
that I had expected to see in the UI actually showed up.
So - my question - do I need to remove these files in order for changes
like this to show up?
What about if I just removed the cache files every time I restarted
Tomcat - would this be a bad idea? After our Dspace is in production -
Tomcat is not restarted all that often.
Thanks for any insights...
--Dan Galewsky
Texas Digital Library/University of Texas
--------------------------------------------------------------------------
----
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
DSpace-tech mailing list
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Tim Donohue

2011-06-16 21:47:34 UTC

Permalink

Hi Dan & Hardy,

There is supposedly a way to trigger Cocoon to 'clear' its cache via the
ClearCacheAction built into Cocoon. See:
http://comments.gmane.org/gmane.text.xml.cocoon.user/61537

I just tried this out locally in my XMLUI, and it *seems* to work (at
least with a few extremely simple tests I've run). But, I'll admit, this
is not well tested at all (SO, DON'T TRY THIS IN PRODUCTION, unless you
are feeling very gutsy or have verified that it is 100% working for you).

In any case, I thought I'd share this patch in case it is helpful (see
attached). Currently, it returns an ugly XML response (which is just
Cocoon's status information), but we could just as easily work this into
the XMLUI Admin Control Panel with a 'prettier' response.

This patch applies to
[dspace-src]/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/sitemap.xmap
(right now its line numbers are based on Trunk, but should work for
1.7.2 or similar)

Please let me know if this seems to work for you in your development
environments, etc. If it does seem to work well, this seems like
something we could easily add to DSpace 1.8's XMLUI Admin Control Panel.

- Tim
--
Tim Donohue
Technical Lead for DSpace Project
DuraSpace.org

Post by Pottinger, Hardy J.
Hi, Dan, it was good to meet you at OR11. I don't know the "official"
answer to this, but I do know my "voodoo" answer is, yes, I make it a
habit to clear the Cocoon cache if I ever change anything in the XMLUI. I
do it often enough that I'd like to develop a button for the XMLUI admin
control panel so I can clear the cache, taking advantage of the native
Cocoon clearcache method, while Tomcat is up. Though, manually deleting
the files works great, and I often need to reboot Tomcat as part of the
development process anyway, so I just take a moment, while Tomcat is down,
to delete the Cocoon cache files.
Perhaps someone with a deeper understanding of Cocoon can respond with
something more nuanced than my answer. But I'd say, it can't hurt, if
you're developing using XMLUI, to empty the cache files pre-emptively.
They are, after all, just cache files, most likely in a development
environment. So, no big deal to delete 'em.
--
University of Missouri Library Systems
http://lso.umsystem.edu/~pottingerhj/
"No matter how far down the wrong road you've gone,
turn back." --Turkish proverb

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
DSpace-tech mailing list
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Tim Donohue

2011-06-16 21:52:07 UTC

Permalink

Neglected to mention in my previous email:

Once you apply the previously sent patch, you should be able to clear
the Cocoon cache by visiting:

http://localhost:8080/xmlui/clearcache

Again, it will return a bunch of XML (which is Cocoon Status Info). But,
in that XML will be an section like:

<group name="VM">
<group name="...EHDefaultStore">
<value name="cached">
<line>[empty]</line>
</value>
<value name="size">
<line>0 items in cache (0 are empty)</line>
</value>
</group>
</group>

- Tim

Post by Tim Donohue
Hi Dan & Hardy,
There is supposedly a way to trigger Cocoon to 'clear' its cache via the
http://comments.gmane.org/gmane.text.xml.cocoon.user/61537
I just tried this out locally in my XMLUI, and it *seems* to work (at
least with a few extremely simple tests I've run). But, I'll admit, this
is not well tested at all (SO, DON'T TRY THIS IN PRODUCTION, unless you
are feeling very gutsy or have verified that it is 100% working for you).
In any case, I thought I'd share this patch in case it is helpful (see
attached). Currently, it returns an ugly XML response (which is just
Cocoon's status information), but we could just as easily work this into
the XMLUI Admin Control Panel with a 'prettier' response.
This patch applies to
[dspace-src]/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/sitemap.xmap
(right now its line numbers are based on Trunk, but should work for
1.7.2 or similar)
Please let me know if this seems to work for you in your development
environments, etc. If it does seem to work well, this seems like
something we could easily add to DSpace 1.8's XMLUI Admin Control Panel.
- Tim

Tim Donohue

2011-06-16 22:06:26 UTC

Permalink

Hardy & Dan,

Ok, after a bit more playing around, here's a slightly updated version
of the patch that shows it seems to be working (see attached).

This updated version adds an additional option:

http://localhost:8080/xmlui/statusinfo
-> will now show the Cocoon Status XML doc (as a "base" version, to
compare /clearcache to)

http://localhost:8080/xmlui/clearcache
-> Clears the Cocoon Cache & returns the updated Cocoon Status XML doc

So, if you install this patch, you can see it in action. Browse around
the XMLUI and visit the /statusinfo path. As you browse around, more and
more items will be added to the "EHDefaultStore" cache (which you can
view in the XML returned by /statusinfo). Then, if you visit /clearcache
path, that cache will be cleared out.

However, I will admit, there's another cache that appears in that Cocoon
Status XML, the "DefaultTransientStore" which is seemingly unaffected by
calls to '/clearcache' (it looks to be mostly caching the messages.xml
contents). So, I'm not sure this works on *everything*, but most Cocoon
cached content should be cleared.

Again, all the usual warnings -- DO NOT try this in Production yet.
This is just me playing around with the Cocoon Cache to see what may be
possible. It still isn't very well tested or guaranteed to be
functioning properly. :)

- Tim

Post by Tim Donohue
Once you apply the previously sent patch, you should be able to clear
http://localhost:8080/xmlui/clearcache
Again, it will return a bunch of XML (which is Cocoon Status Info). But,
<group name="VM">
<group name="...EHDefaultStore">
<value name="cached">
<line>[empty]</line>
</value>
<value name="size">
<line>0 items in cache (0 are empty)</line>
</value>
</group>
</group>
- Tim