[GitHub] [tinkerpop] spmallette commented on pull request #1038: TINKERPOP-2130 Fix default parameter assignment in Connection ctor
just peeking in on this PR - I'll let @jorgebay make the final word on this, but I guess the reason we needed to add this line was so that calls further down that use `options` and not `this.options` will work properly? shouldn't we just consistently use `this.options` rather than try to interchangeably use both as well as alter the state of the `options` parameter? [ Full content available at: https://github.com/apache/tinkerpop/pull/1038 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[GitHub] [tinkerpop] spmallette commented on issue #1039: TINKERPOP-2131 Gremlin.Net: Better explain connection pool exceptions
VOTE +1 [ Full content available at: https://github.com/apache/tinkerpop/pull/1039 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[GitHub] [tinkerpop] spmallette commented on issue #1039: TINKERPOP-2131 Gremlin.Net: Better explain connection pool exceptions
VOTE +1 - though a CHANGELOG entry would be good [ Full content available at: https://github.com/apache/tinkerpop/pull/1039 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Updated] (TINKERPOP-2133) Use neo4j index lookup in Neo4jGraphStep with HasContainers containing TextP predicates
[
https://issues.apache.org/jira/browse/TINKERPOP-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-2133:
Labels: (was: easyfix performance)
Priority: Trivial (was: Major)
Good oneadded "trivial" status as I think this would be a good "starter"
issue for someone who wants to do an initial contribution to TinkerPop.
> Use neo4j index lookup in Neo4jGraphStep with HasContainers containing TextP
> predicates
> ---
>
> Key: TINKERPOP-2133
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2133
> Project: TinkerPop
> Issue Type: Improvement
> Components: neo4j
>Affects Versions: 3.4.0
>Reporter: Andrey Skorikov
>Priority: Trivial
>
> When evaluating a Neo4jGraphStep with HasContainers containing TextP
> predicates, for example: g.V().has("Label", "name",
> TextP.containing("substring")), a scan over all vertices with the label is
> performed.
> Currently, an index lookup is used only when an complete property value is
> given, that is g.V().has("Label", "name", "exact") - implemented
> [here|https://github.com/apache/tinkerpop/blob/master/neo4j-gremlin/src/main/java/org/apache/tinkerpop/gremlin/neo4j/structure/trait/NoMultiNoMetaNeo4jTrait.java#L172].
> Allowing to use an index lookup for TextP predicates like containing,
> startingWith would substantially improve the evaluation performance.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2133) Use neo4j index lookup in Neo4jGraphStep with HasContainers containing TextP predicates
[
https://issues.apache.org/jira/browse/TINKERPOP-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742104#comment-16742104
]
Andrey Skorikov commented on TINKERPOP-2133:
Thanks. I have implemented a simple patch for this, but have not created a pull
request yet. I will create a pull request and reference this ticket in it.
> Use neo4j index lookup in Neo4jGraphStep with HasContainers containing TextP
> predicates
> ---
>
> Key: TINKERPOP-2133
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2133
> Project: TinkerPop
> Issue Type: Improvement
> Components: neo4j
>Affects Versions: 3.4.0
>Reporter: Andrey Skorikov
>Priority: Trivial
>
> When evaluating a Neo4jGraphStep with HasContainers containing TextP
> predicates, for example: g.V().has("Label", "name",
> TextP.containing("substring")), a scan over all vertices with the label is
> performed.
> Currently, an index lookup is used only when an complete property value is
> given, that is g.V().has("Label", "name", "exact") - implemented
> [here|https://github.com/apache/tinkerpop/blob/master/neo4j-gremlin/src/main/java/org/apache/tinkerpop/gremlin/neo4j/structure/trait/NoMultiNoMetaNeo4jTrait.java#L172].
> Allowing to use an index lookup for TextP predicates like containing,
> startingWith would substantially improve the evaluation performance.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2134) Bump to Groovy 2.5.5
stephen mallette created TINKERPOP-2134: --- Summary: Bump to Groovy 2.5.5 Key: TINKERPOP-2134 URL: https://issues.apache.org/jira/browse/TINKERPOP-2134 Project: TinkerPop Issue Type: Improvement Components: groovy Affects Versions: 3.4.0 Reporter: stephen mallette Assignee: stephen mallette Bump to Groovy 2.5.5: http://groovy-lang.org/changelogs/changelog-2.5.5.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [tinkerpop] jorgebay commented on pull request #1038: TINKERPOP-2130 Fix default parameter assignment in Connection ctor
I think the safest bet would be to use double assignment, that way is concise
and less error prone, dwyt @nivsherf ?
```javascript
this.options = options = options || {};
```
[ Full content available at: https://github.com/apache/tinkerpop/pull/1038 ]
This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
Re: [DISCUSS] Recognizing Contributions
I just pushed the rework of the model for "Release Notes" and contributions - as I mentioned during the 3.4.0/3.3.5/3.2.11 release process what I'd thought would work didn't work out so well in practice. I've instead come up with this form: https://github.com/apache/tinkerpop/commit/b968099ae17e1104469fa0a18425aecfcb7b2d09 which replaces the "javadocs" link on the download/release page with a "contributors" link which pops up a modal containing the "git shortlog" (and whatever else we'd like to see in there). I only did it for the most recent release at this point (and have not yet published). You can generate-home.sh to view it. Kuppitz is going to try to automate generation of the previous release modals. Once that's done, we can publish the site with that change. On Wed, Dec 19, 2018 at 11:20 AM Stephen Mallette wrote: > Some time has passed since this thread was last touched, but I got around > to documenting the things discussed here: > > > https://github.com/apache/tinkerpop/commit/4b10cfda1f85aefe3017ec7fc25791d409719329 > (Release Notes) > > https://github.com/apache/tinkerpop/commit/0f82111ecd1a1c966760c9009d486eae4adc8a3e > (Contributor List) > > Note that I didn't deal with "Friends of TinkerPop" stuff. I'm still not > sure what that should be and it probably needs more discussion. Anyway, > please let me know if there are any concerns or things forgotten...if not > we will proceed with this direction with/after 3.4.0 > > On Mon, Oct 8, 2018 at 2:33 PM Stephen Mallette > wrote: > >> I'm going to assume lazy consensus on the general points of this proposal >> as its been a few days now since I originally posted it. I will try to >> document the general aspects of what was presented here in the dev docs and >> will post back here when I've done so. I think we can take this discussion >> in two separate directions at this point one for the release notes changes >> and one for the web site (probably new email threads i guess). I don't >> think we need to try to force any of this in for the current release that >> we're dealing with. In fact I'll probably make the dev doc changes in a >> branch so that they don't go in as part of this release. >> >> On Wed, Oct 3, 2018 at 11:59 AM Stephen Mallette >> wrote: >> >>> There has been some discussion within the PMC over the last month or so >>> about how to recognize the various contributors to Apache TinkerPop. We >>> currently have this: >>> >>> http://tinkerpop.apache.org/#committers >>> >>> but we think some changes should occur. First, we would like to better >>> recognize the list of folks who contributed during a particular release >>> period to include: >>> >>> 1. git contributions for a release will be aggregated and presented in >>> the release notes. >>> 2. non-code contributions to a release will be added and presented in >>> the release notes. >>> >>> I don't know if "release notes" means CHANGELOG or Upgrade Docs or >>> something else - I suppose that remains up for discussion. The issue is >>> more about capturing these contributions better on a per-release basis. >>> >>> Second, we expect to modify the website in that space given in the link >>> above - rather than have it read "Apache TinkerPop Committers" it will >>> instead be "Apache TinkerPop Contributors" and it will include both >>> official committers as well as "Friends of the TinkerPop" (working >>> title...suggest something better??). >>> >>> For the committers section, individuals can keep this information up to >>> date themselves (because they have access to the git repository), but we >>> will ask for a bio update from each person every 6 months via email with a >>> request to indicate an "active" or "inactive" status. If you are "inactive" >>> it simply means that you aren't currently participating in the project. >>> Irrespective of being active or inactive, your name and tenure >>> accomplishments remain present on the front page of the web site. Being >>> "inactive" does not affect your status as an Apache committer/PMC member - >>> that remains unchanged. Should you decide that you are inactive at some >>> point, note that there is no special process to become "active" again - you >>> just have to update your bio to do so. The format of the committer section >>> would be basically the same as it is now but would have active and inactive >>> sections, sorted by date of TinkerPop commitership (or membership in the >>> pre-Apache days), as they are now. >>> >>> The new "Friends of the TinkerPop" section will be a listing of those >>> people who have promoted the project in some positive capacity (e.g. >>> developed a third-party library that has some good benefit to the >>> community) but aren't committers/pmc members. >>> >>> There's still a fair bit to sort out in terms of how this will be >>> implemented, but these are the general big picture items. Please let us >>> know what you think and then we can drive into details. >>> >>> >>> >>> >>> . >>> >>
[GitHub] [tinkerpop] FlorianHockmann commented on issue #1039: TINKERPOP-2131 Gremlin.Net: Better explain connection pool exceptions
> though a CHANGELOG entry would be good Right, I just added an entry. [ Full content available at: https://github.com/apache/tinkerpop/pull/1039 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Created] (TINKERPOP-2135) Gremlin.Net ConnectionPool doesn't handle closed idle connections properly
Florian Hockmann created TINKERPOP-2135:
---
Summary: Gremlin.Net ConnectionPool doesn't handle closed idle
connections properly
Key: TINKERPOP-2135
URL: https://issues.apache.org/jira/browse/TINKERPOP-2135
Project: TinkerPop
Issue Type: Bug
Affects Versions: 3.4.0
Reporter: Florian Hockmann
The {{ConnectionPool}} of Gremlin.Net checks whether a connection is actually
still open before it returns that connection to execute a request ([in
{{SelectLeastUsedConnection}}|https://github.com/apache/tinkerpop/blob/67764ba23d67d9f62048c22e8bbcefb87463584e/gremlin-dotnet/src/Gremlin.Net/Driver/ConnectionPool.cs#L124]):
{code}
if (connection.IsOpen) return true;
DefinitelyDestroyConnection(connection);
{code}
However, the connection stays in the pool as {{DefinitelyDestroyConnection}}
only disposes the connection:
{code}
private void DefinitelyDestroyConnection(Connection connection)
{
connection.Dispose();
Interlocked.Decrement(ref _nrConnections);
}
{code}
This is problematic as it can potentially fill the pool with unusable
connections. Even worse, {{SelectLeastUsedConnection}} will likely return such
an unusable connection since it only checks for the number of in-flight
requests and a disposed connection won't have any in-flight requests. This
should ultimately result in a {{NoConnectionAvailableException}} when the pool
tried {{_poolSize}} times to return such a disposed connection.
Note: This all can only happen when a connection was closed while sitting idle
in the pool which shouldn't usually happen due to the heartbeat. If a
connection problem occurs during the execution of a request, then all
connections will be closed and new ones will be created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2135) Gremlin.Net ConnectionPool doesn't handle closed idle connections properly
[
https://issues.apache.org/jira/browse/TINKERPOP-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann updated TINKERPOP-2135:
Description:
The {{ConnectionPool}} of Gremlin.Net checks whether a connection is actually
still open before it returns that connection to execute a request ([in
{{SelectLeastUsedConnection}}|https://github.com/apache/tinkerpop/blob/67764ba23d67d9f62048c22e8bbcefb87463584e/gremlin-dotnet/src/Gremlin.Net/Driver/ConnectionPool.cs#L124]):
{code:java}
if (connection.IsOpen) return true;
DefinitelyDestroyConnection(connection);
{code}
However, the connection stays in the pool as {{DefinitelyDestroyConnection}}
only disposes the connection:
{code:java}
private void DefinitelyDestroyConnection(Connection connection)
{
connection.Dispose();
Interlocked.Decrement(ref _nrConnections);
}
{code}
This is problematic as it can potentially fill the pool with unusable
connections. Even worse, {{SelectLeastUsedConnection}} will likely return such
an unusable connection since it only checks for the number of in-flight
requests and a disposed connection won't have any in-flight requests. This
means that {{GetConnectionFromPool}} will try to get a connection until another
still valid connection also has no in-flight requests.
Note: This all can only happen when a connection was closed while sitting idle
in the pool which shouldn't usually happen due to the heartbeat. If a
connection problem occurs during the execution of a request, then all
connections will be closed and new ones will be created.
was:
The {{ConnectionPool}} of Gremlin.Net checks whether a connection is actually
still open before it returns that connection to execute a request ([in
{{SelectLeastUsedConnection}}|https://github.com/apache/tinkerpop/blob/67764ba23d67d9f62048c22e8bbcefb87463584e/gremlin-dotnet/src/Gremlin.Net/Driver/ConnectionPool.cs#L124]):
{code}
if (connection.IsOpen) return true;
DefinitelyDestroyConnection(connection);
{code}
However, the connection stays in the pool as {{DefinitelyDestroyConnection}}
only disposes the connection:
{code}
private void DefinitelyDestroyConnection(Connection connection)
{
connection.Dispose();
Interlocked.Decrement(ref _nrConnections);
}
{code}
This is problematic as it can potentially fill the pool with unusable
connections. Even worse, {{SelectLeastUsedConnection}} will likely return such
an unusable connection since it only checks for the number of in-flight
requests and a disposed connection won't have any in-flight requests. This
should ultimately result in a {{NoConnectionAvailableException}} when the pool
tried {{_poolSize}} times to return such a disposed connection.
Note: This all can only happen when a connection was closed while sitting idle
in the pool which shouldn't usually happen due to the heartbeat. If a
connection problem occurs during the execution of a request, then all
connections will be closed and new ones will be created.
> Gremlin.Net ConnectionPool doesn't handle closed idle connections properly
> --
>
> Key: TINKERPOP-2135
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2135
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Florian Hockmann
>Priority: Major
>
> The {{ConnectionPool}} of Gremlin.Net checks whether a connection is actually
> still open before it returns that connection to execute a request ([in
> {{SelectLeastUsedConnection}}|https://github.com/apache/tinkerpop/blob/67764ba23d67d9f62048c22e8bbcefb87463584e/gremlin-dotnet/src/Gremlin.Net/Driver/ConnectionPool.cs#L124]):
> {code:java}
> if (connection.IsOpen) return true;
> DefinitelyDestroyConnection(connection);
> {code}
> However, the connection stays in the pool as {{DefinitelyDestroyConnection}}
> only disposes the connection:
> {code:java}
> private void DefinitelyDestroyConnection(Connection connection)
> {
> connection.Dispose();
> Interlocked.Decrement(ref _nrConnections);
> }
> {code}
> This is problematic as it can potentially fill the pool with unusable
> connections. Even worse, {{SelectLeastUsedConnection}} will likely return
> such an unusable connection since it only checks for the number of in-flight
> requests and a disposed connection won't have any in-flight requests. This
> means that {{GetConnectionFromPool}} will try to get a connection until
> another still valid connection also has no in-flight requests.
> Note: This all can only happen when a connection was closed while sitting
> idle in the pool which shouldn't usually happen due to the heartbeat. If a
> connection problem occurs during the execution of a request, then all
> connections will be closed and new ones will be created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76
[jira] [Comment Edited] (TINKERPOP-2090) After running backend for a day or so System.IO.IOException keep throwing
[
https://issues.apache.org/jira/browse/TINKERPOP-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742327#comment-16742327
]
Greg Pepin edited comment on TINKERPOP-2090 at 1/14/19 5:22 PM:
In trying out the new version, I've run across a new issue. In response to the
original issue, I put in a lot of additional error handling and retry logic in
my application to handle cosmosDb specific errors. In doing so I wrote some
resiliency tests that are designed to execute many high-cost traversal tasks in
parallel to ensure that the code is resilient enough for all of those
traversals to execute successfully. However after updating to 3.4.0, I am
getting errors in that test. I end up getting WebSocketExceptions with a
messages saying that the operation completed successfully. Any idea why that
would be the case?
was (Author: papapep):
In trying out the new version, I've run across a new issue. In response to
this issue, I put in a lot of additional error handling and retry logic in my
application to handle cosmosDb specific errors. In doing so I wrote some
resiliency tests that are designed to execute many high-cost traversal tasks in
parallel to ensure that the code is resilient enough for all of those
traversals to execute successfully. However after updating to 3.4.0, I am
getting errors in that test. I end up getting WebSocketExceptions with a
messages saying that the operation completed successfully. Any idea why that
would be the case?
> After running backend for a day or so System.IO.IOException keep throwing
> -
>
> Key: TINKERPOP-2090
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2090
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.4.0
> Environment: .NET Core 2.1.5
> Microsoft Azure
>Reporter: Saber Karmous
>Priority: Critical
>
> .NET Core 2.1.5
> Gremlin.NET 3.4.0-rc2
> We're using the latest RC of the Gremlin client. And we have a gremlin client
> that's being injected as a singleton through out IoC container. After running
> the backend for a day or two it keeps throwing System.IO.IOExceptions. If we
> restart the application it works again.
> We use Polly for out retry strategy, and retrying for 9 times. But it keeps
> failing.
> I added the stack trace below. Reproducing is a bit of a pain in the behind,
> you have to wait for a day or two for the exception to occur.
> {noformat}
> *no* System.IO.IOException:
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at
> System.Runtime.CompilerServices.ConfiguredValueTaskAwaitable+ConfiguredValueTaskAwaiter.GetResult
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at
> System.Net.Security.SslStreamInternal+d`1.MoveNext
> (System.Net.Security, Version=4.1.1.0, Culture=neutral,
> PublicKeyToken=b03f5f7f11d50a3a)
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at
> System.Runtime.CompilerServices.ConfiguredValueTaskAwaitable+ConfiguredValueTaskAwaiter.GetResult
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at
> System.Net.Security.SslStreamInternal+d`1.MoveNext
> (System.Net.Security, Version=4.1.1.0, Culture=neutral,
> PublicKeyToken=b03f5f7f11d50a3a)
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification
> (System.Private.CoreLib, Versio
[jira] [Commented] (TINKERPOP-2090) After running backend for a day or so System.IO.IOException keep throwing
[
https://issues.apache.org/jira/browse/TINKERPOP-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742327#comment-16742327
]
Greg Pepin commented on TINKERPOP-2090:
---
In trying out the new version, I've run across a new issue. In response to
this issue, I put in a lot of additional error handling and retry logic in my
application to handle cosmosDb specific errors. In doing so I wrote some
resiliency tests that are designed to execute many high-cost traversal tasks in
parallel to ensure that the code is resilient enough for all of those
traversals to execute successfully. However after updating to 3.4.0, I am
getting errors in that test. I end up getting WebSocketExceptions with a
messages saying that the operation completed successfully. Any idea why that
would be the case?
> After running backend for a day or so System.IO.IOException keep throwing
> -
>
> Key: TINKERPOP-2090
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2090
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.4.0
> Environment: .NET Core 2.1.5
> Microsoft Azure
>Reporter: Saber Karmous
>Priority: Critical
>
> .NET Core 2.1.5
> Gremlin.NET 3.4.0-rc2
> We're using the latest RC of the Gremlin client. And we have a gremlin client
> that's being injected as a singleton through out IoC container. After running
> the backend for a day or two it keeps throwing System.IO.IOExceptions. If we
> restart the application it works again.
> We use Polly for out retry strategy, and retrying for 9 times. But it keeps
> failing.
> I added the stack trace below. Reproducing is a bit of a pain in the behind,
> you have to wait for a day or two for the exception to occur.
> {noformat}
> *no* System.IO.IOException:
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at
> System.Runtime.CompilerServices.ConfiguredValueTaskAwaitable+ConfiguredValueTaskAwaiter.GetResult
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at
> System.Net.Security.SslStreamInternal+d`1.MoveNext
> (System.Net.Security, Version=4.1.1.0, Culture=neutral,
> PublicKeyToken=b03f5f7f11d50a3a)
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at
> System.Runtime.CompilerServices.ConfiguredValueTaskAwaitable+ConfiguredValueTaskAwaiter.GetResult
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at
> System.Net.Security.SslStreamInternal+d`1.MoveNext
> (System.Net.Security, Version=4.1.1.0, Culture=neutral,
> PublicKeyToken=b03f5f7f11d50a3a)
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at Gremlin.Net.Driver.WebSocketConnection+d__7.MoveNext
> (Gremlin.Net, Version=3.4.0.0, Culture=neutral,
> PublicKeyToken=d2035e9aa387a711)
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken=7cec85d7bea7798e)
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification
> (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral,
> PublicKeyToken
[GitHub] [tinkerpop] nivsherf commented on pull request #1038: TINKERPOP-2130 Fix default parameter assignment in Connection ctor
Makes sense @jorgebay. I updated the code accordingly. [ Full content available at: https://github.com/apache/tinkerpop/pull/1038 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Assigned] (TINKERPOP-2132) In concurrent scenes kerberos authentication failed
[
https://issues.apache.org/jira/browse/TINKERPOP-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette reassigned TINKERPOP-2132:
---
Assignee: stephen mallette
> In concurrent scenes kerberos authentication failed
> ---
>
> Key: TINKERPOP-2132
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2132
> Project: TinkerPop
> Issue Type: Bug
> Components: driver, server
>Affects Versions: 3.3.2
>Reporter: kaiyangzhang
>Assignee: stephen mallette
>Priority: Major
>
> *Scenes:*
> 1. Gremlin Server Kerberos Authentication
> 2. Multithreading using the same client
>
> {code:java}
> DriverRemoteConnection connection =
> DriverRemoteConnection.using(cluster,"graphbase");
> GraphTraversalSource g = graph.traversal().withRemote(connection);
> Thread demo1 = new Thread(new ThreadDemo1(g));
> Thread demo2 = new Thread(new ThreadDemo1(g));
> Thread demo3 = new Thread(new ThreadDemo1(g));
> Thread demo4 = new Thread(new ThreadDemo1(g));
> Thread demo5 = new Thread(new ThreadDemo1(g));
> Thread demo6 = new Thread(new ThreadDemo1(g));
> Thread demo7 = new Thread(new ThreadDemo1(g));
> Thread demo8 = new Thread(new ThreadDemo1(g));
> Thread demo9 = new Thread(new ThreadDemo1(g));
> Thread demo10 = new Thread(new ThreadDemo1(g));
> {code}
>
> *ERROR INFO*
> {code:java}
> Exception in thread "Thread-4" java.util.concurrent.CompletionException:
> org.apache.tinkerpop.gremlin.driver.exception.ResponseException: Failed to
> authenticate
> at
> java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:375)
> at java.util.concurrent.CompletableFuture.join(CompletableFuture.java:1934)
> at org.apache.tinkerpop.gremlin.driver.ResultSet.one(ResultSet.java:107)
> at
> org.apache.tinkerpop.gremlin.driver.ResultSet$1.hasNext(ResultSet.java:159)
> at org.apache.tinkerpop.gremlin.driver.ResultSet$1.next(ResultSet.java:166)
> at org.apache.tinkerpop.gremlin.driver.ResultSet$1.next(ResultSet.java:153)
> at
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteTraversal$TraverserIterator.next(DriverRemoteTraversal.java:142)
> at
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteTraversal$TraverserIterator.next(DriverRemoteTraversal.java:127)
> at
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteTraversal.nextTraverser(DriverRemoteTraversal.java:108)
> at
> org.apache.tinkerpop.gremlin.process.remote.traversal.step.map.RemoteStep.processNextStart(RemoteStep.java:80)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.hasNext(DefaultTraversal.java:192)
> at com.huawei.graphbase.gremlin.ThreadDemo1.println(ThreadDemo1.java:48)
> at com.huawei.graphbase.gremlin.ThreadDemo1.run(ThreadDemo1.java:32)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.tinkerpop.gremlin.driver.exception.ResponseException:
> Failed to authenticate
> at
> org.apache.tinkerpop.gremlin.driver.Handler$GremlinResponseHandler.channelRead0(Handler.java:246)
> at
> org.apache.tinkerpop.gremlin.driver.Handler$GremlinResponseHandler.channelRead0(Handler.java:197)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:373)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:359)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:351)
> at
> org.apache.tinkerpop.gremlin.driver.Handler$GremlinSaslAuthenticationHandler.channelRead0(Handler.java:123)
> at
> org.apache.tinkerpop.gremlin.driver.Handler$GremlinSaslAuthenticationHandler.channelRead0(Handler.java:67)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:373)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:359)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:351)
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:373)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:359)
> at
> io.netty.channel.AbstractChannelHandlerC
