I said it might take a few seconds, I didn't say it was computationally heavy.
justin randell wrote:
hi,
2010/1/21 Peter Rundle <[email protected]>:
It's alleged Ken Foskey did scribe:
You could try closing STDOUT which will tell apache that your script has
stopped output.
This is interesting idea, I think I will give that a try if I can find out
how to get hold of the STDOUT file pointer.
In perl I executed a background task with an system( "command &" ); to
perform the background tasks. I then emailed a reponse to the client to
tell them the job was done.
That's the kinda thing I need to do. I was hoping to avoid doing a system
command because the action I need to do is easily done right away in the php
(database connection is already open with right privileges etc). I just need
to let the browser know that there's not gonna be any more output, it's
finished go and render the page and be happy. If I call a system command I
have to pass all the info I current have in the application open a new
connection to the database in the other process etc. Doable but if I can
just close the network connection that'd be neater.
Cron jobs aren't the go, this is an event driven task that needs to happen
when the event occurs, not some minutes/hours later when the cron jobs wakes
up at the specified interval.
i'm interested in the requirements that led to this problem. to be
honest, it sounds a bit fishy from a design point of view. maybe it
just has to be that way, but requiring big chunks of computation that
have to happen straight away, are triggered by network requests (that
don't need to see the results of the processing in real time) is not
something i'd allow unless absolutely necessary. at the very least,
i'd want the resource that triggers that access controlled.
sorry if this is a blind alley, but this is a problem i would be
trying *not* to solve if possible. any architecture that requires this
will be harder to scale and easier to DOS, which might not bite you
straight away, but will probably bite you at some point.
so, the client request that triggers the processing doesn't see the
results. what is it about the app that requires it to happen straight
away? is it a consistency issue - no other client should see the site
before the processing is done? would it be enough for other clients to
just see the site with all or none of the processing finished?
cheers,
justin
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
