OrientDB Version, operating system, or hardware.

• v2.2.7

Operating System

• [x] Linux

I have my database "cdrarch" running on a first server node, which has been started in distributed mode, and is ONLINE: orientdb {db=cdrarch}> list servers

CONFIGURED SERVERS
+----+-----------------+------+-----------+-----------------------+-----------------+-----------------+---------------+---------------+---------+
|#   |Name             |Status|Connections|StartedOn              |Binary           |HTTP             |UsedMemory     |FreeMemory     |MaxMemory|
+----+-----------------+------+-----------+-----------------------+-----------------+-----------------+---------------+---------------+---------+
|0   |node1473107743544|ONLINE|1          |2016-09-07 10:27:24.808|10.49.69.190:2424|10.49.69.190:2480|5.51GB (38.74%)|1.71GB (12.05%)|14.22GB  |
+----+-----------------+------+-----------+-----------------------+-----------------+-----------------+---------------+---------------+---------+

I have copied the "hazelcast.xml" file to a second server, and started that server as well.

The logs on both nodes say that they get a socket connection: extract from the logs on the second node:

2016-09-07 12:18:51:293 WARNI Assigning distributed node name: node1473243531293 [OHazelcastPlugin]

2016-09-07 12:18:52:399 INFO  [10.49.69.189]:2434 [cdrcontrols] [3.6.3] Creating MulticastJoiner [Node]
2016-09-07 12:18:52:405 INFO  [10.49.69.189]:2434 [cdrcontrols] [3.6.3] Address[10.49.69.189]:2434 is STARTING [LifecycleService]
...
2016-09-07 12:18:52:668 INFO  [10.49.69.189]:2434 [cdrcontrols] [3.6.3] Connecting to /10.49.69.190:2434, timeout: 0, bind-any: true [InitConnectionTask]
2016-09-07 12:18:52:675 INFO  [10.49.69.189]:2434 [cdrcontrols] [3.6.3] Established socket connection between /10.49.69.189:42394 and /10.49.69.190:2434 [TcpIpConnectionManager]
2016-09-07 12:18:58:692 INFO  [10.49.69.189]:2434 [cdrcontrols] [3.6.3]

Members [2] {
        Member [10.49.69.190]:2434
        Member [10.49.69.189]:2434 this
}

Then the database 'GratefulDeadConcerts' gets replicated:

2016-09-07 12:19:03:593 INFO  [node1473243531293] Current node started as MASTER for database 'GratefulDeadConcerts' [OHazelcastPlugin]
2016-09-07 12:19:03:596 INFO  [node1473243531293] New distributed configuration for database: GratefulDeadConcerts (version=1)

CLUSTER CONFIGURATION (LEGEND: X = Owner, o = Copy)
+--------+-----------+----------+-----------------+
|        |           |          |     MASTER      |
|        |           |          |     ONLINE      |
+--------+-----------+----------+-----------------+
|CLUSTER |writeQuorum|readQuorum|node1473107743544|
+--------+-----------+----------+-----------------+
|*       |     1     |    1     |        X        |
|internal|     1     |    1     |                 |
+--------+-----------+----------+-----------------+

 [OHazelcastPlugin]
2016-09-07 12:19:03:596 INFO  [node1473243531293] Saving distributed configuration file for database 'GratefulDeadConcerts' to: /opt/orientdb/databases/GratefulDeadConcerts/distribut
ed-config.json [OHazelcastPlugin]
2016-09-07 12:19:03:600 INFO  [node1473243531293] Distributed servers status:

+------------------+--------+------------------------------------+-----+---------+-----------------+-----------------+-------------------------+
|Name              |Status  |Databases                           |Conns|StartedOn|Binary           |HTTP             |UsedMemory               |
+------------------+--------+------------------------------------+-----+---------+-----------------+-----------------+-------------------------+
|node1473243531293*|STARTING|                                    |0    |12:18:50 |10.49.69.189:2424|10.49.69.189:2480|75.77MB/491.00MB (15.43%)|
|node1473107743544 |ONLINE  |GratefulDeadConcerts=ONLINE (MASTER)|3    |10:27:24 |10.49.69.190:2424|10.49.69.190:2480|5.35GB/14.22GB (37.63%)  |
|                  |        |bvdd-test=ONLINE (MASTER)           |     |         |                 |                 |                         |
+------------------+--------+------------------------------------+-----+---------+-----------------+-----------------+-------------------------+
...
2016-09-07 12:19:05:102 INFO  [node1473243531293] Publishing ONLINE status for database node1473243531293.GratefulDeadConcerts... [ODistributedDatabaseImpl]
2016-09-07 12:19:05:109 INFO  [node1473243531293] New distributed configuration for database: GratefulDeadConcerts (version=31)

CLUSTER CONFIGURATION (LEGEND: X = Owner, o = Copy)
+-------------+----+-----------+----------+-----------------+-----------------+
|             |    |           |          |     MASTER      |     MASTER      |
|             |    |           |          |     ONLINE      |     ONLINE      |
+-------------+----+-----------+----------+-----------------+-----------------+
|CLUSTER      |  id|writeQuorum|readQuorum|node1473107743544|node1473243531293|
+-------------+----+-----------+----------+-----------------+-----------------+
|*            |    |     2     |    1     |        X        |        o        |
|_studio_1    |  50|     2     |    1     |        o        |        X        |
|_studio_5    |  54|     2     |    1     |        o        |        X        |
|_studio_6    |  55|     2     |    1     |        o        |        X        |
|_studio_7    |  56|     2     |    1     |        o        |        X        |
|e_4          |  21|     2     |    1     |        o        |        X        |
|e_5          |  22|     2     |    1     |        o        |        X        |
...
|written_by_7 |  40|     2     |    1     |        o        |        X        |
+-------------+----+-----------+----------+-----------------+-----------------+

 [OHazelcastPlugin]
2016-09-07 12:19:05:109 INFO  [node1473243531293] Saving distributed configuration file for database 'GratefulDeadConcerts' to: /opt/orientdb/databases/GratefulDeadConcerts/distribut
ed-config.json [OHazelcastPlugin]

So far so good, it seems.

Then it starts with my big (300GB) database "cdrarch", but here we get problems:

2016-09-07 12:19:05:119 INFO  [node1473243531293] Current node started as MASTER for database 'cdrarch' [OHazelcastPlugin]
2016-09-07 12:19:05:120 INFO  [node1473243531293] New distributed configuration for database: cdrarch (version=1)

CLUSTER CONFIGURATION (LEGEND: X = Owner, o = Copy)
+--------+-----------+----------+-----------------+
|        |           |          |     MASTER      |
|        |           |          |     ONLINE      |
+--------+-----------+----------+-----------------+
|CLUSTER |writeQuorum|readQuorum|node1473107743544|
+--------+-----------+----------+-----------------+
|*       |     1     |    1     |        X        |
|internal|     1     |    1     |                 |
+--------+-----------+----------+-----------------+
2016-09-07 12:19:05:121 INFO  [node1473243531293] Saving distributed configuration file for database 'cdrarch' to: /opt/orientdb/databases/cdrarch/distributed-config.json [OHazelcast
Plugin]
2016-09-07 12:19:05:124 INFO  [node1473243531293] Distributed servers status:

+------------------+--------+------------------------------------+-----+---------+-----------------+-----------------+-------------------------+
|Name              |Status  |Databases                           |Conns|StartedOn|Binary           |HTTP             |UsedMemory               |
+------------------+--------+------------------------------------+-----+---------+-----------------+-----------------+-------------------------+
|node1473243531293*|STARTING|                                    |0    |12:18:50 |10.49.69.189:2424|10.49.69.189:2480|75.77MB/491.00MB (15.43%)|
|node1473107743544 |ONLINE  |GratefulDeadConcerts=ONLINE (MASTER)|3    |10:27:24 |10.49.69.190:2424|10.49.69.190:2480|5.35GB/14.22GB (37.63%)  |
|                  |        |cdrarch=ONLINE (MASTER)             |     |         |                 |                 |                         |
|                  |        |bvdd-test=ONLINE (MASTER)           |     |         |                 |                 |                         |
+------------------+--------+------------------------------------+-----+---------+-----------------+-----------------+-------------------------+
 [OHazelcastPlugin]
2016-09-07 12:19:05:131 WARNI [node1473243531293]->[[node1473107743544]] Requesting deploy of database 'cdrarch' on local server... [OHazelcastPlugin]
2016-09-07 12:19:05:444 WARNI [node1473243531293] Moving existent database 'cdrarch' in '/opt/orientdb/databases/cdrarch' to '/opt/orientdb/databases//../backup/databases/cdrarch' an
d get a fresh copy from a remote node... [OHazelcastPlugin]
2016-09-07 12:19:05:445 SEVER [node1473243531293] Error on moving existent database 'cdrarch' located in '/opt/orientdb/databases/cdrarch' to '/opt/orientdb/databases/../backup/datab
ases/cdrarch'. Deleting old database... [OHazelcastPlugin]
2016-09-07 12:19:05:445 INFO  [node1473243531293]<-[node1473107743544] Copying remote database 'cdrarch' to: /tmp/orientdb/install_cdrarch.zip [OHazelcastPlugin]
2016-09-07 12:19:05:446 INFO  [node1473243531293]<-[node1473107743544] Installing database 'cdrarch' to: /opt/orientdb/databases/cdrarch... [OHazelcastPlugin]
2016-09-07 12:19:05:447 INFO  [node1473243531293] - writing chunk #1 offset=0 size=0b [OHazelcastPlugin]
2016-09-07 12:19:05:448 INFO  [node1473243531293] Database copied correctly, size=0b [ODistributedAbstractPlugin$3]
2016-09-07 12:19:07:476 INFO  Node is not online yet (status=STARTING), blocking the command until it is online (retry=1, queue=0 worker=0) [ODistributedWorker]
2016-09-07 12:19:09:476 INFO  Node is not online yet (status=STARTING), blocking the command until it is online (retry=2, queue=0 worker=0) [ODistributedWorker]
...

-> what's happening?

Getting test case failures with below errors on

$ mvn clean install
-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running TestSuite
May 25, 2016 7:24:28 AM com.orientechnologies.common.log.OLogManager log
INFO: OrientDB auto-config DISKCACHE=30,286MB (heap=1,820MB os=127,852MB disk=60,573MB)
May 25, 2016 7:24:28 AM com.orientechnologies.common.log.OLogManager log
INFO: Received signal: SIGTRAP
May 25, 2016 7:24:28 AM com.orientechnologies.common.log.OLogManager log
INFO: Received signal: SIGTRAP
May 25, 2016 7:24:28 AM com.orientechnologies.common.log.OLogManager log
INFO: Received signal: SIGTRAP
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (safepoint.cpp:310), pid=1714, tid=70366099075488
#  guarantee(PageArmed == 0) failed: invariant
#
# JRE version: OpenJDK Runtime Environment (8.0_03-b03) (build 1.8.0_03-Ubuntu-8u77-b03-3ubuntu3-b03)
# Java VM: OpenJDK 64-Bit Server VM (25.03-b03 mixed mode linux-ppc64 compressed oops)
# Core dump written. Default location: /home/orientdb/core/core or core.1714
#
# An error report file with more information is saved as:
# /home/orientdb/core/hs_err_pid1714.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Aborted (core dumped)

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] OrientDB ........................................... SUCCESS [  2.109 s]
[INFO] OrientDB Test Commons .............................. SUCCESS [  2.472 s]
[INFO] OrientDB Core ...................................... FAILURE [43:17 min]
[INFO] OrientDB Enterprise ................................ SKIPPED
[INFO] OrientDB Client .................................... SKIPPED
[INFO] OrientDB Object .................................... SKIPPED
[INFO] OrientDB Server .................................... SKIPPED
[INFO] OrientDB Tools ..................................... SKIPPED
[INFO] OrientDB GraphDB ................................... SKIPPED
[INFO] OrientDB Tests ..................................... SKIPPED
[INFO] OrientDB Distributed Server ........................ SKIPPED
[INFO] OrientDB Lucene full text and spatial index ........ SKIPPED
[INFO] OrientDB JDBC Driver ............................... SKIPPED
[INFO] OrientDB ETL ....................................... SKIPPED
[INFO] OrientDB Community Distribution .................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 43:22 min
[INFO] Finished at: 2016-05-25T08:07:19+00:00
[INFO] Final Memory: 36M/437M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on project orientdb-core: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
[ERROR] Command was /bin/sh -c cd /home/orientdb/core && /usr/lib/jvm/java-8-openjdk-ppc64el/jre/bin/java -ea -Xmx2048m -Dindex.flushAfterCreate=false -Dstorage.makeFullCheckpointAfterCreate=false -Dstorage.makeFullCheckpointAfterOpen=false -Dstorage.makeFullCheckpointAfterClusterCreate=false -Dstorage.wal.syncOnPageFlush=false -Dstorage.configuration.syncOnUpdate=false -Ddb.makeFullCheckpointOnIndexChange=false -Ddb.makeFullCheckpointOnSchemaChange=false -jar /home/orientdb/core/target/surefire/surefirebooter3525119745377553230.jar /home/orientdb/core/target/surefire/surefire521712066030713187tmp /home/orientdb/core/target/surefire/surefire_08450310273360802813tmp
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :orientdb-core


Also other details are as below.
root@51f9ab09782a:/home/orientdb# mvn --version
Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_03-Ubuntu, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-ppc64el/jre
Default locale: en_US, platform encoding: ANSI_X3.4-1968
OS name: "linux", version: "4.2.0-16-generic", arch: "ppc64le", family: "unix"

root@51f9ab09782a:/home/orientdb# java -version
openjdk version "1.8.0_03-Ubuntu"
OpenJDK Runtime Environment (build 1.8.0_03-Ubuntu-8u77-b03-3ubuntu3-b03)
OpenJDK 64-Bit Server VM (build 25.03-b03, mixed mode)

root@51f9ab09782a:/home/orientdb# arch
ppc64le

root@51f9ab09782a:/home/orientdb# cat /etc/os-release
NAME="Ubuntu"
VERSION="16.04 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
UBUNTU_CODENAME=xenial

Any pointers to resolve above test case failures.

Regards, Amit

To support old binary formats we can use following approach:

1. Read storage configuration.
2. If storage configuration version is different from latest, look at list of migration scripts which will be used to migrate db data.
3. Perform migration automatically, with ability to track migration progress using listeners.

Subtasks:

• Integration of component version concept into storage components
• OMigration interface
• Migrator implementation
• API and console command for upgrade task
• API and console command that show version of binary data structure
• Automatic tests for testing backward compatibility
• Add compatibility for
  • 1.5.0
  • 1.5.1
  • 1.5.2
  • 1.6.0
  • 1.6.1
  • 1.6.2
  • 1.6.3
• Implement upgrade tasks for:
  • 1.5.0
  • 1.5.1
  • 1.5.2
  • 1.6.0
  • 1.6.1
  • 1.6.2
  • 1.6.3

More Info: http://stackoverflow.com/questions/38295528/isauthorized-exception-can-not-close-file-with-id-0-because-it-is-still-in-us

Expected behavior and actual behavior

Is: server starts but throws errors Should: server starts and all fine

Steps to reproduce the problem

JDK8 or 9 installed.

Error message

2016-07-10 20:59:41:942 WARNI {db=OSystem} MBean with name com.orientechnologies.orient.core.storage.impl.local.paginated.atomicoperations:id=1899654914,name="OSystem",type=OAtomicOperationsMangerMXBean has already registered. Probably your system was not shutdown correctly or you have several running applications which use OrientDB engine inside [OAtomicOperationsManager] 2016-07-10 20:59:41:944 SEVER isAuthorized() Exception: Can not close file with id 0 because it is still in use DB name="OSystem" [OSystemUserAuthenticator]

Runninng Mode

• [X] Embedded, using PLOCAL access mode
• [ ] Embedded, using MEMORY access mode
• [ ] Remote

Misc

• [ ] I have a distributed setup with multiple servers. How many?
• [ ] I'm using the Enterprise Edition

OrientDB Version

• [X] v2.0.x - Please specify last number:
• [ ] v2.1.x - Please specify last number:
• [X] v2.2.x - Please specify last number:

Operating System

• [X] Linux
• [ ] MacOSX
• [ ] Windows
• [ ] Other Unix
• [ ] Other, name?

Java Version

• [ ] 6
• [ ] 7
• [X] 8

Hi,

I got an OutOfMemoryError while inserting about 10^6 Nodes in a OrientGraph.

orientdb.err

2015-02-03 11:18:03:156 INFO  OrientDB auto-config DISKCACHE=13,880MB (heap=455MB os=16,384MB disk=105,812MB) [orientechnologies]
2015-02-03 11:18:03:160 INFO  Loading configuration from: /usr/local/Cellar/orientdb/2.0.1/libexec/config/orientdb-server-config.xml... [OServerConfigurationLoaderXml]
2015-02-03 11:18:03:398 INFO  OrientDB Server v2.0.1 (build UNKNOWN@r; 2015-01-28 18:33:00+0000) is starting up... [OServer]
2015-02-03 11:18:03:432 INFO  Databases directory: /usr/local/Cellar/orientdb/2.0.1/libexec/databases [OServer]
2015-02-03 11:18:03:487 INFO  Listening binary connections on 0.0.0.0:2424 (protocol v.28, socket=default) [OServerNetworkListener]
2015-02-03 11:18:03:489 INFO  Listening http connections on 0.0.0.0:2480 (protocol v.10, socket=default) [OServerNetworkListener]
2015-02-03 11:18:03:509 INFO  Installing dynamic plugin 'orientdb-lucene-2.0-dist.jar'... [OServerPluginManager]
2015-02-03 11:18:03:661 INFO  Lucene index plugin installed and active. Lucene version: LUCENE_47 [OLuceneIndexPlugin]
2015-02-03 11:18:03:663 INFO  Installing dynamic plugin 'studio-2.0.zip'... [OServerPluginManager]
2015-02-03 11:18:03:692 INFO  Installing GREMLIN language v.2.6.0 - graph.pool.max=50 [OGraphServerHandler]
2015-02-03 11:18:03:693 INFO  [OVariableParser.resolveVariables] Error on resolving property: distributed [orientechnologies]
2015-02-03 11:18:03:694 INFO  Installing Script interpreter. WARN: authenticated clients can execute any kind of code into the server by using the following allowed languages: [sql] [OServerSideScriptInterpreter]
2015-02-03 11:18:03:695 INFO  OrientDB Server v2.0.1 is active. [OServer]%                                                               14:03 log master ❯ cat orientdb.err

2015-02-03 11:18:03:155 INFO  OrientDB auto-config DISKCACHE=13,880MB (heap=455MB os=16,384MB disk=105,812MB) [orientechnologies]
2015-02-03 11:18:03:160 INFO  Loading configuration from: /usr/local/Cellar/orientdb/2.0.1/libexec/config/orientdb-server-config.xml... [OServerConfigurationLoaderXml]
2015-02-03 11:18:03:397 INFO  OrientDB Server v2.0.1 (build UNKNOWN@r; 2015-01-28 18:33:00+0000) is starting up... [OServer]
2015-02-03 11:18:03:432 INFO  Databases directory: /usr/local/Cellar/orientdb/2.0.1/libexec/databases [OServer]
2015-02-03 11:18:03:487 INFO  Listening binary connections on 0.0.0.0:2424 (protocol v.28, socket=default) [OServerNetworkListener]
2015-02-03 11:18:03:488 INFO  Listening http connections on 0.0.0.0:2480 (protocol v.10, socket=default) [OServerNetworkListener]
2015-02-03 11:18:03:509 INFO  Installing dynamic plugin 'orientdb-lucene-2.0-dist.jar'... [OServerPluginManager]
2015-02-03 11:18:03:660 INFO  Lucene index plugin installed and active. Lucene version: LUCENE_47 [OLuceneIndexPlugin]
2015-02-03 11:18:03:663 INFO  Installing dynamic plugin 'studio-2.0.zip'... [OServerPluginManager]
2015-02-03 11:18:03:692 INFO  Installing GREMLIN language v.2.6.0 - graph.pool.max=50 [OGraphServerHandler]
2015-02-03 11:18:03:692 INFO  [OVariableParser.resolveVariables] Error on resolving property: distributed [orientechnologies]
2015-02-03 11:18:03:694 INFO  Installing Script interpreter. WARN: authenticated clients can execute any kind of code into the server by using the following allowed languages: [sql] [OServerSideScriptInterpreter]
2015-02-03 11:18:03:694 INFO  OrientDB Server v2.0.1 is active. [OServer]Exception in thread "Timer-0" java.lang.OutOfMemoryError: GC overhead limit exceeded
    at java.util.concurrent.ConcurrentHashMap$EntrySetView.iterator(ConcurrentHashMap.java:4746)
    at com.orientechnologies.orient.server.plugin.OServerPluginManager.updatePlugins(OServerPluginManager.java:277)

Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "Timer-0"
java.lang.OutOfMemoryError: GC overhead limit exceeded
    at java.util.Arrays.copyOfRange(Arrays.java:3664)
    at java.lang.String.<init>(String.java:201)
    at java.lang.StringBuilder.toString(StringBuilder.java:407)
    at java.io.ObjectStreamField.getClassSignature(ObjectStreamField.java:322)
    at java.io.ObjectStreamField.<init>(ObjectStreamField.java:140)
    at java.io.ObjectStreamClass.matchFields(ObjectStreamClass.java:2259)
    at java.io.ObjectStreamClass.getReflector(ObjectStreamClass.java:2149)
    at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:517)
    at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:365)
    at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:464)
    at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:365)
    at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:464)Exception in thread "OrientDB <- BinaryClient (/127.0.0.1:54626)" java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded

a test class in scala:

package model.orientdb

import com.orientechnologies.orient.core.intent.OIntentMassiveInsert
import com.orientechnologies.orient.core.sql.OCommandSQL
import com.tinkerpop.blueprints.impls.orient.{OrientVertex, OrientGraphFactory, OrientGraph}
import org.scalatest._
import de.softamrhein.Logger

class OrientDBGraphAPISpec extends FlatSpecLike
  with BeforeAndAfter
  with BeforeAndAfterAll
  with Matchers
  with Logger
{

  var factory: OrientGraphFactory = null
  var graph: OrientGraph = null

  override def beforeAll() = {
    factory = new OrientGraphFactory("remote:localhost/test")
  }

  override def afterAll() = {
    factory.close()
  }

  before {
    graph = factory.getTx
    graph.getRawGraph.declareIntent( new OIntentMassiveInsert() );
  }

  after {
    graph.commit()
    graph.shutdown()
  }


  "Graph" can "remove everything" in {

    graph.command(new OCommandSQL("delete Vertex Structure")).execute()
    graph.command(new OCommandSQL("delete Vertex StructureNode")).execute()

    graph.command(new OCommandSQL("delete Edge childNode")).execute()
    graph.command(new OCommandSQL("delete Edge rootNode")).execute()


    assert(true)
  }



  def createStructure(ident: String, nodePrefix: String, levelCount: Int, nodesPerLevel: Int) = {

    val structureVertex = graph.addVertex("class:Structure", "ident", ident)

    def loop (currentLevel: Int, parentVertex: OrientVertex, edgeClass: String): Unit = {

      if (currentLevel < levelCount) {

        (1 to nodesPerLevel).foreach { idx =>

          val nodeVertex = graph.addVertex("class:StructureNode", "ident", nodePrefix + '-' + currentLevel + '-' + idx)
          parentVertex.addEdge(edgeClass, nodeVertex, edgeClass)

          loop(currentLevel + 1, nodeVertex, "childNode")
        }

      }

    }

    loop(0, structureVertex, "rootNode")
  }

  it can "create small 1-level structure" in {
    createStructure("structure-1-level", "Node1l", 1, 10)
  }

  it can "create 2-level structure" in {
    createStructure("structure-2-level", "Node2l", 2, 10)
  }

  it can "create 3-level structure" in {
    createStructure("structure-3-level", "Node3l", 3, 10)
  }

  it can "create 4-level structure" in {
    createStructure("structure-4-level", "Node4l", 4, 10)
  }

  it can "create 5-level structure" in {
    createStructure("structure-5-level", "Node5l", 5, 10)
  }

  it can "create 6-level structure" in {
    createStructure("structure-6-level", "Node6l", 6, 10)
  }
}

OrientDB Version, operating system, or hardware.

2.2.12 (and later 2.2.14)

Operating System

• [X ] Linux

Expected behavior and actual behavior

Embedded Orient DB appears to be consuming between 2GB and 4GB of memory on our server. The net result is that our server gets stuck in major collections, CPU usage sky rockets, the application becomes totally unusable. We are not storing large objects in our Orient DB. Mostly list of email addresses and id's.

We would not expect Orient DB to consume such a massive amount of memory. I wonder if Andrey's new refactoring of Orient locking schemes is causing this behaviour?

Steps to reproduce the problem

This is occuring in production, so its tough to advise how to reproduce. Please refer to snapshots below>

Such features as record level security encourage user to use OrientDB authorization as application level authorization. In other words, use OUser class as a main class for application user.

However there are some significant design issues in binary network protocol.

I suppose users would like to use approach similar to following

• Application opens several sockets to database.
• For each user connected to the application a db session is opened.
• OPEN_DATABASE command is used to authorize user.
• SessionID or similar entity is used as auth token.

Issues with concurrent requests

ODatabaseDocumentTx is not thread safe. And in binary network protocol each client session holds its instance of ODatabaseDocumentTx.

Thus session can not be used by several connections from different sockets because they can be handled in different server threads.

As a result we can not reuse session in different client threads.

This means that we have to open a new session for each user * each application thread. That leads to a need to reauthorize user in db for each thread. And as soon as user request can be handled by several application thread we have to store username and password at application layer.

Memory consumption

Having a thousands of active users may lead to thousands of opened connections in client connection manager. This could be memory consuming.

Possible memory leaks

If user is not logged out and socket was reused by other user, its session may remain in client connection manager forever. It won't be closed automatically as soon as socket still alive and used by application to handle another user sessions.

Session Id shouldn't be used as auth token

Session Id is serial, so it is not really safe to use it as a auth token.

No native way to make users rememberable

As soon as OrientDB supports only user/password authorization, "Remember me" feature could be implemented only by workarounds.

Automatic shutdown of session

Automatic shutdown of sessions that associated to broken connections are not designed for sessions that could be used by several connections.

So some session that is closed in such way may still be used by some other thread.

OrientDB Version, operating system, or hardware.

• v2.2.10
• v2.2.11

Operating System

Linux

Expected behavior and actual behavior

Expected to get an output similar to what's described in http://orientdb.com/docs/last/Console-Command-Repair-Database.html

I am getting just "null pointer exception" with no further details.

From orientdb.err (partial):

2016-10-03 14:41:40:000 INFO  Loading configuration from: /home/develance/orientdb/config/orientdb-server-config.xml... [OServerConfigurationLoaderXml]
2016-10-03 14:41:40:315 INFO  OrientDB Server v2.2.11 (build 2.2.x@r8b3a478e3ca7321a48e7cf0f5991569bbe06ed89; 2016-10-03 09:39:41+0000) is starting up... [OServer]
2016-10-03 14:41:40:322 INFO  Databases directory: /home/develance/orientdb/data [OServer]
2016-10-03 14:41:40:783 INFO  Listening binary connections on 0.0.0.0:2424 (protocol v.36, socket=default) [OServerNetworkListener]
2016-10-03 14:41:40:786 INFO  Listening http connections on 0.0.0.0:2480 (protocol v.10, socket=default) [OServerNetworkListener]
2016-10-03 14:41:40:798 INFO  Installing dynamic plugin 'studio-2.2.zip'... [OServerPluginManager]
2016-10-03 14:41:40:808 INFO  ODefaultPasswordAuthenticator is active [ODefaultPasswordAuthenticator]
2016-10-03 14:41:40:813 INFO  OServerConfigAuthenticator is active [OServerConfigAuthenticator]
2016-10-03 14:41:40:814 INFO  OSystemUserAuthenticator is active [OSystemUserAuthenticator]
2016-10-03 14:41:40:848 INFO  Installed GREMLIN language v.2.6.0 - graph.pool.max=50 [OGraphServerHandler]
2016-10-03 14:41:40:848 INFO  [OVariableParser.resolveVariables] Error on resolving property: distributed [orientechnologies]
2016-10-03 14:41:40:852 WARNI Authenticated clients can execute any kind of code into the server by using the following allowed languages: [sql] [OServerSideScriptInterpreter]
2016-10-03 14:41:40:855 INFO  OrientDB Studio available at http://45.56.122.213:2480/studio/index.html [OServer]
2016-10-03 14:41:40:855 INFO  OrientDB Server is active v2.2.11 (build 2.2.x@r8b3a478e3ca7321a48e7cf0f5991569bbe06ed89; 2016-10-03 09:39:41+0000). [OServer]
2016-10-03 14:43:55:296 WARNI {db=OSystem} Storage 'OSystem' was not closed properly. Will try to recover from write ahead log [OLocalPaginatedStorage]
2016-10-03 14:43:55:297 INFO  {db=OSystem} Looking for last checkpoint... [OLocalPaginatedStorage]
2016-10-03 14:43:55:297 INFO  {db=OSystem} Checkpoints are absent, the restore will start from the beginning. [OLocalPaginatedStorage]
2016-10-03 14:43:55:298 INFO  {db=OSystem} Data restore procedure is started. [OLocalPaginatedStorage]
2016-10-03 14:43:55:305 WARNI {db=OSystem} Non tx operation was used during data modification we will need index rebuild. [OLocalPaginatedStorage]
2016-10-03 14:43:55:311 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OFullCheckpointStartRecord{lsn=OLogSequenceNumber{segment=0, position=5293}, p$
2016-10-03 14:43:55:311 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OCheckpointEndRecord{lsn=OLogSequenceNumber{segment=0, position=5301}} will be$
2016-10-03 14:43:55:318 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OFullCheckpointStartRecord{lsn=OLogSequenceNumber{segment=0, position=14746}, $
2016-10-03 14:43:55:319 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OCheckpointEndRecord{lsn=OLogSequenceNumber{segment=0, position=14770}} will b$
2016-10-03 14:43:55:327 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OFullCheckpointStartRecord{lsn=OLogSequenceNumber{segment=0, position=42277}, $
2016-10-03 14:43:55:328 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OCheckpointEndRecord{lsn=OLogSequenceNumber{segment=0, position=42301}} will b$
2016-10-03 14:43:55:686 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OFullCheckpointStartRecord{lsn=OLogSequenceNumber{segment=0, position=139035},$
2016-10-03 14:43:55:686 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OCheckpointEndRecord{lsn=OLogSequenceNumber{segment=0, position=139059}} will $
2016-10-03 14:43:55:925 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OFullCheckpointStartRecord{lsn=OLogSequenceNumber{segment=0, position=417812},$
2016-10-03 14:43:55:926 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OCheckpointEndRecord{lsn=OLogSequenceNumber{segment=0, position=417836}} will $
2016-10-03 14:43:55:927 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OFullCheckpointStartRecord{lsn=OLogSequenceNumber{segment=0, position=417843},$
2016-10-03 14:43:55:927 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OCheckpointEndRecord{lsn=OLogSequenceNumber{segment=0, position=417867}} will $
2016-10-03 14:43:55:928 WARNI {db=OSystem} Record OFuzzyCheckpointStartRecord{lsn=OLogSequenceNumber{segment=0, position=417874}} com.orientechnologies.orient.core.storage.impl.local.paginated.wa$
2016-10-03 14:43:55:928 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OFuzzyCheckpointEndRecord{lsn=OLogSequenceNumber{segment=0, position=417914}} $
2016-10-03 14:43:55:929 WARNI {db=OSystem} Record OFuzzyCheckpointStartRecord{lsn=OLogSequenceNumber{segment=0, position=417921}} com.orientechnologies.orient.core.storage.impl.local.paginated.wa$
2016-10-03 14:43:55:930 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OFuzzyCheckpointEndRecord{lsn=OLogSequenceNumber{segment=0, position=417961}} $
2016-10-03 14:43:55:930 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OFullCheckpointStartRecord{lsn=OLogSequenceNumber{segment=0, position=417968},$
2016-10-03 14:43:55:931 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OCheckpointEndRecord{lsn=OLogSequenceNumber{segment=0, position=417992}} will $
2016-10-03 14:43:55:932 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OFullCheckpointStartRecord{lsn=OLogSequenceNumber{segment=0, position=417999},$
2016-10-03 14:43:55:934 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OCheckpointEndRecord{lsn=OLogSequenceNumber{segment=0, position=418023}} will $
2016-10-03 14:43:55:935 WARNI {db=OSystem} Record OFuzzyCheckpointStartRecord{lsn=OLogSequenceNumber{segment=0, position=418030}} com.orientechnologies.orient.core.storage.impl.local.paginated.wa$
2016-10-03 14:43:55:936 WARNI {db=OSystem} Record com.orientechnologies.orient.core.storage.impl.local.paginated.wal.OFuzzyCheckpointEndRecord{lsn=OLogSequenceNumber{segment=0, position=418070}} $
2016-10-03 14:43:55:937 WARNI {db=OSystem} Record OFuzzyCheckpointStartRecord{lsn=OLogSequenceNumber{segment=0, position=418077}} com.orientechnologies.orient.core.storage.impl.local.paginated.wa$

I tried the repair since whenever I try to access Studio from the browser, I can connect to DB but when selecting "Schema" tab, it reports "Server might be offline".

Steps to reproduce the problem

• open console
• connect to db (remote)
• run repair database --fix-graph

OrientDb: 2.0.14

Orientjs

begin
LET t0 = UPDATE Node SET Points = 0
LET t1 = UPDATE Node SET Position = "admin"
return [$t0, $t1]

Result:

[ { classId: -2, value: null }, { classId: -2, value: null } ]

Expect somethink like this: [ number, number ]

Result in 2.1.2 but in Studio

{
    "result": [
        {
            "@type": "d",
            "@version": 0,
            "value": [
                13,
                13
            ]
        }
    ],
    "notification": "Query executed  in 0.091 sec. Returned 1 record(s)"
}

BTW: It is very hard to take orientdb serious when such simple things doesn't works. In almost every release there is a regression. Orientdb should be focused on qualitity not in features. This is my perspective in 6 month orientdb.

OrientDB Version: 2.2.x

I noticed that in each of our big database directories, a file "default.pcl" exists which has a huge size:

databases$ du -sh *
7.2M    GratefulDeadConcerts
2.2M    OSystem
638G    cdrarch
548G    mobile
24G     navi
databases$ ls -lh */default.pcl
-rw-rw-r-- 1 orientdb orientdb  65K Jun 13  2016 GratefulDeadConcerts/default.pcl
-rw-rw-r-- 1 orientdb orientdb  65K Jun 15  2016 OSystem/default.pcl
-rw-rw-r-- 1 orientdb orientdb  85G Feb  5 00:16 cdrarch/default.pcl
-rw-rw-r-- 1 orientdb orientdb 201G Feb  5 00:03 mobile/default.pcl
-rw-r--r-- 1 orientdb orientdb 129K Nov 24 11:42 navi/default.pcl

For the case of "mobile", that file is almost half of the total size of the database directory!

OrientDB Version, operating system, or hardware.

• v2.2.13-20161027.133116-9

Operating System

• [x] Linux (Ubuntu 14.04LTS)

Expected behavior and actual behavior

Bundled "shutdown.sh" script, with or without extra arguments, should gracefully shutdown the server, but it does not. Follow-up of #6705

Steps to reproduce the problem

1. launched the "shutdown.sh" script without arguments: # bin/shutdown.sh pid file detected, killing process waiting for OrientDB server to shutdown (never completes)

2. launched the "shutdown.sh" script with the arguments mentioned in issue #6705 by robfrank (of course filled in the correct values for our case): # bin/shutdown.sh -h orient1.bc -P 2424-2430 -u root -p ROOT_PASSWORD Sending shutdown command to remote OrientDB Server instance... Sep 30, 2016 2:11:41 PM com.orientechnologies.common.log.OLogManager log SEVERE: Error on connecting to orient1.bc:2424 java.net.ConnectException: Connection refused ...

3. server process still not shutdown: # ps -aef|grep java root 42254 42252 82 Sep29 ? 13:27:20 java -server -Xms1024m -Xmx16384m -Djna.nosys=true -XX:+HeapDumpOnOutOfMemoryError -XX:MaxDirectMemorySize=512g -Djava.awt.headless=true -Dfile.encoding=UTF8 -Drhino.opt.level=9 -Dstorage.diskCache.bufferSize=65536 -Djava.util.logging.config.file=/opt/orientdb/orientdb-community-2.2.10/config/orientdb-server-log.properties -Dorientdb.config.file=/opt/orientdb/orientdb-community-2.2.10/config/orientdb-server-config.xml -Dorientdb.www.path=/opt/orientdb/orientdb-community-2.2.10/www -Dorientdb.build.number=2.2.x@rc32d4ee06d4c38e27eb66931d027eb54854872ff; 2016-09-15 08:47:27+0000 -cp /opt/orientdb/orientdb-community-2.2.10/lib/orientdb-server-2.2.10.jar:/opt/orientdb/orientdb-community-2.2.10/lib/*:/opt/orientdb/orientdb-community-2.2.10/plugins/* -Ddistributed=true com.orientechnologies.orient.server.OServerMain

4. logfile: 2016-09-30 13:52:27:477 WARNI Received signal: SIGTERM [OSignalHandler]

Hey all,

I am a developer at TerraFrame and we are using OrientDB in a few of our products. I am reaching out because the OrientDB spatial library is getting quite out of date and we need updates of dependent libraries, especially JTS (upgraded to locationtech).

Is this something that we can get on the roadmap for next year? We're happy to help with this effort but would want some guidance to make sure we're following correct procedures and maximizing efficiency

Thanks

OrientDB Version: 3.2.13

Java Version: 11

OS: Windows & Ubuntu

The issue #9385 was resolved by version 3.2.4 of OrientDB when you traverse a graph from an SQL query in Java or from the studio. However this issue is still present for gremlins requests.

Expected behavior

When traversing a graph using gremlins if the user has no rights to read certain vertices, the vertices should not be returned but the request should succeed and return the vertices the user has the right to see.

Actual behavior

Orientdb returns an exception.

Steps to reproduce

See the issue #9385 to have the datamodel and do a traversal on the data using gremlins.

javax.script.ScriptException: javax.script.ScriptException: java.lang.NullPointerException: out vertex on edge [...]
	at org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine.eval(GremlinGroovyScriptEngine.java:378)
	at java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:233)
	at javax.script.ScriptEngine$eval$0.call(Unknown Source)
	at Script3.subgraph(Script3.groovy:143)
	at jdk.internal.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:101)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1217)
	at groovy.lang.MetaClassImpl.invokeMethodClosure(MetaClassImpl.java:1050)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1092)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1041)
	at groovy.lang.Closure.call(Closure.java:405)
	at org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine.callGlobal(GremlinGroovyScriptEngine.java:761)
	at org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine.callGlobal(GremlinGroovyScriptEngine.java:755)
	at org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine.invokeImpl(GremlinGroovyScriptEngine.java:737)
	at org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine.invokeFunction(GremlinGroovyScriptEngine.java:427)
	at org.apache.tinkerpop.gremlin.orientdb.executor.OCommandGremlinExecutor.executeFunction(OCommandGremlinExecutor.java:206)
	at com.orientechnologies.orient.core.metadata.function.OFunction.executeInContext(OFunction.java:173)
	at com.orientechnologies.orient.core.metadata.function.ODatabaseFunction.execute(ODatabaseFunction.java:46)
	at com.orientechnologies.orient.core.sql.parser.OFunctionCall.execute(OFunctionCall.java:145)
	at com.orientechnologies.orient.core.sql.parser.OFunctionCall.execute(OFunctionCall.java:96)
	at com.orientechnologies.orient.core.sql.parser.OLevelZeroIdentifier.execute(OLevelZeroIdentifier.java:62)
	at com.orientechnologies.orient.core.sql.parser.OBaseIdentifier.execute(OBaseIdentifier.java:70)
	at com.orientechnologies.orient.core.sql.parser.OBaseExpression.execute(OBaseExpression.java:126)
	at com.orientechnologies.orient.core.sql.parser.OExpression.execute(OExpression.java:102)
	at com.orientechnologies.orient.core.sql.parser.OProjectionItem.execute(OProjectionItem.java:177)
	at com.orientechnologies.orient.core.sql.parser.OProjection.calculateSingle(OProjection.java:167)
	at com.orientechnologies.orient.core.sql.executor.ProjectionCalculationStep.calculateProjections(ProjectionCalculationStep.java:64)
	at com.orientechnologies.orient.core.sql.executor.ProjectionCalculationStep.access$000(ProjectionCalculationStep.java:10)
	at com.orientechnologies.orient.core.sql.executor.ProjectionCalculationStep$1.next(ProjectionCalculationStep.java:39)
	at com.orientechnologies.orient.core.sql.executor.OScriptExecutionPlan.doExecute(OScriptExecutionPlan.java:82)
	at com.orientechnologies.orient.core.sql.executor.OScriptExecutionPlan.fetchNext(OScriptExecutionPlan.java:40)
	at com.orientechnologies.orient.core.sql.parser.OLocalResultSet.fetchNext(OLocalResultSet.java:36)
	at com.orientechnologies.orient.core.sql.parser.OLocalResultSet.<init>(OLocalResultSet.java:27)
	at com.orientechnologies.orient.core.command.OSqlScriptExecutor.executeInternal(OSqlScriptExecutor.java:129)
	at com.orientechnologies.orient.core.command.OSqlScriptExecutor.execute(OSqlScriptExecutor.java:53)
	at com.orientechnologies.orient.core.db.document.ODatabaseDocumentEmbedded.execute(ODatabaseDocumentEmbedded.java:683)
	at com.orientechnologies.orient.server.OConnectionBinaryExecutor.executeQuery(OConnectionBinaryExecutor.java:1349)
	at com.orientechnologies.orient.client.remote.message.OQueryRequest.execute(OQueryRequest.java:143)
	at com.orientechnologies.orient.server.network.protocol.binary.ONetworkProtocolBinary.sessionRequest(ONetworkProtocolBinary.java:355)
	at com.orientechnologies.orient.server.network.protocol.binary.ONetworkProtocolBinary.execute(ONetworkProtocolBinary.java:239)
	at com.orientechnologies.common.thread.OSoftThread.run(OSoftThread.java:68)
Caused by: javax.script.ScriptException: java.lang.NullPointerException: out vertex on edge [...]
	at org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine.eval(GremlinGroovyScriptEngine.java:697)
	at org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine.eval(GremlinGroovyScriptEngine.java:376)
	... 43 more
Caused by: java.lang.NullPointerException: out vertex on edge [...]
	at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:907)
	at org.apache.tinkerpop.gremlin.orientdb.OrientEdge.<init>(OrientEdge.java:33)
	at org.apache.tinkerpop.gremlin.orientdb.OrientEdge.<init>(OrientEdge.java:38)
	at org.apache.tinkerpop.gremlin.orientdb.OrientEdge.<init>(OrientEdge.java:54)
	at org.apache.tinkerpop.gremlin.orientdb.OElementFactory.wrapEdge(OElementFactory.java:16)
	at org.apache.tinkerpop.gremlin.orientdb.OrientVertex.lambda$edges$8(OrientVertex.java:157)
	at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
	at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
	at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
	at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
	at org.apache.tinkerpop.gremlin.orientdb.OrientVertex.edges(OrientVertex.java:159)
	at org.apache.tinkerpop.gremlin.process.traversal.step.map.VertexStep.flatMap(VertexStep.java:68)
	at org.apache.tinkerpop.gremlin.process.traversal.step.map.FlatMapStep.processNextStart(FlatMapStep.java:49)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:144)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:55)
	at org.apache.tinkerpop.gremlin.process.traversal.step.filter.FilterStep.processNextStart(FilterStep.java:37)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:144)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:55)
	at org.apache.tinkerpop.gremlin.process.traversal.step.filter.FilterStep.processNextStart(FilterStep.java:37)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:144)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:55)
	at org.apache.tinkerpop.gremlin.process.traversal.step.filter.FilterStep.processNextStart(FilterStep.java:37)
	at org.apache.tinkerpop.gremlin.process.traversal.step.filter.PathFilterStep.processNextStart(PathFilterStep.java:133)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:144)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:55)
	at org.apache.tinkerpop.gremlin.process.traversal.step.filter.FilterStep.processNextStart(FilterStep.java:37)
	at org.apache.tinkerpop.gremlin.process.traversal.step.filter.DedupGlobalStep.processNextStart(DedupGlobalStep.java:105)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:144)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:55)
	at org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SideEffectStep.processNextStart(SideEffectStep.java:38)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:144)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:55)
	at org.apache.tinkerpop.gremlin.process.traversal.step.map.FlatMapStep.processNextStart(FlatMapStep.java:48)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:144)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:55)
	at org.apache.tinkerpop.gremlin.process.traversal.step.filter.FilterStep.processNextStart(FilterStep.java:37)
	at org.apache.tinkerpop.gremlin.process.traversal.step.filter.PathFilterStep.processNextStart(PathFilterStep.java:133)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:144)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:55)
	at org.apache.tinkerpop.gremlin.process.traversal.step.filter.FilterStep.processNextStart(FilterStep.java:37)
	at org.apache.tinkerpop.gremlin.process.traversal.step.filter.DedupGlobalStep.processNextStart(DedupGlobalStep.java:105)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:144)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:55)
	at org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SideEffectStep.processNextStart(SideEffectStep.java:38)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:144)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:55)
	at org.apache.tinkerpop.gremlin.process.traversal.step.branch.RepeatStep$RepeatEndStep.standardAlgorithm(RepeatStep.java:296)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.ComputerAwareStep.processNextStart(ComputerAwareStep.java:46)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:144)
	at org.apache.tinkerpop.gremlin.process.traversal.step.branch.RepeatStep.standardAlgorithm(RepeatStep.java:196)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.ComputerAwareStep.processNextStart(ComputerAwareStep.java:46)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:144)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.hasNext(ExpandableStepIterator.java:47)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processAllStarts(SupplyingBarrierStep.java:83)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processNextStart(SupplyingBarrierStep.java:70)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:129)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:39)
	at org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.next(DefaultTraversal.java:214)
	at java_util_Iterator$next.call(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:115)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:119)
	at Script1188.run(Script1188.groovy:1)
	at org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine.eval(GremlinGroovyScriptEngine.java:674)
	... 44 more

OrientDB Version: orientdb-community-3.2.7

Java Version: OpenJDK Runtime Environment (build 11.0.17+8-post-Ubuntu-1ubuntu220.04)

OS: Ubuntu 20.04.3 LTS

Expected behavior

Create many edges to one vertex with a reasonable performance.

VertexA1 -> VertexB1 VertexA2 -> VertexB1 VertexA3 -> VertexB1 ... -> VertexB1

Actual behavior

When I've tried create many edges to one vertex the performance slow down very quickly and turns to impracticable.

What can I do to guarantee a reasonable performance?

Note: I've tested with sql.graphConsistencyMode=notx_async_repair and ridBag.embeddedToSbtreeBonsaiThreshold=-1 trying to improve the performance, but the behavior was the same.

Steps to reproduce

I've used Post Command Rest Api with CREATE EDGE E1 UPSERT #rid to #rid. To create edges between vertex class that don't have a "Supernode" we have a reasonable performance.

Regards.

OrientDB Version: 2.2.37

Java Version: OpenJDK 8

OS: Windows

Expected behavior

There should be an option in orientdb-server-config.xml to configure SSL for OrientDB Studio

Actual behavior

OrientDB Studio can only be accessed through HTTP

OrientDB Version: 3.2.7

Java Version: 11.0.17.8

OS: Windows

When assigning OSecurityPolicy to vertices the performances are greatly reduced, even if an index is used. For example, if you set a policy to check read access on an vertex class 'MyVertex' with the property 'security' (String) by setting "security = 'toto'" the count can take more than 1 second for 30000 records.

The query with predicate: select count() from MyVertex

is slower than the query without predicate: select count() from MyVertex where security = 'toto'

An index is set on MyVertex.security : MyVertex.security NOTUNIQUE ["security"] CELL_BTREE

Comparisons done with the same user:

select count() from MyVertex where security = 'toto' returns 23726 in 0.231 sec, with read predicate "true"

select count() from MyVertex returns 23726 in 0.855 sec, with read predicate "security = 'toto'"

select count() from MyVertex where security = 'aaa' returns 0 in 0.007 sec, with read predicate "true"

select count() from MyVertex returns 0 in 0.655 sec, with read predicate "security = 'aaa'"

The aim would be in the end to filter which vertices each user can see in a given class using predicates. Currently the performance hit is too great to use security predicates. Maybe we use badly the index or something like that.

Expected behavior

Have the same performances in queries with and without predicates that does the same thing.

Actual behavior

The queries are up to 100 times slower.

Steps to reproduce

• Create a vertex class and a security property
• Add thousands of vertices
• Index the security property
• Execute some queries with and without security predicates

OrientDB Version: 3.0.37, 3.1.20, 3.2.12

Java Version: OpenJDK 1.8.0_322

OS: CentOS 7 (Linux)

Expected behavior

CHECK DATABASE and REPAIR DATABASE give consistent results: if the check does not report any error, the repair operation should not find anything to repair...

Actual behavior

On the same database as #9898, CHECK DATABASE reports no error:

orientdb {db=database}> check database

Checking storage.Check of storage is started...Check of storage completed in 119999ms.  without errors.

but REPAIR DATABASE --fix-graph --fix-links -v does find some data to repair:

orientdb {db=database}> repair database --fix-graph --fix-links -v                                                                                      
Repair of graph 'plocal:/path/to/my/orientdb/databases/database' is started ...
Scanning 35589387 edges (skipEdges=0)...
... <snip> ...
+ edges: scanned 14000000, removed 4 (estimated remaining time 382 secs)
+ deleting corrupted edge VersionedBy#228:2018216{out:#35:352,in:#166:2532} v1 because incoming vertex (ReferenceDataList#166:2532{in_VersionedBy:[...],in_Identifies:[#210:24963],name:groupActivities,out_Refers:[#315:29114, #316:29114],in_Owns:[#284:24947],out_OwnsMetadata:[#298:4779],in_CopiedFrom:[#255:20816]} v529) does not contain the edge
+ edges: scanned 14100000, removed 5 (estimated remaining time 381 secs)
... <snip> ...
Scanning vertices completed
Repair of graph 'plocal:/path/to/my/orientdb/databases/database' completed in 645 secs
 scannedEdges.....: 35589387
 removedEdges.....: 17
 scannedVertices..: 35589370
 scannedLinks.....: 0
 removedLinks.....: 0
 repairedVertices.: 0

- Removing broken links...
-- Done! Fixed links: 0, modified documents: 0
Repair database complete (0 errors)

The number of corrupted edges varies depending on the OrientDB version: 3.0 and 3.1 detect 5 errors while 3.2 sees 17 of them. All these edges are from the same class, and all have incoming vertices from the same class with RIDs in #166:xxxx.

Steps to reproduce