You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2016/08/02 20:08:20 UTC
[jira] [Commented] (TINKERPOP-1350) Server locks when submitting
parallel requests on session
[ https://issues.apache.org/jira/browse/TINKERPOP-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404681#comment-15404681 ]
ASF GitHub Bot commented on TINKERPOP-1350:
-------------------------------------------
GitHub user spmallette opened a pull request:
https://github.com/apache/tinkerpop/pull/367
TINKERPOP-1350 was never quite fixed in 3.1.3.
Unfortunately, more testing revealed that the fix for the problem was only masked by the changes in 3.1.3.
Changed response encoding to not use the session executor when the session has an error condition it is trying to serialize. This should be fine as there is no need to serialized an error condition as part of a transaction and thus no need to have the session thread to do it. That in turn frees up the worker executor to serialize and cancel long run jobs in the session. Removed recommendations for submitting parallel requests on a session from docs.
Works in full with `mvn clean install && mvn verify -pl gremlin-server -DskipIntegrationTests=false`
VOTE +1
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1350
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/367.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #367
----
commit 57ef449ded52e5c11072e7a626eebcfcc13889c4
Author: Stephen Mallette <sp...@genoprime.com>
Date: 2016-08-02T19:59:19Z
TINKERPOP-1350 was never quite fixed in 3.1.3.
Changed response encoding to not use the session executor when the session has an error condition it is trying to serialize. This should be fine as there is no need to serialized an error condition as part of a transaction and thus no need to have the session thread to do it. That in turn frees up the worker executor to serialize and cancel long run jobs in the session. Removed recommendations for submitting parallel requests on a session from docs.
----
> Server locks when submitting parallel requests on session
> ---------------------------------------------------------
>
> Key: TINKERPOP-1350
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1350
> Project: TinkerPop
> Issue Type: Bug
> Components: server
> Affects Versions: 3.1.2-incubating
> Reporter: stephen mallette
> Assignee: stephen mallette
> Priority: Critical
> Fix For: 3.1.4, 3.2.2
>
>
> This really is only a problem when there is some form of long blocking script submitted and only on a session when done in parallel, like:
> {code}
> final ResultSet first = client.submit(
> "Object mon1 = 'mon1';\n" +
> "synchronized (mon1) {\n" +
> " mon1.wait();\n" +
> "} ");
> final ResultSet second = client.submit(
> "Object mon2 = 'mon2';\n" +
> "synchronized (mon2) {\n" +
> " mon2.wait();\n" +
> "}");
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)