-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deadlock when concurrent node modification in berkeley #1623
Comments
Hi, I have a similar issue but the error is not exactly the same
Which is identical to this old issue with Titan This is with the latest version of Janus and Berkely available. |
Any update or plan on fixing this? |
Any update on this. I am facing the same Lock issue in janus with berkeley on version 0.5.3. I just did the work around by setting isolation level as READ_UNCOMMITTED This is not happening in Janus 0.4.0 |
Using JanusGraph 0.6.3 with berkleyje we are running into the same problems. Actually can reproduce both, deadlock and locktimeout. Lock mode and isolation level are used synonymously in this thread, but there are two berkley related Janusgraph options, so I am not sure which are meant. But even if we set both like this in
The issues still remain. Only by changing EnvironmentConfig.LOCK_TIMEOUT (additionally) things change. Sadly, not found a way to do this programatically, as JanusGraph is not exposing the |
Few details on the deadlock situation. We encountered this only if we have two concurrent transactions which both first read and then update properties of an identical set of vertices (code on our side was an error, so deadlock is not as much an issue for us atm). Not sure if the transaction system should handle this case or the deadlock is expected, but just for completeness here is the stracktrace:
As for the locktimeout issue, this went away removing the lock timeout (and nothing froze). Here is our stacktrace for diagnosis:
|
Sadly, we encountered different exceptions after applying the workarounds (remove locktimeout, set configuration to READ_UNCOMMITTED). As a first intuition I think they all are happening when JanusGraph is implicitly creating the schema in a concurrent setting. It seems they all go away if we do not rely on implicit schema creation and generate the schema beforehand, but importantly only single threaded, so not concurrently. In that case so far we havent seen the numerous errors which I will post below. So, I guess JanusGraph has some problems with automatic schema creation either only with the lock modes READ_UNCOMMITTED or in general with the berkleyje backend... So here are all the stacktraces we encountered when JanusGraph had to automatically create the schema inside the concurrent transactions:
|
…s [tp-tests] Related to JanusGraph#1623 and JanusGraph#4425 Signed-off-by: Oleksandr Porunov <[email protected]>
…s [tp-tests] Related to JanusGraph#1623 and JanusGraph#4425 Signed-off-by: Oleksandr Porunov <[email protected]>
…s [tp-tests] Related to JanusGraph#1623 and JanusGraph#4425 Signed-off-by: Oleksandr Porunov <[email protected]>
Created PR #4701 which exposes all BerkeleyJE config options to the user. This may help configuring necessary timeouts as well as other options. |
Related to JanusGraph#1623 and JanusGraph#4425 Signed-off-by: Oleksandr Porunov <[email protected]>
Related to JanusGraph#1623 and JanusGraph#4425 Signed-off-by: Oleksandr Porunov <[email protected]>
Related to #1623 and #4425 Signed-off-by: Oleksandr Porunov <[email protected]>
Example of code
Exception
For fix it, change default isolation level (LOCK_MODE) to LockMode.READ_UNCOMMITTED
But if we want to use default lock mode, we can increase EnvironmentConfig.LOCK_TIMEOUT (default 500ms), so another way to fix that make it parametr customizable
The text was updated successfully, but these errors were encountered: