I'm definitely modifying the graph at the same time; that's why this is happening. But my assumption was that that shouldn't be breaking Neo4j -- I thought requests are transactional/serialized.
I don't have a repro test at the moment, but the behavior is really simple. Here's an example analogy. We have a subgraph like User A [LIKES] Object 1 and also [LIKES] Object 2: (Object 1) <--LIKES-- (User A) --LIKES--> (Object 2) One operation will delete the [LIKE] to Object 1, while another operation queries whether User A [LIKES] Object 2. The query can be a Cypher query, e.g.: START user=(123), obj=(456) MATCH (user)-[rel]->(obj) WHERE rel~TYPE = 'LIKES' RETURN rel But we've also seen this bug where we used a simple traverse (specifying just max depth 1 and the LIKES relationship type). When you say "looks like a normal case", do you mean that the query should indeed fail like this? I wouldn't expect this -- what can I do to prevent an error? Should I be retrying? Thanks Peter! Aseem On Sun, Nov 20, 2011 at 10:08 PM, Peter Neubauer < peter.neuba...@neotechnology.com> wrote: > Aseem, > What query are you running, and are you modifying your graph on any way at > the same time? Do you have a small example test reproducing this? Looks > like a normal case where this relationship is deleted for some reason, no > failure. Maybe a better Cypher error should point that out... > > /peter > > Sent from my phone, please excuse typos and autocorrection. > On Nov 21, 2011 3:22 AM, "Aseem Kishore" <aseem.kish...@gmail.com> wrote: > > > Hey guys, > > > > If we put our app under a bit of load, creating and removing nodes and > > relationships concurrently, sometimes we get back a 500 Internal Server > > Error from the REST API when we do a traverse or Cypher query. Here's an > > example stack trace: > > > > https://gist.github.com/1381423 > > > > We're running Neo4j. 1.4 still, but does this stack trace provide any > > insight/ideas into what might be wrong, what we could do as a workaround, > > etc.? Can I provide any other info that would help? > > > > It goes without saying that our assumption is that Neo4j shouldn't be > > failing/crashing on queries; our expectation was that operations are > > transactional, etc. > > > > Thanks! > > > > Aseem > > _______________________________________________ > > Neo4j mailing list > > User@lists.neo4j.org > > https://lists.neo4j.org/mailman/listinfo/user > > > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
