-
Type:
Bug
-
Resolution: Fixed
-
Priority:
High
-
Affects Version/s: 3.3.2
-
Component/s: Navigation - Export
-
Environment:
ystem Date mardi, 08 nov. 2005
System Time 17:16:51
Java Version 1.4.2_09
Java Vendor Sun Microsystems Inc.
JVM Version 1.0
JVM Vendor Sun Microsystems Inc.
JVM Implementation Version 1.4.2_09-b05
Java Runtime Java(TM) 2 Runtime Environment, Standard Edition
Java VM Java HotSpot(TM) Client VM
User Name adminweb
User Timezone Europe/Paris
User Locale français (France)
System Encoding Cp1252
Operating System Windows 2000 5.0
OS Architecture x86
Application Server Container Apache Tomcat/5.0.19
Database type oracle
Database JNDI address java:comp/env/jdbc/JiraDSystem Date mardi, 08 nov. 2005 System Time 17:16:51 Java Version 1.4.2_09 Java Vendor Sun Microsystems Inc. JVM Version 1.0 JVM Vendor Sun Microsystems Inc. JVM Implementation Version 1.4.2_09-b05 Java Runtime Java(TM) 2 Runtime Environment, Standard Edition Java VM Java HotSpot(TM) Client VM User Name adminweb User Timezone Europe/Paris User Locale français (France) System Encoding Cp1252 Operating System Windows 2000 5.0 OS Architecture x86 Application Server Container Apache Tomcat/5.0.19 Database type oracle Database JNDI address java:comp/env/jdbc/JiraDS
-
3.03
When we start exporting a large number of issues to Excel (we tried to export all fields of 14000 issues), JIRA throws a java.lang.OutOfMemory.
On less than 1000 issues, the process finishes.
It means that the memory usage of the Excel export is not constant and depends on the export volume.
It's a very big problem since a lot of users are interesting in using the Excel export every day, and the database is growing a lot.
Could you solve this problem quickly ?
- is related to
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
JRASERVER-10404 Make 'views' of content (single issue and search request) pluggable, and rewrite default implementations in velocity
- Closed
