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
-~----------~----~----~----~------~----~------~--~---

Reply via email to