Do you have permissions on the machine to create sockets? If so, and you want an all PHP solution, you could create an extremely small PHP script that runs as a daemon (the "server"), and create a socket with it, from which this script will continuously wait for (any number of) clients to connect.
When a user performs some action on your website that executes some PHP code in your symfony application (the "client"), that PHP code can connect to the socket server and tell it to execute some command, then close the connection to the server (without caring about what the server does with said command). When the server receives a command from a client, it can can exec() it into the background (or fork a child process or something). 2009/6/25 Frank Stelzer <[email protected]> > 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 > <[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 -~----------~----~----~----~------~----~------~--~---
