Forums

I need to run\stop some class that runs on server through django's view\form

I suspect you'll need to provide one or two more details about what you're trying to achieve if you're going to get a helpful response...

Are you trying to say you want some code to run constantly in the background and then control it via forms on web pages?

Yes, that's right. I want rssReader to run continuously on server: it checks news for given time intervals. And its good to have access to its conditions through web form, for example, rssReader.start(), rssReader.stop() et c. But I cant understand how to properly run this class with django's infrastructure.

Unfortunately what you're proposing isn't as easy as it might first appear.

The first issue is that web applications aren't designed to have code constantly running in the background like that. So, you'd need to have that code running in a separate process which you started independently. Webserver code is only invoked on a per-request basis, and it's generally a really bad idea for it to use threads or fork() - this just isn't something the web frameworks are designed to handle. This applies equally to all web frameworks, including Django.

I'm not saying you couldn't knock something together and get it to sort of almost work after a fashion, I'm just saying that I think it's generally a bad idea.

So, let's say you start a separate background process which runs your RSS reader - now you want a way to communicate with that. The good news is that this is entirely possible - the bad news is that it can be tricky depending on what you want to do. My personal approach is typically to have daemons (i.e. background processes) listen for connections on a socket (typically a Unix domain socket) and invent a simple command language to have them communicate. Then the other process (the webserver in your case) can connect, send a command and disconnect again. This approach is flexible and powerful, but if you're not familiar with sockets code then it's probably not your best option.

As a simpler alternative, have your RSS reader frequently check for the existence of a magic file - on PA that would be in your home directory, say. If that file exists, it reads the contents to decide what to do. Then your Django code can simple create the appropriate file with the appropriate content and the next time the RSS reader sees that file it will be carried out. This works for most things except restarting the RSS reader process, you'd need to make other arrangements for that. You could easily wrap this process up behind a class implementation so the web code just uses a method call interface.

One tip if you use this approach - you can't be totally sure that a write() call is atomic, so I suggest creating the file with a different name, writing the content, closing the file (hence flushing the content) and then using os.rename() to move the file into place. This just reduces the scope of problems.

Of course, even using this approach you then have the issue of creating a long-running daemon process on PA, and I suspect that's not something it's really designed to support (but the staff are, of course, welcome to correct me!). I know that there's scope for periodically run background tasks, and if these are frequent enough for you then you don't even need to worry about writing a daemon - just write a script which starts up, checks for the file written by the web interface and then goes on to do whatever checks are required, and then terminates. If you need it to happen more often then I guess the periodic tasks could perhaps be made to fork away from their controlling terminal and run in the background for awhile - taking care to never spawn more than one instance at a time, of course (using a separate lock file is best for this).

Note: It's probably at least polite to check with the PA staff before kicking off background processes, as a badly-written one could cause them some issues. It's possible they might not mind as long as the process is light on resources, but presumably they implemented the limit on the number of background tasks for a good reason so it would be a good idea to check. I'm sure one of them might jump in if they don't like what I'm proposing... (^_^)

NOW, if most of that sounded like gobbledegook, perhaps you could do things a simpler way. For example, just write web server code to perform an RSS check every time a HTTP request is received and not worry about doing things in the background at all.

Hope that's some help.

Well, this sounds like what we designed scheduled tasks for. As kernie_xvid is a paying customer he can also run tasks every hour. Which should be enough definition for an something that checks RSS feeds. Is this an django management command that you want to run? something like "/home/kernie_xvid/my_django_app/manage.py check_feeds" as a hourly scheduled task could do the trick.

Ahha, I hadn't realised it was as frequently as every hour - that'll teach me for trusting my memory and not going to check.

I agree that hourly would seem more than sufficient to check an RSS feed, although I suppose it does depend on the application and what action is taken in response - RSS feeds aren't always for news aggregation, after all. Could be a feed of system events for a distributed network, for example, and you'd want pretty low latency to convert that to email alerts for failures. I agree that it would seem unlikely that this case is something like that. (^_^)

One thing that my unfortunately rather rambling and unfocussed post (like most of mine, I fear) failed to make clear was that when I mentioned using the local filesystem to store config and/or status, this could of course just as easily be something like an SQLite or MySQL DB, which might make life easier.

Or soon a PostgreSQL DB...☺

thank you