This page aims to link all the guides to Problems and Troubleshooting.
OrientDB, by default, manages edges as "lightweight" edges if they have no properties. This means that if an edge has no properties, it's not stored as physical record. But don't worry, your edge is still there but encoded in a separate data structure. For this reason if you execute a select from Eno edges or less edges than expected are returned. It's extremely rare the need to have the list of edges, but if this is your case you can disable this feature by issuing this command once (with a slow down and a bigger database size):
alter database custom useLightweightEdges=false
The reason of this issue is massive usage of sun.misc.Unsafe which may have different contract than it is implemented for Linux and Windows JDKs. To avoid this error please use following settings during server start:
java ... -Dmemory.useUnsafe=false and -Dstorage.compressionMethod=gzip ...
Don't be scared about it: your OrientDB installation will work perfectly, just it could be slower with database larger than memory.
This lock is needed in case of you work on OS which uses aggressive swapping like Linux. If there is the case when amount of available RAM is not enough to cache all MMAP content OS can swap out rarely used parts of Java heap to the disk and when GC is started to collect garbage we will have performance degradation, to prevent such situation Java heap is locked into memory and prohibited to be flushed on the disk.
This usually happens because the database has been corrupted by a hw/sw crash or a hard kill of the process during the writing to disk. If this happens on index clusters just rebuild indexes, otherwise re-import a previously exported database.
Look at: Restore admin user.
Look at: Restore admin user.
This means that probably default timeouts are too low and server side operation need more time to complete. Follow these MemoryLocker.lockMemoryPerformance-Tuning#remote_connections.suggestions]].
Your maven configuration points to the old Orient Technologies repository: http://www.orientechnologies.com/listing/m2. Follow this configuration: [### Record id invalid -1:-2
This message is relative to a temporary Concepts#recordidrecordid.]] generated inside a transaction. For more information look at Transactions. This means that the record hasn't been correctly serialized.
This happens in graphs. Think to this graph of records:
A -> B -> C -> A
When OrientDB starts to serialize records goes recursively from the root A. When A is encountered again to avoid loops it saves the record as empty just to get the RecordID to store into the record C. When the serialization stack ends the record A (that was the first of the stack) is updated because has been created as first but empty.
Try to enable automatic flush of index nodes. Via API:
OGlobalConfiguration.MVRBTREE_LAZY_UPDATES.setValue(-1);
or via configuration:
java ... -Dmvrbtree.optimizeThreshold=-1 ...
This happens if you've migrated a database created with an old version of OrientDB where indexes were managed in different way. Just drop and recreate the indexes.
This is because the database is locked by another process is using it. To fix:
This is a message of an old version of OrientDB: upgrade it.
You're using different version of libraries. For example the client is using 1.3 and the server 1.4. Align the libraries to the same version (last is suggested). Or probably you've different versions of the same jars in the classpath.