Yes, I know, but I want to loose the 'echo |' hack in it which in turn first needs the upcoming patch for the -S command line which we talked about.
On Jan 28, 5:46 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > I am still waiting for a copy of the lastest patch. The one you send > me was rejected because not build against latest commit. > > Massimo > > On Jan 27, 5:55 pm, achipa <attila.cs...@gmail.com> wrote: > > > Err, just noted above :) Put the following line in applications/myapp/ > > cron/crontab > > > -1 * * * * web2py *applications/myapp/private/script.py > > > if your startup script is a regular python script OR > > > -1 * * * * web2py *mycontroller/myfunc > > > if you want to execute a controller function. The -1 is a clue for the > > cron module that this is a one time, run-first task. If you have > > several of these, they will be run sequentially as they appear in the > > crontab. While the startup tasks do not finish, no regular cron tasks > > will be executed. Since I don't know what shared resources you will be > > using, their protection (via mutexes, locks, etc) is the user's > > responsibility. > > > BUT all this will work only AFTER I implement it and Massimo puts in > > trunk, which will hopefully be in a day or two :) > > > On Jan 27, 11:55 pm, billf <billferr...@blueyonder.co.uk> wrote: > > > > This sounds like a good solution - I will have a play with it. Being > > > a bit lazy, what would be the setting for a "run once, straightaway" > > > entry in the crontab? > > > > On Jan 27, 10:44 pm, achipa <attila.cs...@gmail.com> wrote: > > > > > We have internal cron functionality since not so long ago, which > > > > allows us to schedule execution of 3rd party scripts, web2py > > > > environment wrapped scripts (this is "web2py -S app -M -R private/ > > > > script.py" ) and controller functions. Each app has it's own cron > > > > settings (check applications/cron/crontab for examples), so startup > > > > scripts won't be tripping over each other (you can have your own > > > > applications/myapp/cron/crontab). So, since cron is already > > > > initializing itself and reading the crontabs at the first possible > > > > time regardless of how it's run (wsgi,(f)cgi,cherrypy), it might as > > > > well run your application init script. You could just add a line in > > > > the format I mentioned above and that's it. I got the idea when > > > > massimo said web2py -S -M -R since that is roughly also what I use to > > > > wrap stuff I'm starting from cron. > > > > > PS. If crontab sounds like a Hungarian curse to you, take a look* > > > > athttp://en.wikipedia.org/wiki/Cron#Usage > > > > > *Web2py cron just *mimicks* crontab, so it should work on all > > > > platforms without additional daemons - even if you're on windows or on > > > > a mac, it's still a go. > > > > > On Jan 27, 8:59 pm, billf <billferr...@blueyonder.co.uk> wrote: > > > > > > achipa > > > > > > sorry that just sailed over my head. how would that work? what could > > > > > it do? > > > > > > Bill > > > > > > On Jan 27, 7:47 pm, achipa <attila.cs...@gmail.com> wrote: > > > > > > > Just a thought - we could hook an application level startup script > > > > > > (or > > > > > > controller function) into cron. As cron already takes care of cgi/ > > > > > > fastcgi/wsgi/cherrypy, timings and some threading peculiarities it > > > > > > shouldn't be too hard to integrate. How do you feel about that ? > > > > > > > -1 * * * * * web2py *applications/myapp/private/script.py > > > > > > > billf wrote: > > > > > > > My original question was about app-level configuration - I maybe > > > > > > > confused things by my post #3. The plugin stuff is really a > > > > > > > separate > > > > > > > tho' related thread. > > > > > > > > Re Massimo's post re "web2py -S app -M -R private/script.py" > > > > > > > > How does this work if you have an instance of web2py with several > > > > > > > active applications? I suppose it wouldn't be bad to just > > > > > > > include a > > > > > > > line (in private/script.py) for each application, e.g. for app > > > > > > > "bill" > > > > > > > run script X, for app "Tim" run script Y. > > > > > > > > If you used this approach and wanted to change the config for app > > > > > > > "bill" (script X) would you have to restart web2py or could you > > > > > > > just > > > > > > > run script X? > > > > > > > > On Jan 27, 6:09 pm, Timothy Farrell <tfarr...@swgen.com> wrote: > > > > > > > > I think you're misunderstanding. We're talking about the > > > > > > > > database > > > > > > > > driver code that Bill coded together. This has nothing to do > > > > > > > > with any > > > > > > > > particular app. Rather how and when sql.py starts up. > > > > > > > > > mdipierro wrote: > > > > > > > > > I oppose any initialization that is not at the app level. It > > > > > > > > > would > > > > > > > > > introduces hidden dependencies in the apps. > > > > > > > > > > Massimo > > > > > > > > > > On Jan 27, 12:01 pm, Timothy Farrell <tfarr...@swgen.com> > > > > > > > > > wrote: > > > > > > > > > >> I didn't think we were talking on the app level. > > > > > > > > > >> mdipierro wrote: > > > > > > > > > >>> I am skeptical about initialization code being initialized > > > > > > > > >>> by the app > > > > > > > > >>> because it may take time and web server may kill it. > > > > > > > > > >>> My approach is to create an initialization script in > > > > > > > > >>> private and run > > > > > > > > >>> it with > > > > > > > > > >>> web2py -S app -M -R private/script.py > > > > > > > > > >>> On Jan 27, 10:24 am, Timothy Farrell <tfarr...@swgen.com> > > > > > > > > >>> wrote: > > > > > > > > > >>>> Yes, but WSGI/FCGI web-servers always have several new > > > > > > > > >>>> processes ready > > > > > > > > >>>> for requests rather than having to wait for a process to > > > > > > > > >>>> start as soon > > > > > > > > >>>> as a request is received. > > > > > > > > > >>>> Be careful about the multiple processes thing. Separate > > > > > > > > >>>> processes can > > > > > > > > >>>> import the same module and not be sharing data or code > > > > > > > > >>>> because they are > > > > > > > > >>>> run under two separate interpreters in two separate > > > > > > > > >>>> processes. You only > > > > > > > > >>>> have to worry about this type of sharing with shared > > > > > > > > >>>> resources like files. > > > > > > > > > >>>> It seems that you're suggesting one interpreter process > > > > > > > > >>>> should parse the > > > > > > > > >>>> available plugins and provide that data to other > > > > > > > > >>>> interpreter process. > > > > > > > > >>>> Now this could work with threads, but inter-process > > > > > > > > >>>> communication is > > > > > > > > >>>> much more complicated and may take longer than it would > > > > > > > > >>>> for each process > > > > > > > > >>>> to just parse it's own set of plugins. > > > > > > > > > >>>> -tim > > > > > > > > > >>>> achipa wrote: > > > > > > > > > >>>>> One itsy-bitsy note about the persistence of > > > > > > > > >>>>> WSGI/FCGI/standalone - > > > > > > > > >>>>> out of these, only the standalone has serious > > > > > > > > >>>>> persistence. WSGI and > > > > > > > > >>>>> FCGI can (and will) get restarted on the web server's > > > > > > > > >>>>> whim (some > > > > > > > > >>>>> webservers come with a predefined number of requests > > > > > > > > >>>>> after which they > > > > > > > > >>>>> restart the process, just in case). Also, with WSGI and > > > > > > > > >>>>> FCGI you can > > > > > > > > >>>>> have several parallel processes, which again complicates > > > > > > > > >>>>> things (do > > > > > > > > >>>>> you consider a second process starting a first load or > > > > > > > > >>>>> can it re-use > > > > > > > > >>>>> the results of the first one's startup ? It really > > > > > > > > >>>>> depends on the > > > > > > > > >>>>> usage scenario). > > > > > > > > > >>>>> As for main.wsgibase(), my bad, I wanted to say 'when' > > > > > > > > >>>>> not 'where'. > > > > > > > > > >>>>> On Jan 27, 4:35 pm, Timothy Farrell <tfarr...@swgen.com> > > > > > > > > >>>>> wrote: > > > > > > > > > >>>>>> I think you're confusing things.... see below > > > > > > > > > >>>>>> achipa wrote: > > > > > > > > > >>>>>>> The problem is that first start is a very relative term > > > > > > > > >>>>>>> depending on > > > > > > > > >>>>>>> how you run web2py, it's not the same for > > > > > > > > >>>>>>> standalone/cherrypy, CGI, > > > > > > > > >>>>>>> MOD_WSGI, parallel versions of these, etc. > > > > > > > > > >>>>>> Correct...sorta. We really have three categories here, > > > > > > > > >>>>>> threaded > > > > > > > > >>>>>> persistent python interpreter, persistent distinct > > > > > > > > >>>>>> processes and > > > > > > > > >>>>>> (non-persistent) distinct processes. The third scenario > > > > > > > > >>>>>> is vanilla > > > > > > > > >>>>>> CGI. The core of web2py is started for every request > > > > > > > > >>>>>> with plain CGI. > > > > > > > > >>>>>> However WSGI, FCGI and the standalone setups use some > > > > > > > > >>>>>> variation of the > > > > > > > > >>>>>> other two setups in which case imported modules are not > > > > > > > > >>>>>> rerun. (Google > > > > > > > > >>>>>> agrees...http://code.google.com/appengine/docs/python/runtime.html#App_Caching)> > > > > > > > > >>>>>> This means that your > > > > > > > > > >>>>>>> startup code could be executed in a whole lot of > > > > > > > > >>>>>>> places, not always > > > > > > > > >>>>>>> where you want it. You also have to make arrangements > > > > > > > > >>>>>>> for race > > > > > > > > >>>>>>> conditions (what if a web request comes in while you > > > > > > > > >>>>>>> are executing > > > > > > > > >>>>>>> your startup function?) > > > > > > > > > >>>>>> This part is only true if your code is in the page > > > > > > > > >>>>>> processing path (i.e. > > > > > > > > >>>>>> main.wsgibase() ). If your code is in an imported > > > > > > > > >>>>>> module it will only > > > > > > > > >>>>>> be run once per executed process.> As an idea, you might > > > > > > > > >>>>>> want to check/set a flag variable in cache.ram. > > > > > > > > > >>>>>>> If you don't see that flag, presume it's a first start, > > > > > > > > >>>>>>> if it is > > > > > > > > >>>>>>> there, consider yourself loaded. This also can lead to > > > > > > > > >>>>>>> a few gotcha's > > > > > > > > >>>>>>> (use mutexes to prevent race conditions) and doesn't > > > > > > > > >>>>>>> work with CGI, > > > > > > > > >>>>>>> but until somebody suggests something better, it might > > > > > > > > >>>>>>> be worth a try. > > > > > > > > > >>>>>> This is a good point. If you're module has module > > > > > > > > >>>>>> static variables then > > > > > > > > >>>>>> those variables could be accessed from multiple threads > > > > > > > > >>>>>> and hence would > > > > > > > > >>>>>> need to be protected with a lock-type. To see an > > > > > > > > >>>>>> example of this, the > > > > > > > > >>>>>> cache module has "meta_storage" that holds cached > > > > > > > > >>>>>> information and is > > > > > > > > >>>>>> thread-safe. > > > > > > > > > >>>>>> -tim > > > > > > > > > >>>>>>> On Jan 27, 5:44 am, billf > > > > > > > > >>>>>>> <billferr...@blueyonder.co.uk> wrote: > > > > > > > > > >>>>>>>> Basically, is there any code that receives control > > > > > > > > >>>>>>>> when an application > > > > > > > > >>>>>>>> first starts that allows some > > > > > > > > >>>>>>>> initialisation/configuration that > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
