carlos beltran wrote:
> We have been fighting a little with the cache system in Jetspeed 1.3.a1.
> Our goal was that of showing real time data in a portlet presenting a
> RSS page generated with JSP. But we had problems because the portlet
> content was not refreshed when the user was hitting the refresh button
> in his web browser.
>
> Why?
> Answer: cache system.
>
> Two different kinds of cache are acting in the portlet; the first one is
> caching the portlet object in memory and the second one is caching the
> URL that the portlet is using. This second cache is called the
> DiskCache. There is a third class of cache, but it is only working for
> the channels defined in OCS and it is known as FeedCache.
The FeedCache is new for me. Either is something new coming from Raphael
changes or there is a wrong javadoc somewhere. Probably is the DiskCache
by other name.
> The DiskCache has mainly two types of URL: locals and remotes. The
> locals are not cached and are directly get from the URL source ( so if
> your page is local you will not have problems). The DiskCache recognizes
> as locals the next types of URLs:
>
> /test/test
> http://localhost
> http://127.0.0.1
> http://ourserver.domainame
>
> Notice that the URL "http://ourserver"; is considered as remote...
>
And also protocols listed in a specific list in JR.p (file:, jndi:,
classloader:, ...)
> The remotes URL are refreshed by the DiskCacheDaemon. This daemon runs
> with a interval defined in the JR.p; each time it runs it takes all the
> URL from the DiskCache and renews that ones that are remote and have
> passed over their "expiration time". This expiration time is hard coded
> in the source of DiskCacheEntry.java and it is equal to 15 minutes.
>
Not exactly. The initial expiration time is set to 15 minutes. When the
diskcacheDaemon runs, it is set to the Expires: header of the URL (if it
exists and it is > 0)
But the important thing is that the URLs will only be checked when the
DiskCacheDaemon runs (all of them). This is every hour, by default.
> So what happens if you want to refresh your remote URL in the DiskCache
> with a interval lower than 15 minutes, ..well.., you can't, unless you
> change DiskCacheEntry to modify the default expiration time.
>
If the url returns a Expires: header it should be possible to have it
refreshed every time the daemon runs.
> Then, playing with the "expiration time" and the daemon interval, you
> would be able to control the refresh of your portlet lower that 15
> minutes ( in fact we wanted a refresh time of 1 minute).
>
> Finally,In both, local and remote URL, we would suggest to "jump" the
> "portlet cache". This can be done overwriting the isCacheable() method
> as it has been explained in other messages.
>
This brings a lot of overhead for some portlets, as a XSLT transform
will have to be performed for every getContent() call. So, it depends on
your concrete portlet if it is needed or not.
> Hope this help someone,
Yes, at least we are beginning to have reasonable documentation on the
behaviour.
For the next iteration I would have:
- resources can be cacheable or not. The selection will be done via
configurable regular expressions, and not through a fixed strategy. The
minimum and maximum expiration times will be settable for each regexp,
with a global default.
- the daemon will run with a much smaller granularity (every minute?)
but it will check only expired URLs. Currently it makes a request for
every resource with IfModifiedSince: set, and skips refreshing if it
gets a "Not Modified" answer. This saves a lot of work, but still is not
completely trustable (see Apacheweek below). Also, a lot of channels do
not handle these headers.
- The OCS entries will override update times using the OCS information
coming in the feed (they are like update --> once daily ...) They should
update global defaults, but NOT url-regexp specified values.
- A minimum and a maximum expiration time will be set for every entry.
The minimum will be used if Expires: is not meaningful (<=0 or in the
past), and the maximum to avoid pathological cases, where the date
returned is the script modification date, not the channel generation.
For instance, the ApacheWeek entry honors the IfModifiedSince: and
Exppires: headers BUT, when the war is expanded, the cache file gets the
modification date of the war expansion, not the true one in the cache.
So, unless you delete the cache entry, ApacheWeek will not be updated
until roughly 24 hours after you expand the war.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
