The solution of Stefan is perfect.  If you were executing through an
exec() call, then a simple queue will fit your needs just fine.  If no
need to execute a task, then just add it to the queue, which is
basically a list of tasks to be executed:

1. clear cache task
2. custom db cleaning task
3. custom db optimizing task
4. caching RSS feeds task

Then you would make a task that reads the queue and runs the tasks
accordingly.  Using the symfony task framework, it is very easy to run
a task inside another task.  In your queue processing task, you would
write the following:

$task = new customDbCleaningTask ($this->dispatcher, $this-
>formatter);
$task->run ($arguments, $options);

So, to get started, all you really need is a table for the queue and a
queue running task.


James


On Jul 6, 10:58 am, Bert-Jan <[email protected]> wrote:
> I'm using Gearman for moving stuff to the background. Absolutely
> wonderful stuff and very easy to deploy.
>
> Stefan Koopmanschap schreef:
>
> > Hi Christian,
> > The best option for this would be some kind of jobqueue system. There
> > are several options for this, which might or might not fit your solution:
> > There is an (old) plugin that I personally have no experience with but
> > might fit your needs which is the sfJobQueuePlugin[1]. The plugin
> > description basically describes your needs:
> > This plugins enables job queues into Symfony. Using a job queue can be
> > useful when asynchronised server-side operations have to be performed
> > (periodically grabbing a RSS feed, automatically sending emails, etc.)
> > or in environments without a cron access.
> > Alternatively, you could use external job queue systems. The best
> > known to me is the Zend JobQueue which is available in Zend
> > Platform[2]. I have experience with this one, and it seems to work
> > quite fine, though it requires you to have commercial software (and
> > the Zend software can sometimes be a burden). However, it has a lot of
> > nice features that support you in using and handling jobs, and could
> > be a good option if you have budget for commercial software for your
> > server.
> > Perhaps if you google around, there are various other alternatives to
> > the above-mentioned two, but these are two that immediately came up
> > for me as serious solutions for what you are trying to do.
> > Stefan
> > [1]:http://www.symfony-project.org/plugins/sfJobQueuePlugin
> > [2]:http://www.zend.com/platform
> > On Wed, Jun 24, 2009 at 1:32 PM, Christian Weyand
> > <[email protected] <mailto:[email protected]>> wrote:
>
> >     Hello everyone,
>
> >     we've built a feature where we need to perform a bunch of external
> >     operations (reading rss-feeds) when a user triggers a certain action.
> >     This is an asynchronus process, so the user  has not to be bugged
> >     while we import/parse the data - and it might take some time until all
> >     feeds are parsed..
>
> >     Till now we've basicly used "exec(' php %pathtobatchfolder%/
> >     doanything.php +someparameters') to initiate the process. The user can
> >     browse the page without any drawbacks.. once the script is finished,
> >     the user will see the changed information once he visits the same page
> >     again.
>
> >     Drawback of this solution are the ApacheThread we use for each "exec-
> >     process". This might cause some trouble by simply eating all available
> >     apache threads if the page is heavily visited... #fail
>
> >     Now the question to you guys:
> >     How're you handling asynchronus tasks in your applications? We're
> >     thinking about some solutions right now..
>
> >     - use fcgi_php instead of exec, this will save us from wasting
> >     ApacheThreads.. one thing we didn't figure out yet: passing parameters
> >     to the script we want to execute..
>
> >     - don't instantly exec() the script, save the action in the Database
> >     and let a cronjob work on them... -> CLI Task, but we're far away from
> >     realtime..
>
> >     - ... anyone got some hints?
>
> >     Greetings,
> >     Christian
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"symfony users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/symfony-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to