On 9/18/07, Daniel Sheppard [EMAIL PROTECTED] wrote:
Do you have any other errors in your log file that look like
they show the errors in writing? If not, it's probably just that
one process is trying to read the cache while another is writing
to it - my changes should stop that situation from
That is a bit of a weird trace. I can't quite follow how a trace
that looked like that could happen (I don't see how the inflector
would want to get involved during the file opening process).
It's falling over during the writing of the .yml file (line 169),
I'm guessing that's due to multiple
Can It be a dreamhost problem? Dreamhost is knew to sometimes kill the
dispatchers... can this cause the problem?
On 9/18/07, Daniel Sheppard [EMAIL PROTECTED] wrote:
That is a bit of a weird trace. I can't quite follow how a trace
that looked like that could happen (I don't see how the
I'm getting the same problem(see below) with radiant 0.6.2 on
dreamhost... someone is getting something like this?
On 5/13/07, Andrew Klein [EMAIL PROTECTED] wrote:
Hello all!
Okay, now that I have most of my other problems worked out, I've ran
into a new issue. It appears that after so long
Here is the error log:
Processing SiteController#show_page (for 189.24.37.87 at 2007-09-17
18:17:02) [GET]
Parameters: {action=show_page, url=/, controller=site}
NoMethodError (undefined method `[]' for false:FalseClass):
/vendor/radiant/app/models/response_cache.rb:65:in `read_metadata'
NoMethodError (undefined method `[]' for false:FalseClass):
/vendor/radiant/app/models/response_cache.rb:65:in `read_metadata'
/vendor/radiant/app/models/response_cache.rb:71:in
Just checked in a change that will fix it from breaking your site.
Looks like either a process was falling
Any ideas?
I have tried to track this bug with Aptana debugger on Windows.
I'm using Radiant 0.6.2 (gem) with WEBrick server on my development
machine.
The problem is: ResponseCache instance is not living during whole server
lifespan. It is recreated on every page request.
First time, when
I have tried to track this bug with Aptana debugger on Windows.
I'm using Radiant 0.6.2 (gem) with WEBrick server on my development
machine.
The problem is: ResponseCache instance is not living during
whole server
lifespan. It is recreated on every page request.
Yes, the ResponseCache
David Piehler wrote:
I'm running Radiant 0.6.0rc2
Is there any way to disable caching of Radiant generated pages AND
plugin code when running in development mode? Having to clear the page
cache after every plugin code change is slowing me down.
In order to not cache Radiant pages I had
Hello all!
Okay, now that I have most of my other problems worked out, I've ran
into a new issue. It appears that after so long of being up and running,
I suddenly start receiving 'Apache' errors for certain pages of my site
(But not all.) Sometimes just 1 page, other times up to 10+. I try
I'm running Radiant 0.6.0rc2
Is there any way to disable caching of Radiant generated pages AND
plugin code when running in development mode? Having to clear the page
cache after every plugin code change is slowing me down.
In order to not cache Radiant pages I had to set the following in
Hi,
In production mode, Radiant uses page level caching right?
Settings (environment.rb and environments/production.rb) look like page level
caching, but I thought page level caching wrote files to the public/ directory?
I'm confused on the pages being cached as .yml in the cache/ directory?
The caching in radiant is most similar to rails action caching, not page
caching. The radiant custom cache has caused a few problems
for people trying to do session-based things with radiant code, but it
significantly outperforms the rails action cache (or at
least, it does in the mental
Can I set cache options, expire_time for instance, outside of editting the
response_cache.rb file directly?
You sure can. Take a look at the environment files in config/environments/.
Thanks,
I think I got it? -
Example to set the timeout from default of 5 to 10 minutes:
Todd McGrath wrote:
Can I set cache options, expire_time for instance, outside of editting the
response_cache.rb file directly?
You sure can. Take a look at the environment files in config/environments/.
Example to set the timeout from default of 5 to 10 minutes:
Right. Caching the complete url in the database would help,
but would
not work in all cases, i.e. virtual pages that represent
multiple urls.
Perhaps we should try this and get some metrics?
I was thinking that there would be a Page#calculate_urls method that
would by default just
update once per 5 minutes... This is unworkable if
you want conditional content -
ie if user registered
show registered_user_page
else
show login_page
I certainly wasn't saying that page caching wasn't needed, and can
even see how powerful the radiant caching is since
What I was suggesting wasn't that Page.find_by_url be called on
every page request The original email was about changes to the
caching mechanism...
My suggestion, working from your outline:
a) check for the existance of /cache/url.yml
b) check for the validity
OK. Point taken. I was really just putting my two cents in on a
subject that's important to me personally... ie user variable content
and ACLs.
It would be nice to do something like (I haven't actually looked at
the code, my bad):
page = Page.new
page.headers
page.content =
OK. Point taken. I was really just putting my two cents in on a
subject that's important to me personally... ie user variable content
and ACLs.
It would be nice to do something like (I haven't actually looked
at the code, my bad):
page = Page.new
page.headers
Maybe I need to dump my assumptions for a moment. Knowing the page that
we're about to be rendering from the cache would be a useful thing. Why
can't we do it? Because the performance of Page.find_by_url sucks.
I talked a little bit about that suckage a while ago, and somebody
(Adam? Sean?)
I know this is a little late (email from last month)... but in regard
to caching, isn't the major problem with implementing sessions in
Radiant that the headers are cached as well? This seems to be over
optimisation... Just cache the page text and let the headers be
generated. Surely there
1000 -c 2
'http://localhost/articles/2006/04/13/2006-melbourne-international-comed
y-festival-reviews/levelland/'
I ran it first using the current radiant caching mechanism, and then
again modifying the site_controller to always do a Page.find_by_url
regardless of whether the page is cached
Radiant currently caches only the page urls, without the params after
the ?
Am I the only one who thinks this is bad?
For example my products page listing works by
/products?offset=1200limit=10
and I must turn off caching to make this work. Why not just let the
cache
work on the full uri?
It also seems to be a good idea not to put post request's
response into
a cache.
A post supposed to change data, and the outcome of that should not be
cached - I should not say OK if you just signed up as root...
class Page
def cache?
request.get?
end
end
Perhaps that should be
Before changing how the caching works, I would ask, what are the reasons
for modifying caching. I can think of a few.
- It's annoying to have to clear page cache after every edit in order to
view your change.
The solution Dan suggests would make it possible to know exactly which
pages need
I don't see any. It's good enough for most cases, I believe.
The unmentioned alternative, of course, is memcached. It would
take minimal changes to the code, probably a single line in
environment.rb , since ResponseCache piggy-backs on the Rails caching
mechanism.
Well then can we make Apache serve everything? Why not have the options
to make Radiant generate a full directory of HTML files. A possible way
to support having select pieces of the site be dynamic is to use Apache
server side includes to make calls back to Radiant for specific pieces.
Daniel Sheppard wrote:
From looking at response_cache, there are only two features that it
implements that the default rails action caching didn't (easily):
- Expire Everything
- Expire After time
It also caches the entire response (headers + body).
Yeah, I left that off
Hi Dan, Ruben,
Actually I once build a commercial Enterprise CMS where a custom content
proxy would cache everything. It was flushed on time-out /and/ upon
changes in the content. The proxy allowed large companies to set up
caches wherever they pleased and still have a central repository. The
From looking at response_cache, there are only two features that it
implements that the default rails action caching didn't (easily):
- Expire Everything
- Expire After time
Am I missing something else? If I'm not, then I think I might have found
something that will give a big
Dan,
This sounds like a pretty good system.
I'm not sure if my suggestions/concerns are directly related caching,
but they kind of go with it.
The biggest hole in Radiant that I can see is that there is not proper
version management and publishing capabilities.
I work for a large state government
This is excellent. Can you update the unit tests to reflect this change?
Bodhi, would you have time to verify the performance statistics and make
sure this makes it into the core?
--
John Long
http://wiseheartdesign.com
Keita Yamaguchi wrote:
Hi,
Radiant uses YAML for caching pages, but I
I've been using the gallery_behavior for a simple directory/file based gallery. Works well - but have a couple of questions that others may have already experienced...1. Is there a way to control the image caching separately from the rest of the site? The default cache is 5 minutes and is quite
Hey all
How is the caching set up in radiant? As it uses its own caching system
doesn't it, I am looking at doing something similar in another project,
however probably serving HTML rather than YAML but I cant fathom how radiant
custom caching has been set up?
Can anyone help?
Cheers
Tim
Tim Perrett wrote:
How is the caching set up in radiant? As it uses its own caching system
doesn't it, I am looking at doing something similar in another project,
however probably serving HTML rather than YAML but I cant fathom how radiant
custom caching has been set up?
Look at:
On 22/08/2006, at 2:45 PM, Nathan Donaldson wrote:
Hi all,
I have been looking at my logs as I am testing radiant and have noticed
that the CSS files seem to take longer to generate than the HTML files.
Am I doing something wrong?
Here is a snippet from my logs, you can see that the css
Nathan Donaldson wrote:
Hi all,
I have been looking at my logs as I am testing radiant and have noticed
that the CSS files seem to take longer to generate than the HTML files.
Am I doing something wrong?
Do you have a filter defined on the CSS page? Maybe Textile is spending
lots of
On Aug 18, 2006, at 16:29, John W. Long wrote:
Jason Hoffman did a study on Radiant and caching and posted some
interesting screenshots about it on Flickr:
http://flickr.com/photos/textdriveinc/179393665/in/photostream/
I *know* Jason loves testing their Sun/Solaris platform :)
What kind
Hi all,
I have been looking at my logs as I am testing radiant and have noticed
that the CSS files seem to take longer to generate than the HTML files.
Am I doing something wrong?
Here is a snippet from my logs, you can see that the css file is taking
5 times longer to generate than the page
Hey guys,
I looked around and it seems like this hasn't been asked before, but
one of my major concerns with Radiant (which I've been using for quite
some time now) is its caching mechanism. Here's my problem:
I plan on deploying RadiantCMS on websites with content that doesn't
change often - it
Frederico Oliveira wrote:
Now for the question: is there a plan to make the caching method used
by Radiant change, or should I patch the application myself? I can
predict many others will be in this situation soon as the application
is considered for real-world use by more and more developers
Frederico Oliveira wrote:
Still, giving users the chance to change the ResponseCache expiry
times in, say, a config file would be a safe bet.
Actually, you can do that. Just drop the following in config/environment.rb:
ResponseCache.defaults[:expire_time] = 2.days
There are a couple of
43 matches
Mail list logo
