Details
-
Bug
-
Resolution: Fixed
-
Major
-
7.1-milestone-1
Description
When creating an object with a huge object number, we currently store null entries for all objects numbers that have no object associated. So if you create an object with id 67108863, you get 67108863 null entries. As each null is a 64-bit pointer, this needs 512MiB memory per copy of the document. With a memory limit of 1GiB, this is enough for one copy but not two. Saving thus still works but any code that wants to display the document or a part of it creates a clone which is both slow and ends in an OOM error. Object numbers till close to 2³¹ should be supported given enough memory and thus give a memory usage of up to 16GiB per copy of the document.
A possible fix seems to be to store the objects in a Map<Integer, BaseObject>, though this might not fix the performance problems unless all code is adjusted to never iterate over the full list of objects.
Steps to Reproduce:
- Create a document
- Open the object editor and add an object of any type
- Open the web developer tools and change the HTML code:
- Change name="YourClass_0_yourProperty" to name="YourClass_67108863_yourProperty" at the input of a property
- Add a new hidden input <input type="hidden" name="objectPolicy" value="updateOrCreate" />.
- Press save.
Expected Result
The document is saved successfully and can be displayed afterwards.
Actual Result
While the document is saved to the database, the save action fails with an OOM and afterwards all panes like the navigation or recent changes or other views that involve the document fail with an OOM error. It is also not possible to load the object editor again to remove the object.
Attachments
Issue Links
- causes
-
XWIKI-19494 XWikiDocument objects inserted through #readObjectsFromForm can break it
- Closed
- is duplicated by
-
XWIKI-14870 Deleting objects might create persistent NULL object in the object list
- Closed