I would like the job to terminate on leaving the page. I can easily
achieve this via an unload event that notifies the server via ajax
that the job needs cancelling. This would also prevent multiple jobs
running if the page is refreshed.
Using XML-RPC certainly looks better than using the database if I am
running my background job via a separate web2py process. Thanks for
that as I had not come across this before and it will be very useful.
However re my original post it still seems simpler code to run the
background job in threads within my web2py controller. Is there some
architectural reason why this is a bad idea?
On Jan 3, 6:29 pm, PhE <philippe.entzm...@gmail.com> wrote:
> With your second alternative your browser needs to keep the Ajax
> connexion open.
> If the connection is closed what will happen to your thread ? I don't
> master web2py internals but if the client it not there anymore, I
> think the server could kill the server part of the connexion (so kill
> your thread).
> If the page is reloaded twice or more, you will have 2 or more thread
> running ?
>
> What about a separate process (think about a "daemon") that will
> "listen" for job to be executed ?
> The communication should not be by direct SQLite queries but with XML-
> RPC calls.
> Those calls could also handle "session" communication.
>
> On 3 jan, 17:59, apple <simo...@gmail.com> wrote:
>
>
>
>
>
>
>
> > I want an execute button. This starts a multi-threaded background
> > process that scrapes data from 100 web pages. While it is scraping I
> > want an "execute" web page that shows a running total of the number of
> > pages scraped; and confirms when the process has completed.
>
> > If one uses threads in the execute controller it does not work. If you
> > join the threads then this blocks the controller until execution is
> > complete, and the execute view page only gets shown at the end of
> > execution. If you don't join the threads then web2py kills them all
> > when it reaches the return at the end of the controller.
>
> > The manual and a previous forum discussion suggest running a separate
> > web2py instance i.e. subprocess.Popen("c:/python27/python %s/web2py.py
> > -S scraper -M -R %s" %(os.getcwd(), os.getcwd()+"/applications/scraper/
> > modules/execute.py -A " str(session.scraperid))+" "+str(processid)",
> > shell=True). However this requires a separate web2py process. Also the
> > subprocess has no access to session variables so you need to use the
> > database to communicate between the two. This means database reads
> > every time the web page polls for latest status.
>
> > An alternative would be an ajax call from execute view to a controller
> > that starts the threads and joins them. This would keep it all within
> > the same web2py instance and retain access to session variables. It
> > requires less code and is simpler.
>
> > Are there any downsides to the second alternative?
