Details
-
Suggestion
-
Resolution: Won't Do
-
None
-
Windows Server 2003 / MySQL 4.1 / Confluence with 512mb JVM heap.
-
1
-
1
-
Description
Hi everyone,
This is Michael Andreacchio from the Confluence team. Thank you for your interest in this suggestion.
After reviewing this suggestion we have decided that we are unlikely to prioritise it for the foreseeable future. The age of this issue versus the interest and the effort needed to implement just don't give it enough priority for us at the moment. As such, we are closing this ticket to help reflect these priorities to customers.
You can read more about how we prioritise what to implement here.
To learn more about our recent investments in Confluence Data Center, please check our public roadmap and our dashboards containing recently resolved issues, and current work and future plans.
Kind regards,
Confluence Data Center
We have ~1G of attachments.
Simultaneously migrated:
- Confluence from 2.2.5 to 2.2.9
- the attachments from the file system to the DB
- JVM from 256mb max to 512mb max.
The backups now throw an OutOfMemory exception. Even if I de-select the option "Backup Attachments" Confluence still attempts to load the entire recordset into Hibernate memory, resulting in the exception.
I understand that we can use a MySQL backup and a replica of the Confluence Home directory, however an integrated backup would be nicer for our system – and even an automated backup with attachments would be very nice to have. We have been stung in the past with using this restore process failing (since appropriate changes to the database schema are not made when you restore direct to the DB instead of using Confluence).
I propose a change to the backup process to use a streamed-out ZIP file, or at the least not requiring full load into RAM of the entire JVM recordset (instead of doing an eager load of the db, just load one record at a time ... )
Attachments
Issue Links
- is duplicated by
-
- Closed
- relates to
-
- Closed
