Objectdb server out of heap space

I have had a server crash with the following stack trace:

java.lang.OutOfMemoryError: Java heap space
at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:57)
at java.nio.ByteBuffer.allocate(ByteBuffer.java:331)
at sun.nio.cs.StreamEncoder.<init>(StreamEncoder.java:195)
at sun.nio.cs.StreamEncoder.<init>(StreamEncoder.java:175)
at sun.nio.cs.StreamEncoder.forOutputStreamWriter(StreamEncoder.java:59)
at java.io.OutputStreamWriter.<init>(OutputStreamWriter.java:111)
at java.io.PrintWriter.<init>(PrintWriter.java:148)
at java.io.PrintWriter.<init>(PrintWriter.java:131)
at com.objectdb.o.STH.M(STH.java:660)
at com.objectdb.o.LGR.n(LGR.java:375)
at com.objectdb.o.LGR.h(LGR.java:205)
at com.objectdb.o.LGR.g(LGR.java:181)
at com.objectdb.o.HND.M(HND.java:263)
at com.objectdb.o.HND.run(HND.java:150)
at java.lang.Thread.run(Thread.java:722)

I don't understand why this should happen - a server process has full control of its resources, and so should never end up in a situation where it runs out of memory like this.  This could be a serious problem for out deployment of objectdb in production situations. 

> a server process has full control of its resources, and so should never end up in a situation where it runs out of memory like this.

Servers that run on Java JVM, such as the ObjectDB server, are limited to the maximum heap size of the JVM, so they cannot have full control of resources. However, you can easily increase the maximum JVM heap size (which is usually much lower than your physical machine RAM) using the -Xmx JVM option, if necessary.

I'm well aware of VM options for tuning memory.  A server process, if it is to be reliable, should be able to monitor memory use, and check the sizes of requests for data so as to keep within the bounds of resources, failing gracefully with appropriate messages if there are requests for too much data.  What is NOT acceptable for a reliable server process in production is for the server as a whole to die because of lack of memory:  refusing connections and failing individual requests is acceptable, but having the whole server die is not (at the very least put in a watchdog process to restart the server!)

Incidentally, it might help those of us who have a need to deal with issues such as deadlocks and resource errors if the code were not obfuscated, so we can have some idea of what is going on.  Perhaps even some non-disclosure agreement would allow access to source code.  That way you may find you get far clearer descriptions of what the issues actually are, and even fixes.  It would be reassuring for those of us who are trying to put your code into production use to know that we can deal with critical issues ourselves if necessary. 

We should add this ability in future ObjectDB versions, thank you for making this point clear. Meanwhile, you will have to make sure that ObjectDB is run with sufficient heap size for your needs. You may also try restarting the server in this case by setting a cron task that starts / restarts the ObjectDB server once in a while.