Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 986741

Summary:	Too many concurrent long-running database operations hang the server
Product:	[Retired] Zanata	Reporter:	Damian Jansen <djansen>
Component:	Performance	Assignee:	Patrick Huang <pahuang>
Status:	CLOSED UPSTREAM	QA Contact:	Zanata-QA Mailling List <zanata-qa>
Severity:	high	Docs Contact:
Priority:	medium
Version:	development	CC:	sflaniga, zanata-bugs
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-07-31 01:47:39 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	988202

Description Damian Jansen 2013-07-22 02:01:40 UTC

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.

Comment 1 Sean Flanigan 2013-07-22 04:34:05 UTC

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.

Comment 2 Damian Jansen 2014-03-06 04:52:52 UTC

The rate limiting task bug988202 will likely fix this - test this when that's done.

Comment 3 Sean Flanigan 2014-03-06 07:03:51 UTC

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).

Comment 4 Zanata Migrator 2015-07-31 01:47:39 UTC

Migrated; check JIRA for bug status: http://zanata.atlassian.net/browse/ZNTA-541