It looks like there may be an issue with the DB files created with DB Doctor in recovery mode. This is the scenario that results in the OutOfMemory exception problem (using Object DB 2.5.4_04):
1. We instruct Object DB to create a 1Gb DB file on initial start-up using:
<database> <size initial="1024mb" resize="256mb" page="2kb" />
This happens as expected.
2. We use the DB file to store about 540 thousand records. At this stage there is no problem when searching and updating.
3. We run DB Doctor in recovery mode to generate a recovered DB file. No schema (and index) changes - just testing the use of DB Doctor to check DB files during package installation. We get the recovered file, but it is much smaller - see listing below where SystemDB.odb is the 1Gb file created originally and SystemDB.odb.rpmnew is the recovered DB file generated by DB Doctor:
[root@localhost totalrecall]# ls -al db total 1085048 drwxr-xr-x 3 totalrecall totalrecall 4096 Mar 11 12:40 . drwxr-xr-x. 8 totalrecall totalrecall 4096 Mar 11 08:36 .. -rw-r--r-- 1 totalrecall totalrecall 1339 Feb 19 16:35 objectdb.conf -rw-r--r-- 1 root root 1073741824 Mar 11 12:40 SystemDB.odb -rw-r--r-- 1 root root 214695936 Mar 9 15:16 SystemDB.odb.rpmnew [root@localhost totalrecall]#
4. We force the application to use the the DB file generated by DB Doctor.
5. Try a searching and all appears to be fine.
6. Do an update, any update to any record and all appears to be fine.
7. Do a search after the update, any search and CPU use shoots up to > 100% use, memory use shoots up and eventually we get:
Exception in thread "Thread-30" java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOfRange(Arrays.java:2694) at java.lang.String.<init>(String.java:203) at com.objectdb.o.BYR.N(BYR.java:1221) at com.objectdb.o.BYR.N(BYR.java:522) at com.objectdb.o.STT.m(STT.java:115) at com.objectdb.o.TYR.readStringValue(TYR.java:880) at com.arunta.base.db.RecordingMetaData.__odbReadContent(RecordingMetaData.java:1) at com.objectdb.o.MMM.ag(MMM.java:1064) at com.objectdb.o.UTY.aH(UTY.java:1305) at com.objectdb.o.UTY.aG(UTY.java:1277) at com.objectdb.o.ENH.b(ENH.java:102) at com.objectdb.o.LDR.J(LDR.java:800) at com.objectdb.o.LDR.z(LDR.java:219) at com.objectdb.o.OBC.aP(OBC.java:1058) at com.objectdb.o.OBC.aN(OBC.java:963) at com.objectdb.o.OBC.UM(OBC.java:795) at com.objectdb.o.QRR.h(QRR.java:288) at com.objectdb.o.QRR.f(QRR.java:177) at com.objectdb.jpa.JpaQuery.getResultList(JpaQuery.java:716) at com.arunta.base.db.RecordingMetaDataDAO.find(RecordingMetaDataDAO.java:424) at com.arunta.app.services.RecordingService.find(RecordingService.java:247) at com.arunta.base.search.Searcher.searchDb(Searcher.java:473) at com.arunta.app.embeddedui.search.SearchControl$3.construct(SearchControl.java:852) at com.arunta.app.embeddedui.common.util.SwingWorker$2.run(SwingWorker.java:149) at java.lang.Thread.run(Thread.java:722)
If we revert back the application to use the original DB file, the 1Gb file all works fine.
Can you please advise on what the problem may be and how we can avoid it.
I would like this opportunity to suggest to you to modify DB Doctor to create a file that has the opriginal size as the DB input file (or size as specified in the configuration). We create a large file deliberatly as we do not want Object DB to increase its size during operation and end up with segments of the file all over the disk.
Thank you
Emil