Description of problem: If an admin downloads many TMX files simultaneously, the max database connections will be exceeded for too long a period, preventing users from interacting with Zanata. Version-Release number of selected component (if applicable): Dev How reproducible: Moderate, requires a largely filled database. Consistent. Steps to Reproduce: 1. Click Projects 2. Middle click the Export All Projects as TMX 10 times 3. Attempt to use Zanata as a normal user (in another browser, perhaps) Actual results: Browser is "connecting" indefinitely Expected results: Probably shouldn't allow that many TMX downloads.
This can potentially happen with any long-running database operation, including CopyTrans, particularly if streaming ResultSets are used (assuming mysql). We should consider creating a global semaphore which will constrain the number of such DB operations which Zanata will attempt at any one time. Any code which wants to create a streaming ResultSet should acquire a semaphore permit first.
The rate limiting task bug988202 will likely fix this - test this when that's done.
As part of bug 988202, we do plan to limit each API user's number of active API calls, but that won't prevent multiple TMX exports, especially if performed by multiple users. (Or if the users are using the web for TMX export, rather than the REST API.) We will still need a separate semaphore for the TMX export feature, preferably a configurable one. (CopyTrans no longer holds on to the database connection for long periods of time, so it can probably be ignored here.) But the semaphore still needs to be a shared semaphore, for use by other long-running operations (eg our backup feature, if we implement it).
Migrated; check JIRA for bug status: http://zanata.atlassian.net/browse/ZNTA-541