NodeRecord[5] not in use error after deleting nodes

72 views
Skip to first unread message

brian

unread,
Sep 13, 2012, 9:15:42 AM9/13/12
to ne...@googlegroups.com
Hello,

I am writing some unit tests with a "beforeEach" hook that deletes all nodes from the DB with the query:

start n = node(*) delete n

After issuing that query, all further Cypher queries against this DB return the following error:

NodeRecord[5] not in use

I see nothing of interest in the neo4j.*.log or console.log

Configuration:
  • Neo4j 1.8.M06
  • Ubuntu 12.04
  • Oracle JDK 1.6.0_32
  • Auto-indexing enabled on nodes and relationships
Any information would be appreciated.

Thanks.

-brian

brian

unread,
Sep 13, 2012, 9:24:01 AM9/13/12
to ne...@googlegroups.com
Should also have mentioned that I'm accessing the DB via the REST API.

-b

Michael Hunger

unread,
Sep 13, 2012, 10:19:50 AM9/13/12
to ne...@googlegroups.com
- Do you access it directly via http or via a driver?
- can you try if the issue still persists in a recent version (1.8.RC1)

What is one of the queries that fails?

Thanks

Michael

--
 
 

brian

unread,
Sep 13, 2012, 10:39:36 AM9/13/12
to ne...@googlegroups.com
I'm running this in Node.js using the node-neo4j driver. After I do the 'start n = node(*) delete n' query, all further queries fail.  I can correct this only by deleting the DB and creating a new one. The query  that happened to fail first was:

START n = node(*) where n.foo! = 'bar' return n

This query is purposely meant to return an empty result set.

Additional information:  Because of a coding error on my part, the "delete all nodes" query and one or more subsequent queries were issued concurrently.  That is, I didn't wait for the "delete all nodes" query to complete before issuing additional queries. I've since corrected that bug and can no longer recreate this problem.  However, if I remove that synchronization code, I can easily reproduce this problem. Another member of team also reproduced this problem in a slightly different way. He issued  delete requests on multiple nodes in a loop using HTTP DELETE (as opposed to a Cypher query).  He also started issuing Cypher queries before the delete loop was complete and ran into the same error.

I note that a similar issue was raised in the 1.5 timeframe (about a year ago) here: http://neo4j.org/nabble/#nabble-td3513988. I didn't see a resolution though. So I question whether moving my environment to RC1 would be fruitful at this point.

-brian

Mattias Persson

unread,
Sep 13, 2012, 3:31:54 PM9/13/12
to ne...@googlegroups.com


2012/9/13 brian <blevi...@gmail.com>

I'm running this in Node.js using the node-neo4j driver. After I do the 'start n = node(*) delete n' query, all further queries fail.  I can correct this only by deleting the DB and creating a new one. The query  that happened to fail first was:

START n = node(*) where n.foo! = 'bar' return n

This query is purposely meant to return an empty result set.

Additional information:  Because of a coding error on my part, the "delete all nodes" query and one or more subsequent queries were issued concurrently.  That is, I didn't wait for the "delete all nodes" query to complete before issuing additional queries. I've since corrected that bug and can no longer recreate this problem.  However, if I remove that synchronization code, I can easily reproduce this problem. Another member of team also reproduced this problem in a slightly different way. He issued  delete requests on multiple nodes in a loop using HTTP DELETE (as opposed to a Cypher query).  He also started issuing Cypher queries before the delete loop was complete and ran into the same error.

I note that a similar issue was raised in the 1.5 timeframe (about a year ago) here: http://neo4j.org/nabble/#nabble-td3513988. I didn't see a resolution though. So I question whether moving my environment to RC1 would be fruitful at this point.

I'm not sure what is causing your problem, but the problem you referred to for 1.5 has been resolved. It was a problem where at commit time there was a window where a node didn't exist in the graph but still in the index. Your current problem doesn't look like a timing issue like that, does it? I mean, all your queries after your first query fails with the same problem.

-brian
--
 
 



--
Mattias Persson, [mat...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com

brian

unread,
Sep 13, 2012, 6:32:53 PM9/13/12
to ne...@googlegroups.com
That's correct.  After this error occurs, the database is unusable and all queries return the error. I also noted in that previous issue that the author did not have auto-indexing enabled as I do.

-b

brian

unread,
Sep 17, 2012, 9:11:15 AM9/17/12
to ne...@googlegroups.com
I have installed 1.8 RC1 and the error still exists although its behavior has changed slightly.  Now when running my unit tests if I allow the "start n = node(*) delete n" to run concurrently with Cypher queries or node create requests, I see the "record not in use" error spuriously on some Cypher queries. The difference is, when the test completes, my database is still mostly usable. That is, I can continue to issue queries, except for the "delete all query". Once this error occurs, I will receive this error whenever I issue "start n = node(*) delete n" -- even if I issue that query in the Data Browser. When I was running 1.8M7 ,I would receive the "record not in use"  error regardless of the type of Cypher query issued.

Please let me know what other information I can provide.

-brian

Mattias Persson

unread,
Sep 26, 2012, 4:45:44 AM9/26/12
to ne...@googlegroups.com
Would you mind sharing your full test/setup with me?

You could send a link or something directly to mat...@neotechnology.com

Best,
Mattias

2012/9/17 brian <blevi...@gmail.com>

brian

unread,
Sep 26, 2012, 8:48:38 AM9/26/12
to ne...@googlegroups.com
Hi Mattias,

Sharing my environment would be very difficult as there is proprietary code and data involved.  However, I discovered an easy way to reproduce this problem without requiring my environment or any code at all for that matter.  I opened an issue about this and included instructions at:


-brian
Reply all
Reply to author
Forward
0 new messages