How to avoid proxy error when running long utility scripts

Hello. I have created an add-on for handling translations with plone.app.multilingual. It mounts a view @@bootstrap-translations to the language root folders. When the view is invoked, it creates and registers a translation for each object in the English language root for the target language. In this way, all folder structure is absolutely preserved, and the translators need only to worry about translating content. The problem is that there is no way to know how much content it will have to scaffold. I am getting a Proxy Error no doubt because of it timing out, but Zope/Plone continues executing as I can tail the logs to watch progress. It also does finally complete. I had messed around with my Apache virtual host configuration a bit to use KeepAlive and KeepAliveTimeout, but it does not have the desired effect. Also ideally I would only increase the allowed execution time for this one view rather than apply a blanket rule. Is anyone aware if there is any Plone/Zope way to request more allowable time, or would this still be overridden by the web server that sits in between? Thank you in advance for any insight.

I am using dm.zodb.asynchronous (and some JavaScript) in such situations. The general setup is as follows: the long running process is scheduled; the schedule returns an identifier and via this identifier, later requests can check whether the process has finished and (in this case) get the result. JavaScript is used to poll the server periodically to check whether the result is available - and in this case presents it; otherwise, the polling continues.

Note that dm.zodb.asynchronous maintains state in RAM; in a multi instance environment, you must therefore guarantee that all poll requests reach the same instance as the initial request.

We usually do not invoke long-running requests or processes over HTTP. We also ways refactor or wrap the functionality inside a Python script that we can call using bin/instance run somescript.py. This is more robust and offers more flexibility than going over HTTP.

-aj