Bug 995964

Summary:	Critical performance issues with deleting large TMs
Product:	[Retired] Zanata	Reporter:	Damian Jansen <djansen>
Component:	Component-Persistence	Assignee:	Carlos Munoz <camunoz>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Zanata-QA Mailling List <zanata-qa>
Severity:	high	Docs Contact:
Priority:	high
Version:	development	CC:	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:	2013-11-27 03:31:35 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:

Description Damian Jansen 2013-08-12 05:12:35 UTC

Description of problem:
The test TM is of 250MB. Deleting this after it was installed caused repeated memory exceptions

Version-Release number of selected component (if applicable):
Dev

How reproducible:
Moderate, always

Steps to Reproduce:
1. Go to Administration, Translation Memory
2. Install a very large TM - test was of 250MB
3. Press Delete / Clear
4. Press OK

Actual results:
* java.lang.OutOfMemoryError: Java heap space
* java.lang.OutOfMemoryError: GC overhead limit exceeded

Expected results:
Deleted entries.

Additional info:

Comment 1 Damian Jansen 2013-08-12 05:15:16 UTC

This also seems to lock down the server for some indeterminate amount of time, preventing user access.
User is presented with:

JBWEB000309: type JBWEB000066: Exception report

JBWEB000068: message JBWEB000247: Filter execution threw an exception

JBWEB000069: description JBWEB000145: The server encountered an internal error that prevented it from fulfilling this request.

JBWEB000070: exception

javax.servlet.ServletException: JBWEB000247: Filter execution threw an exception
	org.zanata.seam.interceptor.MonitoringWrapper.doFilter(MonitoringWrapper.java:70)
	org.zanata.servlet.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:63)
JBWEB000071: root cause

java.lang.NoClassDefFoundError: Could not initialize class org.jboss.seam.mock.MockViewHandler
	org.jboss.seam.mock.MockApplication.<init>(MockApplication.java:228)
	org.jboss.seam.web.ExceptionFilter.createFacesContext(ExceptionFilter.java:146)
	org.jboss.seam.web.ExceptionFilter.endWebRequestAfterException(ExceptionFilter.java:92)
	org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:70)
	org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
	org.zanata.seam.interceptor.MonitoringWrapper.doFilter(MonitoringWrapper.java:70)
	org.zanata.servlet.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:63)

Comment 2 Carlos Munoz 2013-08-13 01:18:06 UTC

Made TM delete asynchronous. 
In order to delete a TM, the process is now two-step: 
1. Clear the TM
2. Delete the TM

See:
https://github.com/zanata/zanata-server/pull/122

Comment 3 Damian Jansen 2013-08-15 05:51:28 UTC

Line 108 of TransMemoryDAO.java uses setFetchSize (rather than setMaxResults) which is a hint and is ignored by the sql driver (unless some hackery with autocommit is imposed).
The result of this is the batch size is the entire TM.

Replacing this line with .setMaxResults(batchSize) works.

Comment 4 Damian Jansen 2013-08-15 05:53:58 UTC

Also, the end result of this size batch is a database timeout while the query is generated.

Comment 5 Carlos Munoz 2013-08-15 05:54:22 UTC

Fix issue with the clearing of large TMs.

Reduce the batch size to a smaller size.
Use the correct method when setting up TU batches to clear.

See:
https://github.com/zanata/zanata-server/pull/129

Comment 6 Damian Jansen 2013-08-28 04:32:10 UTC

Verified at 6cffb1ba3ce14c4c5803c1e40556bd8d58a60363

Comment 7 Sean Flanigan 2013-11-27 03:31:35 UTC

Closing VERIFIED bugs which predate Zanata 3.1.2.