Hi Chris,
The sfJobQueuePlugin will work for some basic actions, like fetching  
rss feeds or sending emails. I tried to ported the plugin to an 1.2  
version, but i had to stop my work on it then and could not implement  
everything i wanted. But it's pretty easy to create your own "rss  
feed" handler and do your stuff.
This plugin does nothing more than calling symfony tasks via "exec"  
commands. When you work with this stuff some time, you will get to  
know pretty soon, that PHP is not the correct language to manage and  
trigger shell commands. It feels like an hack and this was one of the  
reasons, why i had to abort my work.
But here a quick workflow of this plugin:
- the job queue manager has to be started (it runs in an endless loop,  
like a demon)
- this manager checks every minute, if new tasks should be done. If  
yes, they are called via exec and pushed to an background process  
(this is quite problematic, because you are loosing control of this  
process then).

The better way is to create complete message broker applications like  
ActiveMQ for Apache or RabbitMQ for Erlang etc. The big ones out  
there, like Facebook and Twitter etc. do all stuff, which has nothing  
to do with the frontend in this way. But this setup might be a big  
overkill for smaller projects.

Grüße :)
Frank


Am 24.06.2009 um 22:02 schrieb Stefan Koopmanschap:

> 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 <christ...@weyands.net 
> > 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 symfony-users@googlegroups.com
To unsubscribe from this group, send email to 
symfony-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/symfony-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to