Re: [Catalyst] FastCGI caching issue
The problem has something to do with HTML::FormHandler and HTML::FillInField. I verified that each request *was* hitting my application, and also that the database was getting hit as well. What I discovered is that when I added a TT tag [% customer.email %] in addition to the tag for my HTML::FormHandler field - [% myform.fif.email %], refreshing multiple times resulted in the HFH value changing while the new [% customer.email %] tag got the correct value. Seems like I need to further my understanding of HFH. Thanks for the help! Steve On 7/6/2010 9:33 PM, Toby Corkindale wrote: On 07/07/10 07:35, Steve wrote: The reference to $cachetime was found on the Catalyst Wiki: http://wiki.catalystframework.org/wiki/adventcalendararticles/2007/11-making_your_catalyst_app_cache-friendly In that instance, it's a variable used in some example code - it only has any meaning within that example. If you're using that whole end() block, then cool, but just setting $cachetime=0; on its own won't do anything. The way you put it, it sounds like you're considering doing that. I'd say it shouldn't be your first concern; everyone else tends to have things like forms and pages work fine without needing to tweak that - browsers already have some smarts in them to try and avoid caching dynamic data. I verified that the http header was changed, however this did not fix the problem. As of my last post, I had not implemented/acted on the $cachetime, but since then I've successfully set the http response header 'Cache-Control' to 'no-cache'. This has not solved the problem - Yes, I restarted my httpd server. At present, my cohort and I suspect that we are up against a database caching problem, but haven't completely ruled out anything. Am I better off asking the DBIC list? Well, you haven't told us a whole lot about what the problem is, so it's hard for us to agree or disagree with your diagnosis. I've got a customer form. I have the app open in three different browser tabs (different browsers, different computers yield same result). The following chain of events results in the old values being rendered by my form: 1) I set the email address for customer 'Walmart' to 'wa...@wm.com' in one tab, then save it. 2) In the next browser I edit the same customer, changing the email field to 's...@wm.com', and save it. 3) In the last browser I edit the same customer, changing the email field to 'd...@wm.com', and save it. 4) I go to any of the three browser tabs and refresh. The value toggles between the three values. I'm still a little confused/concerned by your comment that my session seems to 'cross' over to other fastCGI processes; it sounds a bit like you are misunderstanding what the session is *meant* to do, and thus, perhaps the problem lies there. I misspoke. Run your app with Debug mode enabled, and watch the logs - you will be able to see if you're hitting the app, or getting a cached copy. If you add some debug statements in your form handling, you can also see what data you're getting back from the database. You might also want to enable DBIC_TRACE in your environment, to get a /lot/ of SQL dumped out too. Best of luck, Toby Steve On 7/6/2010 4:23 PM, Tomas Doran wrote: On 6 Jul 2010, at 19:26, Steve wrote: however my session seems to 'cross' over to other fastCGI processes (I've got 3 fastCGI processes running). Yes, they'll do that. I've googled around and even tried to set $cachetime = 0 in my Root.pm controller's END action. Er, what is $cachetime? What are you expecting it to effect. Can anyone point me in the direction of a fix? If I've not provided enough background info let me know and I'll expand. Please expand. If you suspect code, please attach code. Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.830 / Virus Database: 271.1.1/2986 - Release Date: 07/06/10 14:36:00 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] FastCGI caching issue
Hello, I remember having a similar problem a long time ago, did you try instead of no-cache to set the cache contol to no-store? I remember that no-cache didn't work but no-store works perfectly if you want the web page to always reflect the latest data that is in your storage. -Leandro On Wed, Jul 7, 2010 at 2:54 PM, Steve st...@matsch.com wrote: The problem has something to do with HTML::FormHandler and HTML::FillInField. I verified that each request *was* hitting my application, and also that the database was getting hit as well. What I discovered is that when I added a TT tag [% customer.email %] in addition to the tag for my HTML::FormHandler field - [% myform.fif.email %], refreshing multiple times resulted in the HFH value changing while the new [% customer.email %] tag got the correct value. Seems like I need to further my understanding of HFH. Thanks for the help! Steve On 7/6/2010 9:33 PM, Toby Corkindale wrote: On 07/07/10 07:35, Steve wrote: The reference to $cachetime was found on the Catalyst Wiki: http://wiki.catalystframework.org/wiki/adventcalendararticles/2007/11-making_your_catalyst_app_cache-friendly In that instance, it's a variable used in some example code - it only has any meaning within that example. If you're using that whole end() block, then cool, but just setting $cachetime=0; on its own won't do anything. The way you put it, it sounds like you're considering doing that. I'd say it shouldn't be your first concern; everyone else tends to have things like forms and pages work fine without needing to tweak that - browsers already have some smarts in them to try and avoid caching dynamic data. I verified that the http header was changed, however this did not fix the problem. As of my last post, I had not implemented/acted on the $cachetime, but since then I've successfully set the http response header 'Cache-Control' to 'no-cache'. This has not solved the problem - Yes, I restarted my httpd server. At present, my cohort and I suspect that we are up against a database caching problem, but haven't completely ruled out anything. Am I better off asking the DBIC list? Well, you haven't told us a whole lot about what the problem is, so it's hard for us to agree or disagree with your diagnosis. I've got a customer form. I have the app open in three different browser tabs (different browsers, different computers yield same result). The following chain of events results in the old values being rendered by my form: 1) I set the email address for customer 'Walmart' to 'wa...@wm.com' in one tab, then save it. 2) In the next browser I edit the same customer, changing the email field to 's...@wm.com', and save it. 3) In the last browser I edit the same customer, changing the email field to 'd...@wm.com', and save it. 4) I go to any of the three browser tabs and refresh. The value toggles between the three values. I'm still a little confused/concerned by your comment that my session seems to 'cross' over to other fastCGI processes; it sounds a bit like you are misunderstanding what the session is *meant* to do, and thus, perhaps the problem lies there. I misspoke. Run your app with Debug mode enabled, and watch the logs - you will be able to see if you're hitting the app, or getting a cached copy. If you add some debug statements in your form handling, you can also see what data you're getting back from the database. You might also want to enable DBIC_TRACE in your environment, to get a /lot/ of SQL dumped out too. Best of luck, Toby Steve On 7/6/2010 4:23 PM, Tomas Doran wrote: On 6 Jul 2010, at 19:26, Steve wrote: however my session seems to 'cross' over to other fastCGI processes (I've got 3 fastCGI processes running). Yes, they'll do that. I've googled around and even tried to set $cachetime = 0 in my Root.pm controller's END action. Er, what is $cachetime? What are you expecting it to effect. Can anyone point me in the direction of a fix? If I've not provided enough background info let me know and I'll expand. Please expand. If you suspect code, please attach code. Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.830 / Virus Database: 271.1.1/2986 - Release Date: 07/06/10 14:36:00 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo:
[Catalyst] FastCGI caching issue
I've hit a snag in the deployment of my first *real* Catalyst App. My application uses HTML::FormHandler and HTML::FormHandler::Model::DBIC, and is deployed using Apache/fastCGI/mysql on a RedHat Linux box. The problem I've encountered is that certain forms don't always retrieve the data from the database after I've made modifications and saved. I know the updates are being performed within the database, however my session seems to 'cross' over to other fastCGI processes (I've got 3 fastCGI processes running). I've googled around and even tried to set $cachetime = 0 in my Root.pm controller's END action. Can anyone point me in the direction of a fix? If I've not provided enough background info let me know and I'll expand. Thanks, Steve attachment: steve.vcf___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] FastCGI caching issue
On 6 Jul 2010, at 19:26, Steve wrote: however my session seems to 'cross' over to other fastCGI processes (I've got 3 fastCGI processes running). Yes, they'll do that. I've googled around and even tried to set $cachetime = 0 in my Root.pm controller's END action. Er, what is $cachetime? What are you expecting it to effect. Can anyone point me in the direction of a fix? If I've not provided enough background info let me know and I'll expand. Please expand. If you suspect code, please attach code. Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] FastCGI caching issue
The reference to $cachetime was found on the Catalyst Wiki: http://wiki.catalystframework.org/wiki/adventcalendararticles/2007/11-making_your_catalyst_app_cache-friendly As of my last post, I had not implemented/acted on the $cachetime, but since then I've successfully set the http response header 'Cache-Control' to 'no-cache'. This has not solved the problem - Yes, I restarted my httpd server. At present, my cohort and I suspect that we are up against a database caching problem, but haven't completely ruled out anything. Am I better off asking the DBIC list? Steve On 7/6/2010 4:23 PM, Tomas Doran wrote: On 6 Jul 2010, at 19:26, Steve wrote: however my session seems to 'cross' over to other fastCGI processes (I've got 3 fastCGI processes running). Yes, they'll do that. I've googled around and even tried to set $cachetime = 0 in my Root.pm controller's END action. Er, what is $cachetime? What are you expecting it to effect. Can anyone point me in the direction of a fix? If I've not provided enough background info let me know and I'll expand. Please expand. If you suspect code, please attach code. Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.830 / Virus Database: 271.1.1/2985 - Release Date: 07/06/10 02:36:00 attachment: steve.vcf___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] FastCGI caching issue
On 6 Jul 2010, at 22:35, Steve wrote: At present, my cohort and I suspect that we are up against a database caching problem, but haven't completely ruled out anything. Am I better off asking the DBIC list? Erm, well if you're unsure, the first thing to do is work out if your app is actually getting hit to generate the page or not - use livehttpheaders, or paros proxy, or charles proxy or something.. Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
