[GitHub] [tinkerpop] spike008t commented on issue #1012: TINKERPOP-1889 - Upgrade ws, adding ping and reconnection javascript
Right, now it's based on tp33. Any rejection to add `debug` package to be able to enable debug by using `DEBUG=gremlin:*`? [ Full content available at: https://github.com/apache/tinkerpop/pull/1012 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Updated] (TINKERPOP-2120) GremlinClient.Dispose()
[ https://issues.apache.org/jira/browse/TINKERPOP-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Austin Malpede updated TINKERPOP-2120: -- Summary: GremlinClient.Dispose() (was: Closing Websocket Connections Not Supported In Gremlin.Net) > GremlinClient.Dispose() > --- > > Key: TINKERPOP-2120 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2120 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.3.4 >Reporter: Austin Malpede >Priority: Minor > Labels: usability > Original Estimate: 72h > Remaining Estimate: 72h > > Currently once a websocket connection is established to a tinkerpop server > using Gremlin.Net, it can't be closed manually. > This functionality exists in other gremlin libraries like gremlin-javascript. > Possible solution: Expose a close function in the DriverRemoteConnection > class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2120) GremlinClient.Dispose()
[ https://issues.apache.org/jira/browse/TINKERPOP-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Austin Malpede closed TINKERPOP-2120. - Resolution: Invalid > GremlinClient.Dispose() > --- > > Key: TINKERPOP-2120 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2120 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.3.4 >Reporter: Austin Malpede >Priority: Minor > Labels: usability > Original Estimate: 72h > Remaining Estimate: 72h > > Currently once a websocket connection is established to a tinkerpop server > using Gremlin.Net, it can't be closed manually. > This functionality exists in other gremlin libraries like gremlin-javascript. > Possible solution: Expose a close function in the DriverRemoteConnection > class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-2120) Closing Websocket Connections Not Supported In Gremlin.Net
Austin Malpede created TINKERPOP-2120: - Summary: Closing Websocket Connections Not Supported In Gremlin.Net Key: TINKERPOP-2120 URL: https://issues.apache.org/jira/browse/TINKERPOP-2120 Project: TinkerPop Issue Type: Improvement Components: dotnet Affects Versions: 3.3.4 Reporter: Austin Malpede Currently once a websocket connection is established to a tinkerpop server using Gremlin.Net, it can't be closed manually. This functionality exists in other gremlin libraries like gremlin-javascript. Possible solution: Expose a close function in the DriverRemoteConnection class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Gremlin Dotnet Closing Websocket Connection
Hello, Is it currently possible to close an open websocket connection to the tinkerpop server while using gremlin dotnet? I know its possible in gremlin js. If not I can start working on a fix. Thanks, Austin
[jira] [Closed] (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 ] stephen mallette closed TINKERPOP-2110. --- Resolution: Done Fix Version/s: 3.3.5 3.4.0 > 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 > Fix For: 3.4.0, 3.3.5 > > > 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 closed pull request #1020: TINKERPOP-2110 Added option to change path for java driver
[ pull request closed by spmallette ] [ 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&focusedCommentId=16725321#comment-16725321 ] ASF GitHub Bot commented on TINKERPOP-2110: --- spmallette closed pull request #1020: TINKERPOP-2110 Added option to change path for java driver URL: https://github.com/apache/tinkerpop/pull/1020 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 >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] robertdale 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
[GitHub] [tinkerpop] robertdale commented on issue #1022: TINKERPOP-2118 Bump to groovy 2.4.16
VOTE +1 [ Full content available at: https://github.com/apache/tinkerpop/pull/1022 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Commented] (TINKERPOP-2118) Bump to Groovy 2.4.16
[ https://issues.apache.org/jira/browse/TINKERPOP-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16725302#comment-16725302 ] ASF GitHub Bot commented on TINKERPOP-2118: --- spmallette opened a new pull request #1022: TINKERPOP-2118 Bump to groovy 2.4.16 URL: https://github.com/apache/tinkerpop/pull/1022 https://issues.apache.org/jira/browse/TINKERPOP-2118 All tests pass with `docker/build.sh -t -i` 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 > Bump to Groovy 2.4.16 > - > > Key: TINKERPOP-2118 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2118 > Project: TinkerPop > Issue Type: Improvement > Components: groovy >Affects Versions: 3.3.4 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Major > > Groovy 2.4.16 was just released: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12342996 > as 3.3.x remains on Groovy 2.4.x we need to keep that line updated. 3.4.x is > already on Groovy 2.5.x so this change will be ignored when merged forward. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [tinkerpop] spmallette opened pull request #1022: TINKERPOP-2118 Bump to groovy 2.4.16
https://issues.apache.org/jira/browse/TINKERPOP-2118 All tests pass with `docker/build.sh -t -i` VOTE +1 [ Full content available at: https://github.com/apache/tinkerpop/pull/1022 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Closed] (TINKERPOP-2096) gremlinpython: AttributeError when connection is closed before result is received
[
https://issues.apache.org/jira/browse/TINKERPOP-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-2096.
---
Resolution: Fixed
Assignee: stephen mallette
Fix Version/s: 3.3.5
3.4.0
I provided a better error than before by throwing a {{GremlinServerError}} thus
avoiding the more ambiguous {{AttributeError}}:
https://github.com/apache/tinkerpop/commit/79b5e1cf169f7b9dd53d3c7e642f00d2a97dcc08
> gremlinpython: AttributeError when connection is closed before result is
> received
> --
>
> Key: TINKERPOP-2096
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2096
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.4.0
>Reporter: Bjarte Johansen
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.4.0, 3.3.5
>
>
> When a connection to the server is closed after a write has happened, the
> call to `tornado.websocket.read_message' returns `None` resulting in a
> `AttributeError: 'NoneType' object has no attribute 'decode'` when calling
> `message.decode('utf-8')` in `Protocol.data_recieved`.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (TINKERPOP-2119) Validate C# code samples in docs
[ https://issues.apache.org/jira/browse/TINKERPOP-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann reassigned TINKERPOP-2119: --- Assignee: Florian Hockmann > Validate C# code samples in docs > > > Key: TINKERPOP-2119 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2119 > Project: TinkerPop > Issue Type: Improvement > Components: documentation, dotnet >Affects Versions: 3.4.0 >Reporter: Florian Hockmann >Assignee: Florian Hockmann >Priority: Major > Fix For: 3.4.0 > > > The docs now contain a lot of C# code samples (thanks for that, Stephen and > Daniel). Unfortunately, some of these samples don't use proper C# syntax and > therefore won't compile. > Since I have already noticed in the past that some listings don't work any > more with more recent versions of Gremlin.Net, we should not only correct > these listings, but actually validate them automatically to ensure that we > notice once the listings don't work any more. > I limited the scope to C# here because I already noticed problems there, but > this could of course also be done later for the other GLVs that can't be > verified with the usual doc generation process. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [DISCUSS] Recognizing Contributions
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 #1016: WIP: Add request pipelining and ConnectionPool sizes TINKERPOP-1775 and TINKERPOP-1774
Since I don't really have a strong opinion on this and because I see your points about simpler code and predictable latencies, I'll change this to use a fixed size unless someone else chimes in and explains why we should use dynamic sizes. [ Full content available at: https://github.com/apache/tinkerpop/pull/1016 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Updated] (TINKERPOP-2119) Validate C# code samples in docs
[ https://issues.apache.org/jira/browse/TINKERPOP-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-2119: Affects Version/s: 3.4.0 > Validate C# code samples in docs > > > Key: TINKERPOP-2119 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2119 > Project: TinkerPop > Issue Type: Improvement > Components: documentation, dotnet >Affects Versions: 3.4.0 >Reporter: Florian Hockmann >Priority: Major > Fix For: 3.4.0 > > > The docs now contain a lot of C# code samples (thanks for that, Stephen and > Daniel). Unfortunately, some of these samples don't use proper C# syntax and > therefore won't compile. > Since I have already noticed in the past that some listings don't work any > more with more recent versions of Gremlin.Net, we should not only correct > these listings, but actually validate them automatically to ensure that we > notice once the listings don't work any more. > I limited the scope to C# here because I already noticed problems there, but > this could of course also be done later for the other GLVs that can't be > verified with the usual doc generation process. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-2119) Validate C# code samples in docs
Florian Hockmann created TINKERPOP-2119: --- Summary: Validate C# code samples in docs Key: TINKERPOP-2119 URL: https://issues.apache.org/jira/browse/TINKERPOP-2119 Project: TinkerPop Issue Type: Improvement Components: documentation, dotnet Reporter: Florian Hockmann Fix For: 3.4.0 The docs now contain a lot of C# code samples (thanks for that, Stephen and Daniel). Unfortunately, some of these samples don't use proper C# syntax and therefore won't compile. Since I have already noticed in the past that some listings don't work any more with more recent versions of Gremlin.Net, we should not only correct these listings, but actually validate them automatically to ensure that we notice once the listings don't work any more. I limited the scope to C# here because I already noticed problems there, but this could of course also be done later for the other GLVs that can't be verified with the usual doc generation process. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [tinkerpop] spmallette commented on issue #1021: TINKERPOP-2116: Use explicit Bindinds object instead of a 2-tuple
i will look into that "bindings" section after this merges. [ Full content available at: https://github.com/apache/tinkerpop/pull/1021 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[GitHub] [tinkerpop] jorgebay commented on issue #1016: WIP: Add request pipelining and ConnectionPool sizes TINKERPOP-1775 and TINKERPOP-1774
The behaviour that motivated TINKERPOP-1774 was the unbounded number of connections that was being created, but it's true that references the java driver as the reference implementation, sorry about that. I think having a fixed amount of connections leads to a predictable behaviour (latency / resource provisioning / etc) and a simpler implementation. With request pipelining, there are few cases where the user will need more than 1 connection (in that case, the user can configure a different fixed number). [ Full content available at: https://github.com/apache/tinkerpop/pull/1016 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[GitHub] [tinkerpop] FlorianHockmann commented on issue #1016: WIP: Add request pipelining and ConnectionPool sizes TINKERPOP-1775 and TINKERPOP-1774
> I would recommend to remove the dynamic pool sizes (min/max), but I leave it > up to you. In my experience, the use for dynamic pools is very limited. > Usually when there is spike in requests, opening new connections can lead to > a latency with no added benefit (there is a limited number of requests that a > server can process at any given time). You mean that the pool should simply have a fixed size instead? Wasn't that what you asked for in TINKERPOP-1774: > Similar to the java connection pool, we should limit the maximum amount of > connections and start with a minimum number. or what do you mean exactly with dynamic pool sizes? I don't really have a strong opinion on that. My assumptions was just that it's probably hard for users to set a good value for the size. Dynamic pool sizes basically avoid this as the pool will automatically grow to a size that is big enough to handle the number of parallel requests the application typically uses. Later on, we could also add a mechanism to remove idle connections if they were only created because of a spike in requests as too many idle connection seem to be problematic with certain providers (especially CosmosDB, judging from the tickets we currently have open). Although this mechanism would of course make the latency problem even worse for spikes when the connections were already closed again since the last spike. [ Full content available at: https://github.com/apache/tinkerpop/pull/1016 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[GitHub] [tinkerpop] aboudreault commented on issue #1021: TINKERPOP-2116: Use explicit Bindinds object instead of a 2-tuple
@FlorianHockmann Yep, already checked to update it, but this docs is not anymore in master. [ Full content available at: https://github.com/apache/tinkerpop/pull/1021 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[GitHub] [tinkerpop] jorgebay commented on pull request #1016: WIP: Add request pipelining and ConnectionPool sizes TINKERPOP-1775 and TINKERPOP-1774
I think this loop (recursion) should be extracted out of this method, otherwise the first time the CAS will occur but the following sendings will never win the CAS op (`_writeInProgress` will already be `1`) . [ Full content available at: https://github.com/apache/tinkerpop/pull/1016 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[GitHub] [tinkerpop] jorgebay commented on pull request #1016: WIP: Add request pipelining and ConnectionPool sizes TINKERPOP-1775 and TINKERPOP-1774
`AggregateException.Handle()` should be called here, as the faulted task is not going to be yielded to the user. Additionally, I think if the sending fails, the whole connection should be "trashed" (empty queues, respond with the errors back to the user) and close the connection. [ Full content available at: https://github.com/apache/tinkerpop/pull/1016 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[GitHub] [tinkerpop] jorgebay commented on pull request #1016: WIP: Add request pipelining and ConnectionPool sizes TINKERPOP-1775 and TINKERPOP-1774
I like this strict behaviour for throttling. [ Full content available at: https://github.com/apache/tinkerpop/pull/1016 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[GitHub] [tinkerpop] jorgebay commented on pull request #1016: WIP: Add request pipelining and ConnectionPool sizes TINKERPOP-1775 and TINKERPOP-1774
This check is nice to have, but given that the connection might switch to closed immediately after this call, I think there is no point in doing a CAS operation here. A `Volatile.Read()` would do it and it's order of magnitude cheaper :) [ Full content available at: https://github.com/apache/tinkerpop/pull/1016 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[GitHub] [tinkerpop] FlorianHockmann commented on issue #1021: TINKERPOP-2116: Use explicit Bindinds object instead of a 2-tuple
Can you please also update [the docs](http://tinkerpop.apache.org/docs/current/reference/#_bindings) accordingly? Otherwise, new users will still try the tuple version. [ Full content available at: https://github.com/apache/tinkerpop/pull/1021 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Work started] (TINKERPOP-2118) Bump to Groovy 2.4.16
[ https://issues.apache.org/jira/browse/TINKERPOP-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TINKERPOP-2118 started by stephen mallette. --- > Bump to Groovy 2.4.16 > - > > Key: TINKERPOP-2118 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2118 > Project: TinkerPop > Issue Type: Improvement > Components: groovy >Affects Versions: 3.3.4 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Major > > Groovy 2.4.16 was just released: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12342996 > as 3.3.x remains on Groovy 2.4.x we need to keep that line updated. 3.4.x is > already on Groovy 2.5.x so this change will be ignored when merged forward. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-2118) Bump to Groovy 2.4.16
stephen mallette created TINKERPOP-2118: --- Summary: Bump to Groovy 2.4.16 Key: TINKERPOP-2118 URL: https://issues.apache.org/jira/browse/TINKERPOP-2118 Project: TinkerPop Issue Type: Improvement Components: groovy Affects Versions: 3.3.4 Reporter: stephen mallette Assignee: stephen mallette Groovy 2.4.16 was just released: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12342996 as 3.3.x remains on Groovy 2.4.x we need to keep that line updated. 3.4.x is already on Groovy 2.5.x so this change will be ignored when merged forward. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [tinkerpop] jorgebay commented on issue #1000: TINKERPOP-1942 New Binary Serialization Format
I've added `MetricsSerializer` that was missing. VOTE +1 [ Full content available at: https://github.com/apache/tinkerpop/pull/1000 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
