That is not the case. Let me better clarify my purpose in pseudo code.
How about changing line 277~282 of gluon/newcron.py from:
elif action:
commands.extend(('-P',
'-N',models,
'-S',app+'/'+command,
'-a','"<recycle>"'))
shell = True
to:
elif action:
urllib.urlopen('http://localhost:%s/%s/%s' % (
server_port, # but how to know this value?
app,
command
) ).read()
continue
I don't think request.env.server_port is available in the newcron.py
context. Does it?
Regards,
Iceberg
On Jul 28, 8:46pm, mdipierro <[email protected]> wrote:
> You can do what you suggest. You cant find the post in
> request.env.server_port
> You see all variables here :
>
> http://web2py.com/examples/simple_examples/status
>
> yet I feel there may be a better way using a queue and a background
> process (without CRON). It depends on what this is really for.
>
> On Jul 28, 5:30 am, Iceberg <[email protected]> wrote:
>
>
>
> > But cache.ram is theoretically faster than cache.disk.
>
> > Besides, what is the pros and cons of using urllib.urlopen('http://
> > localhost:8000/myapp/...').read() to visit an action? My draft:
>
> > Pros:
> > - There is no need to app's environment for the cron job to run, hence
> > avoids potential locking problems radically.
> > - Just a urlopen(...).open() is considered less overhead than a full
> > "web2py -P -N -S ..."
>
> > Cons:
> > - I did not find a way to auto detect which port the main web2py
> > process is running at.
>
> > On Jul 28, 6:06pm, Massimo Di Pierro <[email protected]> wrote:
>
> > > The solution is cache.disk
>
> > > > PS: Using cache.disk() is not (yet) a workaround for
> > > web2py_win.zip. I
> > > > report a bug about that in another post.
>
> > > I do not recall this. Can you tell us more and point to the post?
>
> > > Massimo
>
> > > On Jul 28, 2010, at 4:48 AM, Iceberg wrote:
>
> > > > Scenario: In one of my small enterprise app, my action is time
> > > > consuming, so I use cache. Furthermore, I setup a cron job to "touch"
> > > > this action frequently, hoping that other real users will be benefited
> > > > by always have cache hits. Example as below.
>
> > > > @cache(request.env.path_info,time_expire=1800,cache_model=cache.ram)
> > > > def index():
> > > > result = do_a_time_consuming_job()
> > > > return {'result': result}
>
> > > > # the crontab file
> > > > */30 * * * * root **default/index
>
> > > > Nice plan, huh? But it has no effect. Because each time the cronjob is
> > > > seemingly invoked in a separated process space (via "web2py -P -N -M -
> > > > S myapp/default/index -a <recycled>"), so the main process's cache.ram
> > > > is not touched.
>
> > > > So, is it possible to change the implementation, let the "visit my
> > > > action" cronjob be done by this way?
> > > > urllib.urlopen('http://localhost:8000/myapp/default/index').read()
>
> > > > By the way, my current workaround is to write my crontab file like
> > > > this:
> > > > */30 * * * * root
> > > > **applications/myapp/cron/trigger.py
> > > > and my trigger.py is based on urlopen(...).read() mentioned above.
> > > > The workaround works, but I don't like the fact that it hardcode the
> > > > app name (as well as the port).
>
> > > > PS: Using cache.disk() is not (yet) a workaround for web2py_win.zip. I
> > > > report a bug about that in another post.
>
> > > > So, what's your opinion?
>
> > > > Regards,
> > > > Iceberg
>
> > > > --
> > > > mail from:GoogleGroups "web2py-developers" mailing list
> > > > make speech: [email protected]
> > > > unsubscribe: [email protected]
> > > > details :http://groups.google.com/group/web2py-developers
> > > > the project:http://code.google.com/p/web2py/
> > > > official :http://www.web2py.com/
