I had to create a "daemon" that uses lots of Propel classes and as you said, I run into a lot of memory issues and had to create a script that watches my script. But in my case, I don't have much option since I rely so much on the Propel models.
Pablo On Wed, Feb 4, 2009 at 10:05 PM, John L. Singleton <[email protected]> wrote: > > Hi Jacob, > > Thanks for the response! > >> I know this isn't what you want to hear but.. >> >> PHP is an absolutely awful language when it comes to doing anything >> but web-related work. Well, it's not the language per-se, it's the >> runtime. Even if you figure out how to get your database connections >> reconnected you will run into problems with the PHP garbage >> collector. You will have memory leaks that are impossible to fix. >> You'll end up coding a script to watch your script. > > That's good point. I hadn't really considered the memory angle and I'm > not opposed to just implementing it in Java. The only issue that > kinda, hurm, sucks, is the issue of bypassing my primary persistence > layer (Propel). My attempt to code it in PHP was just to keep things > in PHP... The idea of having a batch script doing an external task was > just a bit too tantalizing, I suppose. But on the plus side, I can > ditch FAM, since Java has built in classes for this sort of thing. > Some of the processing was in Java anyway, on account of the fact that > I'm processing images and Java has superior support for doing non- > trivial image manipulation. > >> Beyond that, you could extend sfPropelDatabase with your own database >> class that reconnects before returning. You (should) just need to >> override the getConnection() method. You can specify the connection >> class in databases.yml. > > > I was afraid of that. Not that I'm opposed to extending the class, it > just seems like I'd get getting into somewhat unsupported territory. > Back to the drawing board. That's for the memory issue comment -- that > has doubtfully helped saved me a great deal of troubleshooting down > the road. > > Best, > > JLS > > On Feb 4, 2009, at 6:15 PM, Jacob Coby wrote: > >> >> >> On Feb 4, 2009, at 7:51 PM, John L. Singleton wrote: >>> The issue is that the next_fam_event call blocks indefinitely. If PHP >>> had threads, I could easily just keep a connection alive in the >>> background, but alas, it doesn't. My other option (of course) is to >>> switch to a polling method, but that wastes CPU and database >>> resources. This is a fairly common pattern which I've used countless >>> times in other languages... Also, async JMS messaging generally works >>> something like this, only you specify callbacks to handle events and >>> so on. I just can't find a way to make it work with Symfony. But >>> thanks so much for responding! >> >> I know this isn't what you want to hear but.. >> >> PHP is an absolutely awful language when it comes to doing anything >> but web-related work. Well, it's not the language per-se, it's the >> runtime. Even if you figure out how to get your database connections >> reconnected you will run into problems with the PHP garbage >> collector. You will have memory leaks that are impossible to fix. >> You'll end up coding a script to watch your script. >> >> If you have anything that needs to run as a daemon or is memory- >> sensitive or needs to process large amounts of data quickly, use a >> language better suited to the task. >> >> With that out of the way, here are some ideas that may or may not >> work: >> >> $dbm = sfContext::getInstance()->getDatabaseManager(); >> $dbm->shutdown(); >> $dbm->initialize(); >> >> At least then you're dealing with the same object that sf uses >> internally. >> >> Beyond that, you could extend sfPropelDatabase with your own database >> class that reconnects before returning. You (should) just need to >> override the getConnection() method. You can specify the connection >> class in databases.yml. >> >> -- >> Jacob Coby >> >> >> >> >> >> >> >> > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" 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-devs?hl=en -~----------~----~----~----~------~----~------~--~---
