[jira] [Closed] (TINKERPOP-2097) Create a DriverRemoteConnection with an initialized Client
[
https://issues.apache.org/jira/browse/TINKERPOP-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-2097.
---
Resolution: Done
Fix Version/s: 3.3.5
3.4.0
This was a really minor change - implemented via CTR on :
https://github.com/apache/tinkerpop/commit/f9d702757bbaf07a09ab13d534f2071a729610ee
> Create a DriverRemoteConnection with an initialized Client
> --
>
> Key: TINKERPOP-2097
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2097
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver
>Affects Versions: 3.3.4
>Reporter: Kevin Gallardo
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.4.0, 3.3.5
>
>
> Currently the only way to create a {{DriverRemoteConnection}} is by providing
> a Cluster or a Configuration, which will then initialize a {{Client}}
> internally. Users have to create a new {{Client}} for every
> {{DriverRemoteConnection}}.
> It would be convenient to add the possibility to provide an already
> initialized {{Client}} so that you don't cause a new connection to the server
> for each {{DriverRemoteConnection}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (TINKERPOP-2097) Create a DriverRemoteConnection with an initialized Client
[
https://issues.apache.org/jira/browse/TINKERPOP-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on TINKERPOP-2097 started by stephen mallette.
---
> Create a DriverRemoteConnection with an initialized Client
> --
>
> Key: TINKERPOP-2097
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2097
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver
>Affects Versions: 3.3.4
>Reporter: Kevin Gallardo
>Assignee: stephen mallette
>Priority: Minor
>
> Currently the only way to create a {{DriverRemoteConnection}} is by providing
> a Cluster or a Configuration, which will then initialize a {{Client}}
> internally. Users have to create a new {{Client}} for every
> {{DriverRemoteConnection}}.
> It would be convenient to add the possibility to provide an already
> initialized {{Client}} so that you don't cause a new connection to the server
> for each {{DriverRemoteConnection}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [tinkerpop] dkuppitz commented on issue #1020: TINKERPOP-2110 Added option to change path for java driver
VOTE +1 [ Full content available at: https://github.com/apache/tinkerpop/pull/1020 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Commented] (TINKERPOP-2110) Allow Connection on Different Path (from /gremlin)
[ https://issues.apache.org/jira/browse/TINKERPOP-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723269#comment-16723269 ] ASF GitHub Bot commented on TINKERPOP-2110: --- spmallette opened a new pull request #1020: TINKERPOP-2110 Added option to change path for java driver URL: https://github.com/apache/tinkerpop/pull/1020 https://issues.apache.org/jira/browse/TINKERPOP-2110 Builds with `mvn clean install && mvn verify -pl gremlin-driver,gremlin-server -DskipIntegrationTests=false` VOTE +1 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Allow Connection on Different Path (from /gremlin) > -- > > Key: TINKERPOP-2110 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2110 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Affects Versions: 3.3.4 >Reporter: Antony Scerri >Priority: Major > > Hi > It appears that the Java driver for Gremlin clients only supports connecting > to hosts on a fixed path (/gremlin). This is based on the code in > tinkerpop/gremlin-driver/src/main/java/org/apache/tinkerpop/gremlin/driver/Host.java > > The function makeUriFromAddress doesn't provide a method for customizing the > path to use. The need arises from proxying multiple server instances through > a simple NGINX type proxy where you want to host each one under a different > path, currently you would need to use a different hostname or port on the > proxy which isn't so desirable. It would seem a relatively simple non > breaking change and provides a little bit more flexibility in usage. Other > clients like the Python one provide this naturally through passing of the > websocket URL. > Thanks > Tony -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (TINKERPOP-2110) Allow Connection on Different Path (from /gremlin)
[ https://issues.apache.org/jira/browse/TINKERPOP-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TINKERPOP-2110 started by stephen mallette. --- > Allow Connection on Different Path (from /gremlin) > -- > > Key: TINKERPOP-2110 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2110 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Affects Versions: 3.3.4 >Reporter: Antony Scerri >Assignee: stephen mallette >Priority: Major > > Hi > It appears that the Java driver for Gremlin clients only supports connecting > to hosts on a fixed path (/gremlin). This is based on the code in > tinkerpop/gremlin-driver/src/main/java/org/apache/tinkerpop/gremlin/driver/Host.java > > The function makeUriFromAddress doesn't provide a method for customizing the > path to use. The need arises from proxying multiple server instances through > a simple NGINX type proxy where you want to host each one under a different > path, currently you would need to use a different hostname or port on the > proxy which isn't so desirable. It would seem a relatively simple non > breaking change and provides a little bit more flexibility in usage. Other > clients like the Python one provide this naturally through passing of the > websocket URL. > Thanks > Tony -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [tinkerpop] spmallette opened pull request #1020: TINKERPOP-2110 Added option to change path for java driver
https://issues.apache.org/jira/browse/TINKERPOP-2110 Builds with `mvn clean install && mvn verify -pl gremlin-driver,gremlin-server -DskipIntegrationTests=false` VOTE +1 [ Full content available at: https://github.com/apache/tinkerpop/pull/1020 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Closed] (TINKERPOP-1849) Provide a way to fold() with an index
[
https://issues.apache.org/jira/browse/TINKERPOP-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-1849.
-
Resolution: Fixed
Fix Version/s: 3.4.0
> Provide a way to fold() with an index
> -
>
> Key: TINKERPOP-1849
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1849
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.0
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.4.0
>
>
> In Groovy you can call {{withIndex()}} to generate output like this:
> {code}
> gremlin> g.V().fold().next().withIndex()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> We can currently simulate this with Gremlin via:
> {code}
> gremlin>
> g.V().project("a","b").by().by(select("x").count(local)).store("x").map(union(select('a'),
> select('b')).fold()).fold().next()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> but it's not easy to follow, efficient, or potentially foolproof. Perhaps we
> can add an option to {{fold()}} that would take an enum of "fold operators".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1849) Provide a way to fold() with an index
[
https://issues.apache.org/jira/browse/TINKERPOP-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723174#comment-16723174
]
ASF GitHub Bot commented on TINKERPOP-1849:
---
asfgit closed pull request #1011: TINKERPOP-1849 Provide a way to fold() with
an index
URL: https://github.com/apache/tinkerpop/pull/1011
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Provide a way to fold() with an index
> -
>
> Key: TINKERPOP-1849
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1849
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.0
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Major
>
> In Groovy you can call {{withIndex()}} to generate output like this:
> {code}
> gremlin> g.V().fold().next().withIndex()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> We can currently simulate this with Gremlin via:
> {code}
> gremlin>
> g.V().project("a","b").by().by(select("x").count(local)).store("x").map(union(select('a'),
> select('b')).fold()).fold().next()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> but it's not easy to follow, efficient, or potentially foolproof. Perhaps we
> can add an option to {{fold()}} that would take an enum of "fold operators".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [tinkerpop] asfgit closed pull request #1011: TINKERPOP-1849 Provide a way to fold() with an index
[ pull request closed by asfgit ] [ Full content available at: https://github.com/apache/tinkerpop/pull/1011 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Closed] (TINKERPOP-2114) Document common Gremlin anti-patterns
[ https://issues.apache.org/jira/browse/TINKERPOP-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kuppitz closed TINKERPOP-2114. - Resolution: Fixed Fix Version/s: 3.3.5 3.4.0 > Document common Gremlin anti-patterns > - > > Key: TINKERPOP-2114 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2114 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Affects Versions: 3.3.4 >Reporter: Daniel Kuppitz >Assignee: Daniel Kuppitz >Priority: Major > Fix For: 3.4.0, 3.3.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2114) Document common Gremlin anti-patterns
[ https://issues.apache.org/jira/browse/TINKERPOP-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723167#comment-16723167 ] ASF GitHub Bot commented on TINKERPOP-2114: --- asfgit closed pull request #1019: TINKERPOP-2114 Document common Gremlin anti-patterns URL: https://github.com/apache/tinkerpop/pull/1019 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Document common Gremlin anti-patterns > - > > Key: TINKERPOP-2114 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2114 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Affects Versions: 3.3.4 >Reporter: Daniel Kuppitz >Assignee: Daniel Kuppitz >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [tinkerpop] asfgit closed pull request #1019: TINKERPOP-2114 Document common Gremlin anti-patterns
[ pull request closed by asfgit ] [ Full content available at: https://github.com/apache/tinkerpop/pull/1019 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[GitHub] [tinkerpop] spmallette commented on pull request #1019: TINKERPOP-2114 Document common Gremlin anti-patterns
oh...now i get it. i think i was pausing my reading in the wrong place. i think a comma after "before" would help: "Ignoring the anti-patterns that were discussed before, there's not much wrong with the traversal, but note the two chained `where()`-steps..." [ Full content available at: https://github.com/apache/tinkerpop/pull/1019 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[GitHub] [tinkerpop] dkuppitz commented on pull request #1019: TINKERPOP-2114 Document common Gremlin anti-patterns
"Ignoring the anti-patterns that were discussed before" -- I added this because
the queries use `both()` (instead of `both()`), which was declared to be
an anti-pattern in an earlier section. I can change it to
`both("knows","created")`, but I wanted the reader to focus on the `where()`
steps, hence I kept the other steps as short as possible.
[ Full content available at: https://github.com/apache/tinkerpop/pull/1019 ]
This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[GitHub] [tinkerpop] spmallette commented on issue #1019: TINKERPOP-2114 Document common Gremlin anti-patterns
This is great - VOTE +1 [ Full content available at: https://github.com/apache/tinkerpop/pull/1019 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[GitHub] [tinkerpop] spmallette commented on pull request #1019: TINKERPOP-2114 Document common Gremlin anti-patterns
I feel like there's maybe two different things that you mean here so I can't say what the correction is but there's something awkward about how this phrase is written: > Ignoring the anti-patterns that were discussed before there's not much wrong > with the traversal, [ Full content available at: https://github.com/apache/tinkerpop/pull/1019 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[DISCUSS] code freeze 3.2.11/3.3.5/3.4.0
While I think we could go on for every adding things to 3.4.0 I think it's time to cut it off and release. There's too many good things in there to hold for any longer. We are looking at releasing 3.2.11, 3.3.5 and 3.4.0. I'd propose we polish up remaining items this week, set for code freeze 12/22 and then build the release for VOTE the week of the 31st. I assume that there are enough PMC members around the holiday period to VOTE on the release artifacts. If the VOTE has to stay open a bit longer than is typical then that's ok. I'm happy to just do all three releases myself this time as it might be hard to coordinate with others during the holiday period. We still have a number of important things to finish - specifically: 1. code reviews on open PRs with ids > 1000 2. finish up the GraphBinary - jorge is adding two more serializers and then i think we can call this a day and put it up for review. 3. documentation review 4. anything else? As usual, let's continue to use this thread for release coordination heading into code freeze.
[GitHub] [tinkerpop] spmallette commented on issue #1013: TINKERPOP-2105 - connection.py - add finally to return connection to the client pool i…
Thanks for fixing the existing tests. Two things: 1. I presume this is a bug on 3.3.x as well as the unreleased 3.4.0. If so, could you please re-target this PR at the `tp33` branch 2. You provided a small python script to reproduce that problem. Is there any reason you could not convert that into a test as part of this PR so that we have some insurance against regression? > ideally the client (who handle the connection pool) should allocate and free > the connections and not the connection itself I think your approach is fine, but I suppose that the `Client` which borrows the `Connection` should be the thing to return it to the pool. If you felt like refactoring that at some point I think that approach would be ok as well. Thanks. [ Full content available at: https://github.com/apache/tinkerpop/pull/1013 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Updated] (TINKERPOP-2105) Gremlin-Python connection not returned back to the pool on exception from gremlin server
[ https://issues.apache.org/jira/browse/TINKERPOP-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-2105: Affects Version/s: 3.3.4 > Gremlin-Python connection not returned back to the pool on exception from > gremlin server > > > Key: TINKERPOP-2105 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2105 > Project: TinkerPop > Issue Type: Bug > Components: driver, python >Affects Versions: 3.3.4 >Reporter: Kunal >Priority: Major > Attachments: issue.py > > > The is an issue with the gremlin-python driver where for requests that return > an exception from the gremlin server result in the connection not being > returned to the pool. I have a reproducer and have attached the code to this > issue as issue.py. > The root cause seems to be in the error handling logic in connection.py refer > to > [https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/driver/connection.py#L75-L81.] > In exception scenarios an exception is thrown on line 77 which cause line 81 > to be not executed. > The result of this is if we use a singleton connection (as in the attached > reproducer) on the client side with default pool size of 4 then the client > becomes unresponsive after 4 requests that result in server throwing an > exception. > This issue is reproducible with tinkergraph reference implementation as well. > > I tried a workaround by changing connection.py locally which did work for me > but not sure if that would be the ideal fix. Basically in the _receive() > function in connection.py I added a try finally and call the > self._pool.put_nowait(self) in the finally block > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
