cancel
Showing results for 
Search instead for 
Did you mean: 

Head's Up! These forums are read-only. All users and content have migrated. Please join us at community.neo4j.com.

Neo4j hanging on CALL dbms.listQueries()

I am running the 4.3.5 Community Edition Docker image. The database seems to be hanging and refusing to process any queries. I tried to run CALL dbms.listQueries() from the web interface, but this too doesn't return. Here is an excerpt from the debug.log:

2021-10-11 06:51:50.040+0000 DEBUG [i.n.h.s.SslHandler] [id: 0x45f1be3e, L:/172.30.0.2:7687 - R:/xxx.xxx.xxx.xxx:39730] HANDSHAKEN: protocol:TLSv1.2 cipher suite:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
2021-10-11 06:51:50.041+0000 DEBUG [i.n.h.c.h.w.WebSocketServerHandshaker] [id: 0x45f1be3e, L:/172.30.0.2:7687 - R:/xxx.xxx.xxx.xxx:39730] WebSocket version V13 server handshake
2021-10-11 06:51:50.042+0000 DEBUG [i.n.h.c.h.w.WebSocketServerHandshaker] WebSocket version 13 server handshake key: eJll1oKUgqW3fU5osdNpHg==, response: 0WE2T0/fqGQS5YO8SZHAk+M7Qdc=
2021-10-11 06:51:50.637+0000 DEBUG [o.n.p.b.r.GetRoutingTableProcedure] Routing result for database DatabaseId{c595bc8c[neo4j]} and routing context Map{address -> String("example.com:7687")} is RoutingResult{routeEndpoints=[example.com:7687], writeEndpoints=[example.com:7687], readEndpoints=[example.com:7687], timeToLiveMillis=300000}
2021-10-11 06:51:51.592+0000 DEBUG [i.n.h.s.SslHandler] [id: 0x975f388b, L:/172.30.0.2:7687 - R:/xxx.xxx.xxx.xxx:39732] HANDSHAKEN: protocol:TLSv1.2 cipher suite:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
2021-10-11 06:51:51.594+0000 DEBUG [i.n.h.c.h.w.WebSocketServerHandshaker] [id: 0x975f388b, L:/172.30.0.2:7687 - R:/xxx.xxx.xxx.xxx:39732] WebSocket version V13 server handshake
2021-10-11 06:51:51.594+0000 DEBUG [i.n.h.c.h.w.WebSocketServerHandshaker] WebSocket version 13 server handshake key: MGY/YrBfYPT+dwmd1otrcQ==, response: 8DftjDfwmriaSkHvstiCJOInoiM=
2021-10-11 06:51:52.541+0000 DEBUG [i.n.h.s.SslHandler] [id: 0xe3d5f37a, L:/172.30.0.2:7687 - R:/xxx.xxx.xxx.xxx:39734] HANDSHAKEN: protocol:TLSv1.2 cipher suite:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
2021-10-11 06:51:52.543+0000 DEBUG [i.n.h.c.h.w.WebSocketServerHandshaker] [id: 0xe3d5f37a, L:/172.30.0.2:7687 - R:/xxx.xxx.xxx.xxx:39734] WebSocket version V13 server handshake
2021-10-11 06:51:52.543+0000 DEBUG [i.n.h.c.h.w.WebSocketServerHandshaker] WebSocket version 13 server handshake key: 5Q4PR7hl+JCemhqt0PL/Ow==, response: fxPoGQrxK6790urjGSYOnTseM90=
2021-10-11 06:51:54.049+0000 DEBUG [i.n.h.s.SslHandler] [id: 0x80bdd677, L:/172.30.0.2:7687 - R:/xxx.xxx.xxx.xxx:39736] HANDSHAKEN: protocol:TLSv1.2 cipher suite:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
2021-10-11 06:51:54.051+0000 DEBUG [i.n.h.c.h.w.WebSocketServerHandshaker] [id: 0x80bdd677, L:/172.30.0.2:7687 - R:/xxx.xxx.xxx.xxx:39736] WebSocket version V13 server handshake
2021-10-11 06:51:54.051+0000 DEBUG [i.n.h.c.h.w.WebSocketServerHandshaker] WebSocket version 13 server handshake key: xCTPXTqXmmNsdKM/rVbsFg==, response: hYgNPWHCKCMxlosMRATv1NChGYQ=
2021-10-11 06:51:54.622+0000 DEBUG [o.n.p.b.r.GetRoutingTableProcedure] Routing result for database DatabaseId{c595bc8c[neo4j]} and routing context Map{address -> String("example.com:7687")} is RoutingResult{routeEndpoints=[example.com:7687], writeEndpoints=[example.com:7687], readEndpoints=[example.com:7687], timeToLiveMillis=300000}

There is no output in the neo4j.log file.

I would like to restart the server but I am worried about leaving the database in an inconsistent state.

Any suggestions for how I can debug this would be appreciated.

2 REPLIES 2

I think it is better to turn off authentication protocol by choosing proper configuration params.
Once you know it is starting the normal way then you can tune other configuration parameters like authentication strings. Please check if it is memory issue and consider using memrec tool for configuring -xms and -xmx switches with appropriate numbers in GB.

Sameer Gijare

Hi Sameer

Thanks for the response and the suggestion to use memrec.

I bit the bullet and restarted the database. Thankfully it managed to recover. I'll monitor to see if this happens again.