You are probably right about that. I am hoping to have to do that a bit later rather than sooner though. :) I figured out why my echoes wouldn't flush... It is typical really :)
With autoRender = false I have tried a small test like this: echo 'Hi there'; flush(); @ob_flush(); sleep(3); // no more echoes. When I browsed this action (or curled it) I never saw anything before the 3 seconds were up. And like I said earlier, I have also added several other combinations of ob_* and flush calls to the mix with no change. Then it struck me that I probably needed to echo this instead: echo "Hi there \n"; // notice the newline added to the end of the string. Now I can see the reply before the 3 seconds begin. /Martin On May 7, 4:20 pm, "Dardo Sordi Bogado" <[EMAIL PROTECTED]> wrote: > Well, I think you can put $this->autoRender = false; an do echo but > the real thing you should consider is implementing some batch > processing and a queue system if you are planing to grow that big. > > On Wed, May 7, 2008 at 11:02 AM, [EMAIL PROTECTED] > > <[EMAIL PROTECTED]> wrote: > > > I will not know that. but once I know that the contents of the POST > > looks OK I want to reply... anything that happens after that (database > > problem or some other internal error) is "my fault" and not an issue > > relevant to the external server. > > > I just need to "sign for the package" before opening and examining all > > the contents. If an item is missing the messenger can't do anything > > about that. I still need to call whoever send the package to get that > > corrected. (feeble analogy, I know) > > > There is no way I can keep the external server hanging while I > > possible look through >300'000 of rows of data, call other external > > systems or some other time-expensive task. When logs and data grow I > > can see it becoming a real problem very quickly. On day one I know we > > will have to assign these incoming calls to one of 380'000 users > > stored in our MySQL database. > > > On May 7, 2:28 pm, "dr. Hannibal Lecter" <[EMAIL PROTECTED]> wrote: > > > I don't understand. How can you know it's "All OK" if your processing > > > is not done yet?? > > > > On May 7, 12:38 pm, "[EMAIL PROTECTED]" > > > > <[EMAIL PROTECTED]> wrote: > > > > Hi everyone, > > > > > I am trying to improve the performance of an API I provide to other > > > > systems. Requests that post data to my application now have to wait > > > > for my processing to finish (parsing, saving model-data...) before > > > > they see a simple "All OK" response. > > > > > Since the processing is governed by the controller I thought that I > > > > could echo the response and then flush the buffers and never render > > > > any final view for these actions. But... I can get it to work. I have > > > > tried many combinations of ob_* calls and flushes, following both old > > > > code I have used for outputting images and a few examples and hits > > > > found online and at php.net. > > > > > Maybe flushing is not enough? I am a bit lost here. Has anyone got any > > > > example to share where they can let the browser (or other script) see > > > > the results before all processing is complete? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---