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 > > > > > > >>>>>>>> doesn't have to run after every request? > > > > > > > >>>>>>>> I believe code could be put in db.py but that is not ideal > > > > > > >>>>>>>> conceptually - and would run on every request? > > > > > > > >>>>>>>> I can see that there are pros and cons to the idea of "on > > > > > > >>>>>>>> start" code > > > > > > >>>>>>>> and would be interested in peoples' views. > > > > > > > >>>>>> -- > > > > > > >>>>>> Timothy Farrell <tfarr...@swgen.com> > > > > > > >>>>>> Computer Guy > > > > > > >>>>>> Statewide General Insurance Agency (www.swgen.com) > > > > > > > >>>> -- > > > > > > >>>> Timothy Farrell <tfarr...@swgen.com> > > > > > > >>>> Computer Guy > > > > > > >>>> Statewide General Insurance Agency (www.swgen.com) > > > > > > > >> -- > > > > > > >> Timothy Farrell <tfarr...@swgen.com> > > > > > > >> Computer Guy > > > > > > >> Statewide General Insurance Agency (www.swgen.com) > > > > > > > -- > > > > > > Timothy Farrell <tfarr...@swgen.com> > > > > > > Computer Guy > > > > > > Statewide General Insurance Agency (www.swgen.com) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
