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 infl
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 pr
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
> 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 falli
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 `r
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
> On every consequent page request ResponseCache is created again, but
> with original defaults as specified in
> radiant-0.6.2/app/models/response_cache.rb.
I avoided this by adding this line to the "activate" def of a custom
extension:
ResponseCache.defaults[:perform_caching] = false
> 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 Response
> 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 s
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
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
re
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
/con
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:
> ResponseCache.defau
> > 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:
Respons
Todd McGrath wrote:
>> 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
>> leas
>
> 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 ment
> > 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 th
Todd McGrath wrote:
> 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 .ym
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?
> 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
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?
Sean
Daniel Sheppard wrote:
> Maybe I need to dump my assumptions for a moment. Knowing the page that
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?) sugges
> H... does rails give you access to the session cookie before it
> gets sent off in the response? Perhaps the site_controller could be
> changed to clear out that cookie if the request is going to be cached
-
> giving a warning / raising an exception if the session is not empty.
> You'd st
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
I too have a need to implement a system that prevents displaying pages
unless the user is authenticated. I will need levels of authentication
and have more than just a handful of users.
Smells like sessions to me but do I understand correctly that radiant's
caching prevents this?
I'm not even
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 = Cache.get_conte
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/.yml
b) check for the validity of /c
date 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 i
urrent caching mechanism, running:
ab2 -n 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
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
Regarding to caching, I might just try the following:
1. Make the page-parts accessible via urls. ( /pagename/partname )
2. Make the snippets accessible via urls.( /snippet/snippetname ...
might clash )
3. Have a method on PagePart which'll determine if their rendered
context is dynamic or not.
> 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
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=1200&limit=10
and I must turn off caching to make this work. Why not just let the
cache
work on the full uri? Peopl
> > 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 p
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. Howe
- It's annoying to have to clear page cache after every edit in order to
view your change.
The cache is automatically cleared for the page you edited, but only that
page. If you edit a layout or snippet, the whole cache is cleared.
Also, I see no reason why we can't attach a Preview button
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 th
y, 3 January 2007 2:52 PM
> To: radiant@lists.radiantcms.org
> Subject: Re: [Radiant] Ideas for reimplementation of radiant caching
>
> >From looking at response_cache, there are only two features that it
> implements that the default rails action caching didn't (easily):
&g
> 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
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).
> Am I missing something
>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 ju
Daniel Sheppard wrote:
> I want radiant to have a more robust caching mechanism than the current
> 'expire every x minutes' method of doing things - I'd like it to be able
> to handle just removing things from the cache when things actually
> change. I've roughed out a plan on how I think this shou
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
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
Dan,
It seems you have given this quite a bit of thought, and it could
work. I'm just worried about when will the ROI of performace hit make
it be worth.
Just as an anecdote, I've worked with paid enterprise-grade CMS's,
open-source CMS's and I've only seen two types of caching:
1) The classic:
I want radiant to have a more robust caching mechanism than the current
'expire every x minutes' method of doing things - I'd like it to be able
to handle just removing things from the cache when things actually
change. I've roughed out a plan on how I think this should be done in a
safe manner.
I
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
Hi,
Radiant uses YAML for caching pages, but I think Marshal is better. I
recommend Marshal because YAML has a problem of handling multi-byte
characters and YAML is slower than Marshal. I attached the patch for
using Marshal, this works fine in my environment.
1. multi-byte characters problem
I
Hi,
On 25-Sep-2006 13:30 -0500, J Coppedge was heard to say:
> 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 short for an image
> gallery that has to generate the thumbnails on the fly. Just causes
> overhead an
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 s
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:
http://d
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
___
Hi again,
Thanks for the suggestion, I have checked and I don't have a filter on
the CSS page.
Bodhi, I take your point that the difference isn't that much, but as it
is a file that is cached it should be pretty quick.
I'm wondering if I am doing something wrong?
Regards
Nathan
--
Posted vi
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 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
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 t
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 ki
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 ot
On 8/18/06, John W. Long <[EMAIL PROTECTED]> wrote:
> I don't have plans to change the caching mechanism. Are you really
> experiencing that much load that regenerating the page every five
> minutes or so is a problem? I would find that really, really surprising.
> If you were you could probably af
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 develope
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
61 matches
Mail list logo
