Is there any way to start/stop background processes from inside Drupal?
I'm currently writing a module that has to continuously monitor a socket connection for events coming from a remote server.I thought about using hook_cron(), but I'm afraid that the infinite (or continuous) loop of my event handler would tie out other modules that use hook_cron().Another alternative would be to use batch api, but do batch processes run in the background?
Thanks in advance,
Leo
1 year 39 weeks ago
You might want to think about queue, which has been backported to D6. Here
are rough notes from John VanDyk's drupalcon sf preso on batch v. queue:
//
when to use batch:
- when you're doing something that will exceed php's time-out
- when you're writing something that could get large
- when you want to give users feedback on what's going on
when to use queue
- when you want to stash things for later processing
- when you want to distribute computing
- when you want to run queue "with a twist" (conditional outputs, other
processes kicked off, etc)
//
...not that those were particularly useful to your question, but they're a
basis. There are some details instructions in drupal_queue.module's
readme.txt (the backport from D7) that will help you decide whether running
a queue under a separate crontab (or even using drush) makes sense. If I
were in your position, I'd lean heavily in that direction not only for the
"offswitch", but for the option of distributing that computing down the
road, which is possible with queue.
regards/BF
An alternative solution is to write a lightweight php file that runs
via command-line php and can write to the Drupal database.
You start off your file with
<?php
require_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
And then you have full access to the Drupal environment including
db_query to be able to read/write information in the Drupal
environment.
Regards,
Greg?>
I'm quite frustrated with the Form API right now, so please forgive my tone.
I've got a form that has a bunch of inputs, all of them multiselects, that allow the user to choose what classes to see in our schedule.(our class schedule is in an external database). I've got a bunch of code in the form_submit function that builds a very elaborate sql query to get the list of requested classes.
Unfortunately, the form_submit function is not actually permitted to display anything except through drupal_set_message().
So I have to either pass my complicated sql query, or all the contents of the form fields to some other page through $form_state['redirect'].
How do I do that without shoving it all into the querystring?
Right now, I'm looking at the performance issues of:
A: storing the query as a string in the database with a query_id, then sending a query_id in the redirect,
B: storing the result of the query in the database with a result_id, then sending a result_id in the redirect.
Is there some other way to accomplish what I want?
p.s. I've looked at the search module, it basically shoves the form input into the querystring of the redirect. That'll work for a single input, but multiple array inputs will be a huge pain.
Sam
This is an old thread, so I'm not sure it's still relevant, but if so check out the Background Process module: http://drupal.org/project/background_process
This is an old thread, so I'm not sure it's still relevant, but if so check out the Background Process module: http://drupal.org/project/background_process
Post Comment