You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "stephen mallette (JIRA)" <ji...@apache.org> on 2017/05/16 11:47:04 UTC

[jira] [Commented] (TINKERPOP-1674) Traversals reference elements after deletion

    [ https://issues.apache.org/jira/browse/TINKERPOP-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16012200#comment-16012200 ] 

stephen mallette commented on TINKERPOP-1674:
---------------------------------------------

I looked at your code a bit - seems like you had to do a lot to get this to crop up. I don't imagine there's a way to make this happen in a more simplistic fashion? Perhaps you've already tried this but If it is something related to one thread deleting a vertex that another thread references, couldn't this example be simplified to just that scenario?

> Traversals reference elements after deletion
> --------------------------------------------
>
>                 Key: TINKERPOP-1674
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1674
>             Project: TinkerPop
>          Issue Type: Bug
>          Components: neo4j
>    Affects Versions: 3.2.3, 3.2.4
>         Environment: Demonstrated on Ubuntu, OSX
>            Reporter: SmedbergM
>
> In a multiprocessor environment, a traversal will sometimes reference vertices which another thread/processor has already deleted. This causes the entire traversal to fail in an unrecoverable fashion and throw an uncaught exception.
> MWE: https://github.com/SmedbergM/neo4j-deletion-error
> Gist containing logging output: https://gist.github.com/SmedbergM/5fcf0d98a255e7d346b85b98bcc1ec0d
> This error has cropped up persistently over several months/releases (dating back to 3.1.x or earlier). I have not tried to diff back/bisect to find introduction time of the behavior.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)