Elias Torres wrote:

Allen Gilliland wrote:
Looks fine to me, so +1, but one note.  we should be clear about the
caching strategy.  my expectation is that we would not cache these feeds
just like we don't cache search results pages.  that would need to be
accounted for in the FeedServlet.

It makes sense. It makes so much sense that I'm writing up another
proposal for complete reverse proxy support (e.g. no page cache at all,
optionally).

We would like an option that disables page caching in the app server
because we discovered a large amount of CPU being consumed by
StringBuffer memory management instead of writing directly to the socket
stream.

Sure, I'm always interested in supporting more caching configs =)

You *can* actually disable all of Roller's rendering caches very easily in the current code. Each of Roller's caches supports an "enabled" flag in the config, so if you put ...

cache.weblogpage.enabled=false
cache.weblogfeed.enabled=false

in your config file then you don't have caching in the app anymore. i use this feature regularly in testing.

-- Allen



Also, we provide the option for the built-in search to be disable, and
that would also need to be handled in the FeedServlet so that search
feeds are not returned when search is disabled.

Right. Good catch.

-Elias

-- Allen


Elias Torres wrote:
Hi guys (again),

Here's another simple/short proposal that I would like comments on so I
can get a sense from the community if I can proceed and when.

http://cwiki.apache.org/confluence/display/ROLLER/Proposal_SearchFeeds

-Elias

Reply via email to