orientdb
orientdb copied to clipboard
orientechnologies
NullPointerException: Null value is passed
OrientDB Version: 2.2.34
Java Version: 1.8
OS: Linux
Expected behavior
Database stable
Actual behavior
Database low with block
Steps to reproduce
I have this problem:
2021-02-11 11:45:48:059 INFO [169.254.92.247]:2434 [orientdb] [3.8.4] processors=8, physical.memory.total=31.3G, physical.memory.free=1.0G, swap.space.total=24.0G, swap.space.free=22.9G, heap.memory.used=2.8G, heap.memory.free=1.2G, heap.memory.total=4.0G, heap.memory.max=4.0G, heap.memory.used/total=71.15%, heap.memory.used/max=71.15%, minor.gc.count=1192786, minor.gc.time=15876333ms, major.gc.count=1339, major.gc.time=256184ms, load.process=0.04%, load.system=0.09%, load.systemAverage=170.00%, thread.count=105, thread.peakCount=115, cluster.timeDiff=0, event.q.size=0, executor.q.async.size=0, executor.q.client.size=0, executor.q.query.size=0, executor.q.scheduled.size=0, executor.q.io.size=0, executor.q.system.size=0, executor.q.operations.size=0, executor.q.priorityOperation.size=0, operations.completed.count=391445, executor.q.mapLoad.size=0, executor.q.mapLoadAllKeys.size=0, executor.q.cluster.size=0, executor.q.response.size=0, operations.running.count=0, operations.pending.invocations.percentage=0.00%, operations.pending.invocations.count=0, proxy.count=0, clientEndpoint.count=0, connection.active.count=1, client.connection.count=0, connection.count=1 [HealthMonitor]Cannot route COMMAND operation to the distributed node java.lang.NullPointerException: Null value is passed at com.orientechnologies.orient.core.sql.OSoftQueryResultList.add(OSoftQueryResultList.java:199) at com.orientechnologies.orient.server.distributed.impl.ODistributedStorage.mergeResultByAggregation(ODistributedStorage.java:550) at com.orientechnologies.orient.server.distributed.impl.ODistributedStorage.command(ODistributedStorage.java:300) at com.orientechnologies.orient.core.sql.query.OSQLQuery.run(OSQLQuery.java:78) at com.orientechnologies.orient.core.sql.query.OSQLAsynchQuery.run(OSQLAsynchQuery.java:74) at com.orientechnologies.orient.core.sql.query.OSQLSynchQuery.run(OSQLSynchQuery.java:102) at com.orientechnologies.orient.core.query.OQueryAbstract.execute(OQueryAbstract.java:33) at com.orientechnologies.orient.server.network.protocol.binary.ONetworkProtocolBinary.command(ONetworkProtocolBinary.java:1567) at com.orientechnologies.orient.server.network.protocol.binary.ONetworkProtocolBinary.executeRequest(ONetworkProtocolBinary.java:665) at com.orientechnologies.orient.server.network.protocol.binary.ONetworkProtocolBinary.sessionRequest(ONetworkProtocolBinary.java:399) at com.orientechnologies.orient.server.network.protocol.binary.ONetworkProtocolBinary.execute(ONetworkProtocolBinary.java:218) at com.orientechnologies.common.thread.OSoftThread.run(OSoftThread.java:82) Any solution?
Hi @Fabio83-develop
OrientDB v 2.2 is a pretty old one, I'm afraid it's no longer supported. The easiest thing you can try with zero effort is to upgrade to v 2.2.37 and see if this problem was fixed in the meantime. Even better, if you have a chance to upgrade to latest v 3.1 you will solve this and tons of other problems.
Looking at the stack trace, the problem in the management of a query result set in distributed, an easy patch (but probably not so clean) is a null check here
https://github.com/orientechnologies/orientdb/blob/2.2.x/distributed/src/main/java/com/orientechnologies/orient/server/distributed/impl/ODistributedStorage.java#L550
anyway, even if we find and fix the problem, I doubt we will release a new official hotfix for it, so you should build it on your own
Thanks
Luigi
Ciao Luigi,
è un software che sta in produzione e poter fare l'upgrade comporta cambiamenti si a livello di codice che di query se non sbaglio, anche perchè la gestione tra la 2.2 e la 3.0 o 3.1 è differente. Il problema di questi null sembra causato da un errato cluster. In produzione ci sono due server uno master e l'altro no e sembra che il master provi a recuperare dei dati e non vi risce gettando l'eccezione di nullPointer. Fare l'upgrade alla versione ultima ovvero la 2.2.37 comporta solo l'installazione sul server e la copia del db più i file di configurazione?
Ciao Fabio
IT: Per curiosita', hai un deploy in sharding (ne dubito, ma non si sa mai...)? Se e' un full replica normale, puoi semplicemente provare a fermare i server, copiare il db del master sulla replica e riavviare, con buona probabilita' andra' tutto a posto. L'upgrade a 2.2.37 dovrebbe essere abbastanza semplice, basta copiare i db e la configurazione, ma ti consiglio di fare sempre un test in pre-prod, non si sa mai... Se hai bisogno sono qui
EN: Out of curiosity, do you have a deploy with sharding (I doubt, but you never know...)? If it's a normal full-replica, you can try to stop the servers, copy the DB from the master to the replica and restart, there is a good chance that it will fix the problem. The upgrade is supposed to be straight forward, just copy the DBs and the config to the new installation. Anyway, I strongly suggest you to do some tests in pre-prod If you need help just let me know
Thanks
Luigi
Hi Luigi,
I encountered a configuration problem, the custom configuration is not read, but it seems to always use the default one. It's a problem? or is there an explanation?
Hi Fabio
Which configuration is not being read? From XML or command line?
Thanks
Luigi
In the configuration file orientdb-server-config.xml
<...properties> <..entry value="1" name="db.pool.min"/> <..entry value="50" name="db.pool.max"/> <..entry value="false" name="profiler.enabled"/> </properties...>
The properties aren't read.
I also tried from command line with this command: CONFIG SET
Hi @Fabio83-develop
I remember something similar in old releases, I think it's a bug. As a quick fix, you can pass them via command line, eg.
./server.sh -Ddb5.pool.max=50
or just edit the bat/sh file and add them inside
I hope it helps
Thanks
Luigi
It works for all the properties, just concatenate them, eg.
./server.sh -Ddb5.pool.max=50 -Ddb.pool.min=1
Thanks
Luigi
Hi Luigi,
I tried this command:
./server.sh -Ddb.pool.max=50 -Ddb.pool.min=1 -Dprofiler.enabled=false -Dmemory.directMemory.trackMode=true -Dlog.console.level=info -Dlog.file.level=fine &
and when I run the CONFIG command from the Console, the result is this:
LOCAL SERVER CONFIGURATION +----+---------------------------------------------------+-----------------------------------------------------------------------------+ |# |NAME |VALUE | +----+---------------------------------------------------+-----------------------------------------------------------------------------+ |0 |environment.dumpCfgAtStartup |false | |55 |db.pool.min |1 | |56 |db.pool.max |100 | |119 |profiler.enabled |false | |129 |log.console.level |info | |130 |log.file.level |info | +----+---------------------------------------------------+-----------------------------------------------------------------------------+
It doesn't seem to work
Ciao Fabio
IT: Per curiosita', hai un deploy in sharding (ne dubito, ma non si sa mai...)? Se e' un full replica normale, puoi semplicemente provare a fermare i server, copiare il db del master sulla replica e riavviare, con buona probabilita' andra' tutto a posto. L'upgrade a 2.2.37 dovrebbe essere abbastanza semplice, basta copiare i db e la configurazione, ma ti consiglio di fare sempre un test in pre-prod, non si sa mai... Se hai bisogno sono qui
EN: Out of curiosity, do you have a deploy with sharding (I doubt, but you never know...)? If it's a normal full-replica, you can try to stop the servers, copy the DB from the master to the replica and restart, there is a good chance that it will fix the problem. The upgrade is supposed to be straight forward, just copy the DBs and the config to the new installation. Anyway, I strongly suggest you to do some tests in pre-prod If you need help just let me know
Thanks
Luigi
In produzione i server sono in cluster, e il problema lo da sul nodo principale.