On Jun 7, 2012, at 2:03 PM, Cliff Kachinske wrote: > It's not unusual to have a setup like this: > > development box -> test box -> production box > > The test box is a clone of the production box, as much as you can make it so. > No reason why it couldn't be a virtual machine, but it has to be there to > prevent surprises due to different patch/version levels of the various > packages in the system.
Right. I'm working on a back end for an iPad app that uses that general setup. The development environment is local to my map, and the text box is a small-scale imitation of the production box (both Rackspace servers, as it happens), with identical configurations. Minor changes I just push out to the test box, but anything that's more involved goes through all three. (To my original restart question, though: think of it as an academic project. If you wanted to recognize a restart from inside an app, how would you go about it?) > > On Thursday, June 7, 2012 3:48:00 PM UTC-4, Derek wrote: > Ah, it seemed to me this is just a development environment and thus you > wouldn't need this feature in production? > > On Thursday, May 31, 2012 2:47:51 PM UTC-7, Jonathan Lundell wrote: > On May 31, 2012, at 2:32 PM, Derek wrote: >> If you're blowing away your database, why don't you clear memcached when you >> blow away your database? I don't see how this is a web2py issue. > > One possible reason: web2py (and in particular my application) aren't > necessarily the only memcached clients on the machine. > > Regardless, it's more a puzzle than an issue. I can certainly clear my caches > manually, and that's in fact what I do now. But if there *were* a > straightforward way to detect web2py restart from inside an app, that'd be > handy in this particular case. > >> >> On Wednesday, May 30, 2012 7:10:13 PM UTC-7, Jonathan Lundell wrote: >> I've got an application that uses memcached. I'd like to recognize when >> web2py gets restarted (mod_wsgi, fwiw) so I can flush my cache. No doubt I >> can figure something out, but I'm sure I must be missing something obvious. >> (My motivation: in my development environment, I sometimes blow away my >> database when installing and starting a new copy of the app, and things get >> confused when the cache is still holding data from the earlier run.) >
