Simetrical wrote:
On Wed, Jul 16, 2008 at 2:32 PM, DJ Bauch dj.bauch@gmail.com wrote:
Basically, I am flushing the output before running anything from my job queue. I frequently have a non-empty job queue, and have found that the modification lets the browser see the page much faster than when I run some jobs first. Is there any reason not to suggest this as a change to the code base? It made quite a dramatic improvement on my wiki when I made the change, although perhaps things are different with Linux/Apache/MySQL?
Well, I don't know, but here's a guess, based on the comment there. What happens if, in your setup, some error occurs during job queue processing (say a deadlock, or a database server crash, etc.) and the transaction is rolled back? The page will already have been output, so no error will be displayed. The page can only safely be displayed after all database activity is finished.
Job queue processing is meant to be transparent, so should *not* show an error message to the end-user when processing unrelated background jobs.
A more general issue is to confirm whether the background processing continues correctly if the connection gets aborted before it's complete -- which is more likely if flushing output before this is done.
I don't see why the job queue needs to be using the same transactions as the main page activity, if it is. If there aren't other reasons here I'm missing, your change would be fine if all transactions were committed, then the page was output, then new transactions were started for the job queue. In your version of the code, I don't think that's what's happening, since presumably the main transactions are only committed at $factory->shutdown().
Indeed, someone want to check what's going on in there? :)
-- brion