Re: [DISCUSS] Gremlin JavaScript release

[Jorge Bay Gondra]

First week of April sounds good to me.

On Fri, Feb 23, 2018 at 12:34 PM, Stephen Mallette 
wrote:

> Ok - i was just asking for clarity because this thread started as a
> discussion on a "beta" release.
>
> Our last release was in december, so I suppose it would be time to get
> another one out. I do have a number of issues I'd like to complete for
> these versions - can we tentatively say that we release first week of
> April? That would give us about four more weeks of development (opportunity
> to fix more GLV tests across the board plus the other issues I'd like to
> see done) plus a week of code freeze. is that a good target?
>
> On Fri, Feb 23, 2018 at 3:20 AM, Jorge Bay Gondra <
> jorgebaygon...@gmail.com>
> wrote:
>
> > I'm referring to an official release of all artifacts for versions 3.2.8
> > and 3.3.2. The JavaScript GLV has been reviewed and merged, the test
> suite
> > is in good shape. This GLV has been in the pipeline for a long time now,
> I
> > think we should make the last effort for it to be generally available.
> >
> > BTW, npm fixed the issue for the gremlin package:
> > https://www.npmjs.com/org/tinkerpop
> >
> > On Thu, Feb 22, 2018 at 11:03 PM, Stephen Mallette  >
> > wrote:
> >
> > > You're referring to a gremlin-javascript release candidate and not to a
> > > general official release of all artifacts (java, .net, etc) for
> > > 3.3.2/3.2.8), right?
> > >
> > > On Wed, Feb 21, 2018 at 9:57 AM, Jorge Bay Gondra <
> > > jorgebaygon...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > > Regarding the npm issue, we created a ticket on the npm issue
> tracker:
> > > > https://github.com/npm/registry/issues/281 and contacted support.
> > > >
> > > > We are waiting for a response from them, but in any case if it takes
> to
> > > > long for npm support to look at it, Jean-Baptiste could grant the
> > > > individual members of tinkerpop:developers / release manager access,
> so
> > > > that should not be blocking an official release of the JavaScript
> GLV.
> > > >
> > > > Can we start discussing a timeline for 3.2.8/3.3.2?
> > > >
> > > > Thanks,
> > > > Jorge
> > > >
> > > > On Tue, Feb 20, 2018 at 10:23 AM, Jorge Bay Gondra <
> > > > jorgebaygon...@gmail.com
> > > > > wrote:
> > > >
> > > > > Any luck?
> > > > >
> > > > > On Wed, Feb 14, 2018 at 9:43 AM, Jorge Bay Gondra <
> > > > > jorgebaygon...@gmail.com> wrote:
> > > > >
> > > > >> hm... that's weird... It's working on my end with a different
> > > package...
> > > > >>
> > > > >> Maybe use a newer npm cli version?
> > > > >>
> > > > >> If npm access is still failing after cli upgrade, you could use
> npm
> > > > owner
> > > > >>  to add any other tinkerpop
> > member
> > > > >>  as co-owner and we
> > > could
> > > > >> try to run npm access from there.
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Tue, Feb 13, 2018 at 4:55 PM, Jean-Baptiste Musso <
> > > jbmu...@gmail.com
> > > > >
> > > > >> wrote:
> > > > >>
> > > > >>> Getting a 403 Forbidden error:
> > > > >>>
> > > > >>> $ npm access grant read-write tinkerpop:developers gremlin
> > > > >>> npm http request PUT
> > > > >>> https://registry.npmjs.org/-/team/tinkerpop/developers/package
> > > > >>> npm http 403 https://registry.npmjs.org/-/t
> > > > >>> eam/tinkerpop/developers/package
> > > > >>> npm ERR! code E403
> > > > >>> npm ERR! Forbidden : -/team/tinkerpop/developers/package
> > > > >>>
> > > > >>> Also:
> > > > >>>
> > > > >>> $ npm whoami
> > > > >>> npm http request GET https://registry.npmjs.org/-/whoami
> > > > >>> npm http 200 https://registry.npmjs.org/-/whoami
> > > > >>> jbmusso
> > > > >>>
> > > > >>> Funny, I got confused in my previous posts and just realized
> that:
> > I
> > > > was
> > > > >>> prettier sure I owned gremlin-javascript, but I used to publish
> > > > >>> under gremlin-client.
> > > > >>>
> > > > >>> Jean-Baptiste
> > > > >>>
> > > > >>> On Tue, Feb 13, 2018 at 3:55 PM, Jorge Bay Gondra <
> > > > >>> jorgebaygon...@gmail.com>
> > > > >>> wrote:
> > > > >>>
> > > > >>> > gremlin-javascript is not org scoped but "tinkerpop:developers"
> > has
> > > > >>> write
> > > > >>> > access to it:
> > > > >>> >
> > > > >>> > npm access ls-packages tinkerpop:developers
> > > > >>> >
> > > > >>> >
> > > > >>> > What's the response for:
> > > > >>> >
> > > > >>> > npm access grant read-write tinkerpop:developers gremlin
> > > > >>> >
> > > > >>> >
> > > > >>> >
> > > > >>> > On Tue, Feb 13, 2018 at 3:42 PM, Jean-Baptiste Musso <
> > > > >>> jbmu...@gmail.com>
> > > > >>> > wrote:
> > > > >>> >
> > > > >>> > > Hmm. It looks like you can only grant access to team of
> > > developers
> > > > >>> for
> > > > >>> > > @scoped package, but not for standard (unscoped) packages.
> > > > >>> > > I can make the "tinkerpop" user owner of that "gremlin"
> > package,
> > > if
> > > > >>> that
> > > > >>> > > helps.
> > > > >>> > >
> > > > >>> > > 

[jira] [Commented] (TINKERPOP-1804) Has step doesn't consider strategy vertexProperty filters

[stephen mallette (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381192#comment-16381192
 ] 

stephen mallette commented on TINKERPOP-1804:
-

I've looked at this one from time to time since it was created. I still can't 
figure out what can be done here. Ultimately, the only way I can think of to 
get the result you want is for the strategy to produce this traversal:

{code}
gremlin> 
sg.V().hasLabel("person").has('location','seattle').filter(properties('location').hasValue('seattle').hasNot('endTime')).valueMap()
==>[name:[matthias],location:[seattle]]
{code}

Basically that 
{{filter(properties('location').hasValue('seattle').hasNot('endTime'))}} ends 
up being responsible for filtering out the "marko" vertex that we don't want. 
Not sure how to make {{SubgraphStrategy}} do that

I'd say that right now, the {{vertexProperties()}} configuration on the 
{{SubgraphStrategy.Builder}} really is only responsible for filtering out what 
shows up in calls to things like {{valueMap()}}. It can't do anything to build 
up more complex filters for vertices. The two configurations operate 
independently from one another.


> Has step doesn't consider strategy vertexProperty filters
> -
>
> Key: TINKERPOP-1804
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1804
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Simone Cattani
>Priority: Major
>
> Has step, when used in a traversal defined with strategies, doesn't consider 
> filters applied on properties by the strategies
> Let's consider the crew example adding an old location for Marko, in Seattle, 
> the current Matthias' location.
> {code}
> graph = TinkerFactory.createTheCrew()
> g = graph.traversal()
> g.V().has('name', 'marko').property('location', 'seattle', 'startTime', 1994, 
> 'endTime', 1997)
> {code}
> Defining a strategy that considers just current location I can correctly 
> obtain the list of current locations
> {code}
> g.withStrategies(SubgraphStrategy.build().vertexProperties(or(hasLabel(neq('location')),hasNot('endTime'))).create()).V().hasLabel("person").valueMap()
> ==>[name:[marko],location:[santa fe]]
> ==>[name:[stephen],location:[purcellville]]
> ==>[name:[matthias],location:[seattle]]
> ==>[name:[daniel],location:[aachen]]
> {code}
> But requiring people (currently) living in Seattle, I obtain Marko, too
> {code}
> g.withStrategies(SubgraphStrategy.build().vertexProperties(or(hasLabel(neq('location')),hasNot('endTime'))).create()).V().hasLabel("person").has('location',
>  'seattle').valueMap()
> ==>[name:[marko],location:[santa fe]]
> ==>[name:[matthias],location:[seattle]]
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

RE: [Discuss] Expose metadata from Gremlin Server to Clients.

[Ashwini Singh]

Completely agree on making the change for other drivers too. The plan from our 
side is to make changes to other drivers as well.  My focus on Gremlin.Net was 
just for an example . Yes, we should make change to Gremlin Server to write 
the metadata for testing.

I agree to adding this to ResultSet and exposing this as part of every response 
for all the drivers and follow the same pattern as JAVA.

On the gremlin GVL part,  I agree we should support this on traversal for 
bytecode as well. For now, we do not have support for bytecode but we are 
actively working on that and need support for metadata there as well. Thanks 
for bringing this up. Just wanted to understand how we track issues at 
tinkerpop, Can we spilt the change to support for gremlin request/script first 
and bytecode/traversal separately? If we prefer to split the change in chunks, 
but completely fine with one change.

Thanks,
Ashwini Singh
Software Engineer @ Azure Cosmos DB

-Original Message-
From: Stephen Mallette  
Sent: Wednesday, February 28, 2018 9:58 AM
To: dev@tinkerpop.apache.org
Subject: Re: [Discuss] Expose metadata from Gremlin Server to Clients.

This newly created issue might be related to this in some way:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FTINKERPOP-1906=04%7C01%7Cashwsing%40microsoft.com%7C614b32ff7f984c66554808d57ed4d22b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636554374885412678%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1=w7pyg6JF4KMbPdpBg6t%2F8cE%2BflbnCQQdyMUgc6HDrXw%3D=0

On Wed, Feb 28, 2018 at 11:37 AM, Florian Hockmann 
wrote:

> I agree that we also should make this metadata available for 
> traversals since we want to move users away from sending Gremlin 
> scripts as strings and instead use Bytecode based GLVs.
>
> Regarding Gremlin.Net: I think that the implementation would be very 
> similar to how it can be implemented in the Java driver as we tried to 
> stay close to the Java driver in general. The only difference is 
> probably that we currently don't have a ResultSet in Gremlin.Net, but 
> that's only because I didn't see much value in adding that. Metadata 
> would of course be a good argument to also implement a ResultSet in 
> Gremlin.Net and then the implementation should be really basically the 
> same as in the Java driver.
>
>
> Am 28.02.2018 um 16:15 schrieb Stephen Mallette:
> > I'm fine with using the last response message as the carrier for 
> > this metadata on a particular request. I can't really tell if there 
> > is much
> work
> > to do on Gremlin Server itself here. It seems like most of the work 
> > must occur on the various drivers (you mention the .NET api, but all 
> > of the drivers would need to support this feature). However, I would 
> > think that
> we
> > would want Gremlin Server itself to append in some kind metadata 
> > (maybe query time? something easy) so that we could write tests 
> > for the drivers in TinkerPop itself. There is also the question of 
> > how we would expose this metadata to GLVs which don't see response 
> > messages at all. A traversal might need some metadata itself so that 
> > the user could retrieve the server metadata from that. The 
> > implementation between Java and the
> GLVs
> > might be different here as the GLV traversal class is typically 
> > quite lightweight and only used for generating bytecode.
> >
> > I'm not so sure I like the  SubmitAsynWithHeaders()  but I don't 
> > think
> too
> > much about how the .NET driver works. Is there a reason to not 
> > always return metadata? could it be expensive to do so? If we just 
> > added an
> extra
> > method how would remote traversals configure this option? I think we 
> > need another way. Generally speaking, for Java, I think I would like 
> > to see
> the
> > metadata available to the ResultSet somehow which would in turn make 
> > it pretty easy to get it on to a Traversal instance once that 
> > facility was made available.but as to how to enable or disable 
> > the return of the metadata, i'm not sure how that should work just 
> > yet - i need to think on that some more.
> >
> > For committers who work on GLVs, please take a look at this thread 
> > and offer your thoughts on how this might work in the GLV driver you 
> > tend to have the most knowledge on. Let's see if we can come to one 
> > nice unified solution. At that point, we can setup a ticket in JIRA and go 
> > from there.
> >
> > Ashwini, thanks for offering a pull request for this by the way. 
> > Once we get consensus on how to do this, we'll see if tasks need to 
> > be divided
> and
> > how you might contribute.
> >
> >
> >
> > On Mon, Feb 26, 2018 at 6:45 PM, Ashwini Singh < 
> > ashws...@microsoft.com.invalid> wrote:
> >
> >> Hi Stephen,
> >>
> >> Thanks for considering the change.
> >>
> >> We would be more inclined towards the 

[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable

[Roman Kreisel (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381065#comment-16381065
 ] 

Roman Kreisel commented on TINKERPOP-1906:
--

[~Florian Hockmann]: Thanks for solving the status code thing... I was so sure 
it just contains the numerical code, that I just didn't see it.

I think i might've also brought some additional confusion into this discussion 
with the link posted above 
([https://docs.microsoft.com/en-us/rest/api/documentdb/http-status-codes-for-documentdb])
 - I guess this might be valid only for the Cosmos DB's RESTful interface, but 
not for the Gremlin/Tinkerpop API.

> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Priority: Major
> Attachments: message.txt, stacktrace.txt
>
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to 
> react on the GremlinService's Response. The only content is the exception's 
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode 
> or anything else that's responded by the service.
>  
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a 
> "Request Rate to Large" response, in case you have high load on your 
> database. In such a case, you want to be able to detect this "error" and just 
> retry after a few milliseconds (i'm not sure, but i think even a proposal for 
> this retry-timeout is given in the response)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1897) Provide Docker images of Gremlin Server and Console

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381047#comment-16381047
 ] 

ASF GitHub Bot commented on TINKERPOP-1897:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/802
  
I just reset my docker account password and it turns out that i'm one of 
the owners on the TinkerPop organization - so that's good.


> Provide Docker images of Gremlin Server and Console
> ---
>
> Key: TINKERPOP-1897
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1897
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: console, server
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
>
> TinkerPop should provide Docker images of Gremlin Server and Gremlin Console 
> that are deployed together with each release.
> This originated from the mailing list:
> [https://lists.apache.org/thread.html/744ae19afa9b2fd1984c1e4dddc588e98786d9c21b633aab8bfa@%3Cdev.tinkerpop.apache.org%3E]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop issue #802: Add docker images for console and server TINKERPOP-189...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/802
  
I just reset my docker account password and it turns out that i'm one of 
the owners on the TinkerPop organization - so that's good.


---

[DISCUSS] 3.4.0 Fix Version

[Stephen Mallette]

We made the rule a release or two ago that we would set the Fix Version for
all version on which a JIRA applied. Now we've opened up 3.4.0. It occurred
to me that we might need to go back in time and change all closed JIRAs
from the unreleased 3.3.2 to include newly added 3.4.0. But then I was
like, "nah" - doesn't feel necessary. We can just apply from 3.3.3 forward.
Does that bug anyone?

If not I'll assume lazy consensus in 72 hours (Saturday, March 3, 2018, 4pm
EST) and just leave it alone.

[jira] [Commented] (TINKERPOP-1897) Provide Docker images of Gremlin Server and Console

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381036#comment-16381036
 ] 

ASF GitHub Bot commented on TINKERPOP-1897:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/802
  
Thanks for doing this @FlorianHockmann - i'm just dumping my brain of 
questions and thoughts on this one.

So `mvn deploy` will deploy to where? dockerhub?  If so, could you include 
something in the dev docs on how you configure your system to allow for that? 

i assume we would want it to deploy here: 
https://hub.docker.com/u/tinkerpop/ but i can't remember  who controls that...i 
think it's one of us..

Also, what happens when we do a `mvn deploy` on a SNAPSHOT? that would be 
bad right? I think we need to prevent such things from happening somehow.

what does adding this extra step do to the the overall build time (when 
building docker is enabled, of course)? I like that you made it a separate 
`` and used the `.docker` pattern we have with `.glv`. Part of this PR 
will likely need to include updates for the release process as well. 


> Provide Docker images of Gremlin Server and Console
> ---
>
> Key: TINKERPOP-1897
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1897
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: console, server
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
>
> TinkerPop should provide Docker images of Gremlin Server and Gremlin Console 
> that are deployed together with each release.
> This originated from the mailing list:
> [https://lists.apache.org/thread.html/744ae19afa9b2fd1984c1e4dddc588e98786d9c21b633aab8bfa@%3Cdev.tinkerpop.apache.org%3E]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop issue #802: Add docker images for console and server TINKERPOP-189...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/802
  
Thanks for doing this @FlorianHockmann - i'm just dumping my brain of 
questions and thoughts on this one.

So `mvn deploy` will deploy to where? dockerhub?  If so, could you include 
something in the dev docs on how you configure your system to allow for that? 

i assume we would want it to deploy here: 
https://hub.docker.com/u/tinkerpop/ but i can't remember  who controls that...i 
think it's one of us..

Also, what happens when we do a `mvn deploy` on a SNAPSHOT? that would be 
bad right? I think we need to prevent such things from happening somehow.

what does adding this extra step do to the the overall build time (when 
building docker is enabled, of course)? I like that you made it a separate 
`` and used the `.docker` pattern we have with `.glv`. Part of this PR 
will likely need to include updates for the release process as well. 


---

[jira] [Comment Edited] (TINKERPOP-1906) Make ResponseException explorable

[Ashwini Singh (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381019#comment-16381019
 ] 

Ashwini Singh edited comment on TINKERPOP-1906 at 2/28/18 8:47 PM:
---

In case of 429,  Gremlin Response from Azure Cosmos DB contains 
ResponseStatusCode.ServerError(500) and exception details as the message, which 
includes details of 429 exceptions. At the Gremlin.Net driver side, you see the 
 ResponseException because of the error code  ResponseStatusCode.ServerError 
(500). Also, Cosmos DB adds more details in the ResponseStatus.Attributes. You 
can check that through tools like Fiddler.

 

I agree with Florian, the change mentioned below is to expose these details and 
client can handle the rate limiting.

[https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E]


was (Author: ashwini singh):
In case of 429,  Gremlin Response from Azure Cosmos DB contains 
ResponseStatusCode.ServerError(500) and exception details as the message, which 
includes details of 429 exceptions. At the Gremlin.Net driver side, you see the 
 ResponseException because of the error code  ResponseStatusCode.ServerError 
(500). Also, Cosmos DB adds more details in the ResponseStatus.Attributes. You 
can check that through tools like Fiddler.

 

I agree with Florian, the change mentioned 
[here|mailto:%20https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E]
 is to expose these details and client can handle the rate limiting.

> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Priority: Major
> Attachments: message.txt, stacktrace.txt
>
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to 
> react on the GremlinService's Response. The only content is the exception's 
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode 
> or anything else that's responded by the service.
>  
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a 
> "Request Rate to Large" response, in case you have high load on your 
> database. In such a case, you want to be able to detect this "error" and just 
> retry after a few milliseconds (i'm not sure, but i think even a proposal for 
> this retry-timeout is given in the response)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1897) Provide Docker images of Gremlin Server and Console

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381025#comment-16381025
 ] 

ASF GitHub Bot commented on TINKERPOP-1897:
---

Github user spmallette commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/802#discussion_r171379911
  
--- Diff: docs/src/reference/gremlin-applications.asciidoc ---
@@ -1830,6 +1862,63 @@ $ curl -X POST -d "{\"gremlin\":\"divideIt(8, 2)\"}" 
"http://localhost:8182;
 In the above REST-based requests, the bindings contain a special parameter 
that tells the `ScriptEngine` cache to
 immediately forget the script after execution. In this way, the function 
does not end up being globally available.
 
+[[gremlin-server-docker-image]]
+=== Docker Image
+The Gremlin Server can also be started as a 
link:https://hub.docker.com/r/tinkerpop/gremlin-server/[Docker image]:
+
+[source,text]
+
+$ docker run tinkerpop/gremlin-server:x.y.z
+[INFO] GremlinServer - 
+ \,,,/
+ (o o)
+-oOOo-(3)-oOOo-
+
+[INFO] GremlinServer - Configuring Gremlin Server from 
conf/gremlin-server.yaml
+[INFO] MetricManager - Configured Metrics ConsoleReporter configured with 
report interval=18ms
--- End diff --

I suggest you elide some of the log output hereless to maintain should 
the output ever change. maybe "..." everything starting here down to (but not 
including):

```text
[INFO] GremlinServer$1 - Gremlin Server configured with worker thread pool 
of 1, gremlin pool of 4 and boss thread pool of 1.
```


> Provide Docker images of Gremlin Server and Console
> ---
>
> Key: TINKERPOP-1897
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1897
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: console, server
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
>
> TinkerPop should provide Docker images of Gremlin Server and Gremlin Console 
> that are deployed together with each release.
> This originated from the mailing list:
> [https://lists.apache.org/thread.html/744ae19afa9b2fd1984c1e4dddc588e98786d9c21b633aab8bfa@%3Cdev.tinkerpop.apache.org%3E]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop pull request #802: Add docker images for console and server TINKER...

[spmallette]

Github user spmallette commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/802#discussion_r171379911
  
--- Diff: docs/src/reference/gremlin-applications.asciidoc ---
@@ -1830,6 +1862,63 @@ $ curl -X POST -d "{\"gremlin\":\"divideIt(8, 2)\"}" 
"http://localhost:8182;
 In the above REST-based requests, the bindings contain a special parameter 
that tells the `ScriptEngine` cache to
 immediately forget the script after execution. In this way, the function 
does not end up being globally available.
 
+[[gremlin-server-docker-image]]
+=== Docker Image
+The Gremlin Server can also be started as a 
link:https://hub.docker.com/r/tinkerpop/gremlin-server/[Docker image]:
+
+[source,text]
+
+$ docker run tinkerpop/gremlin-server:x.y.z
+[INFO] GremlinServer - 
+ \,,,/
+ (o o)
+-oOOo-(3)-oOOo-
+
+[INFO] GremlinServer - Configuring Gremlin Server from 
conf/gremlin-server.yaml
+[INFO] MetricManager - Configured Metrics ConsoleReporter configured with 
report interval=18ms
--- End diff --

I suggest you elide some of the log output hereless to maintain should 
the output ever change. maybe "..." everything starting here down to (but not 
including):

```text
[INFO] GremlinServer$1 - Gremlin Server configured with worker thread pool 
of 1, gremlin pool of 4 and boss thread pool of 1.
```


---

[jira] [Closed] (TINKERPOP-1586) SubgraphStrategy in OLAP

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette closed TINKERPOP-1586.
---
   Resolution: Fixed
Fix Version/s: 3.3.2
   3.2.8

> SubgraphStrategy in OLAP
> 
>
> Key: TINKERPOP-1586
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1586
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> If a vertex filter is provided in {{SubgraphStrategy}}, then it will turn any 
> edge step in the traversal into something like:
> {noformat}
> ...outE().filter(inV().vertexFilterCondittion())
> {noformat}
> This breaks any OLAP traversal (leaving the star graph) and is not even the 
> behavior that you would always want. We should have an option to disable the 
> adjacent vertex checks. In code this would just mean to replace this 
> {{else}}: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/decoration/SubgraphStrategy.java#L92
> ...with {{else if (checkAdjacentVertices)}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1586) SubgraphStrategy in OLAP

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381020#comment-16381020
 ] 

ASF GitHub Bot commented on TINKERPOP-1586:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/799


> SubgraphStrategy in OLAP
> 
>
> Key: TINKERPOP-1586
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1586
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: stephen mallette
>Priority: Major
>
> If a vertex filter is provided in {{SubgraphStrategy}}, then it will turn any 
> edge step in the traversal into something like:
> {noformat}
> ...outE().filter(inV().vertexFilterCondittion())
> {noformat}
> This breaks any OLAP traversal (leaving the star graph) and is not even the 
> behavior that you would always want. We should have an option to disable the 
> adjacent vertex checks. In code this would just mean to replace this 
> {{else}}: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/decoration/SubgraphStrategy.java#L92
> ...with {{else if (checkAdjacentVertices)}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable

[Ashwini Singh (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381019#comment-16381019
 ] 

Ashwini Singh commented on TINKERPOP-1906:
--

In case of 429,  Gremlin Response from Azure Cosmos DB contains 
ResponseStatusCode.ServerError(500) and exception details as the message, which 
includes details of 429 exceptions. At the Gremlin.Net driver side, you see the 
 ResponseException because of the error code  ResponseStatusCode.ServerError 
(500). Also, Cosmos DB adds more details in the ResponseStatus.Attributes. You 
can check that through tools like Fiddler.

 

I agree with Florian, the change mentioned 
[here|mailto:%20https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E]
 is to expose these details and client can handle the rate limiting.

> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Priority: Major
> Attachments: message.txt, stacktrace.txt
>
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to 
> react on the GremlinService's Response. The only content is the exception's 
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode 
> or anything else that's responded by the service.
>  
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a 
> "Request Rate to Large" response, in case you have high load on your 
> database. In such a case, you want to be able to detect this "error" and just 
> retry after a few milliseconds (i'm not sure, but i think even a proposal for 
> this retry-timeout is given in the response)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop pull request #799: TINKERPOP-1586 Added checkAdjacentVertices opti...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/799


---

[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable

[Florian Hockmann (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381018#comment-16381018
 ] 

Florian Hockmann commented on TINKERPOP-1906:
-

Yeah, seeing the exception message I can completely understand your confusion. 
The thing is that Gremlin.Net just builds the exception message as 
{{$"\{status.Code}: \{status.Message}"}} where {{status.Code}} isn't an {{int}} 
but a {{ResponseStatusCode enum}}. From your {{message.txt}}, the 
{{status.code}} is {{ServerError}} and everything behind that (starting with 
the {{ActivityId}}) is the {{status.Message}} returned by Cosmos DB.

This means for Gremlin.Net that all we're seeing here is the {{ServerError}} 
(which corresponds to the status code 500) and the rest is just a {{string}}. 
So all we could do with that information is to add dedicated exception class 
like {{GremlinServerErrorException}} in cases where the server returns a 
{{ServerError}} (500), but I don't know how useful that is as the 
{{ServerError}} could be basically anything.

> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Priority: Major
> Attachments: message.txt, stacktrace.txt
>
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to 
> react on the GremlinService's Response. The only content is the exception's 
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode 
> or anything else that's responded by the service.
>  
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a 
> "Request Rate to Large" response, in case you have high load on your 
> database. In such a case, you want to be able to detect this "error" and just 
> retry after a few milliseconds (i'm not sure, but i think even a proposal for 
> this retry-timeout is given in the response)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Documentation generation with Docker

[Stephen Mallette]

I pushed the fix for master, so I don't have the console problem anymore.
So now, it's just the issue I guess I've always had.

On Wed, Feb 28, 2018 at 12:18 PM, Robert Dale  wrote:

> That works for me.
>
> Robert Dale
>
> On Wed, Feb 28, 2018 at 11:23 AM, Florian Hockmann  >
> wrote:
>
> > I also ran into the exact same problem in my feature branch for the
> > docker images which is why haven't added my own vote for the PR yet. But
> > it's good to see that it's really completely unrelated to my changes.
> >
> >
> > Am 28.02.2018 um 17:15 schrieb Stephen Mallette:
> > > I'm still a bust - same kind of error I keep having -
> > >
> > >  * source:   /usr/src/tinkerpop/docs/src/recipes/olap-spark-yarn.
> > asciidoc
> > >target:
> > >  /usr/src/tinkerpop/target/postprocess-asciidoc/recipes/
> > olap-spark-yarn.asciidoc
> > >progress:
> > > [=>
> > >   ] 65%java.io.IOException: No input paths
> > > specified in job
> > > Type ':help' or ':h' for help.
> > > Display stack trace? [yN]pb(94); ''
> > >
> > >
> > > Last 10 lines of
> > > /usr/src/tinkerpop/target/postprocess-asciidoc/recipes/
> > olap-spark-yarn.asciidoc:
> > >
> > > gremlin> conf.setProperty('spark.executor.extraLibraryPath',
> > > "$hadoop/lib/native:$hadoop/lib/native/Linux-amd64-64")
> > > ==>null
> > > gremlin> conf.setProperty('gremlin.spark.persistContext', 'true')
> > > ==>null
> > > gremlin> graph = GraphFactory.open(conf)
> > > ==>hadoopgraph[gryoinputformat->gryooutputformat]
> > > gremlin> g = graph.traversal().withComputer(SparkGraphComputer)
> > > ==>graphtraversalsource[hadoopgraph[gryoinputformat->
> gryooutputformat],
> > > sparkgraphcomputer]
> > > gremlin> g.V().group().by(values('name')).by(both().count())
> > > gremlin>
> > >
> > > xargs: /usr/src/tinkerpop/docs/preprocessor/preprocess-file.sh: exited
> > with
> > > status 255; aborting
> > >
> > >
> > >
> > >
> > > On Wed, Feb 28, 2018 at 10:46 AM, Robert Dale 
> wrote:
> > >
> > >> Yup, it's a step in the release docs.  Once updated, master builds
> docs
> > for
> > >> me.
> > >>
> > >> Robert Dale
> > >>
> > >> On Wed, Feb 28, 2018 at 10:42 AM, Stephen Mallette <
> > spmalle...@gmail.com>
> > >> wrote:
> > >>
> > >>> ah - i forgot to do that step.i'm running tp32 now to see if that
> > >>> works, but i'll fix that issue on master.
> > >>>
> > >>> On Wed, Feb 28, 2018 at 10:41 AM, Robert Dale 
> > wrote:
> > >>>
> >  Could it be that 'bin/gremlin.sh' is linked to a specific version?
> > Does
> >  this have to be updated every release?
> > 
> >  $ ll gremlin-console/bin/gremlin.sh
> >  gremlin-console/bin/gremlin.sh ->
> >  ../target/apache-tinkerpop-gremlin-console-3.3.2-
> > >>> SNAPSHOT-standalone/bin/
> >  gremlin.sh
> > 
> >  Robert Dale
> > 
> >  On Wed, Feb 28, 2018 at 10:37 AM, Robert Dale 
> > >> wrote:
> > > I got it too. tp32: good.  tp33: good. master: bad.
> > >
> > > Robert Dale
> > >
> > > On Wed, Feb 28, 2018 at 10:20 AM, Stephen Mallette <
> > >>> spmalle...@gmail.com
> > > wrote:
> > >
> > >> I'm having no success generating docs with Docker. On master i'm
> >  currently
> > >> getting:
> > >>
> > >> Starting namenodes on [localhost]
> > >> localhost: Warning: Permanently added 'localhost' (ECDSA) to the
> > >> list
> > >>> of
> > >> known hosts.
> > >> localhost: starting namenode, logging to
> > >> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-namenode-
> > >>> 61cfd8f63c77.out
> > >> localhost: Warning: Permanently added 'localhost' (ECDSA) to the
> > >> list
> > >>> of
> > >> known hosts.
> > >> localhost: starting datanode, logging to
> > >> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-datanode-
> > >>> 61cfd8f63c77.out
> > >> Starting secondary namenodes [0.0.0.0]
> > >> 0.0.0.0: Warning: Permanently added '0.0.0.0' (ECDSA) to the list
> > >> of
> > >> known
> > >> hosts.
> > >> 0.0.0.0: starting secondarynamenode, logging to
> > >> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-secondarynameno
> > >> de-61cfd8f63c77.out
> > >> starting yarn daemons
> > >> starting resourcemanager, logging to
> > >> /usr/local/lib/hadoop-2.7.2/logs/yarn-root-resourcemanager-
> > >> 61cfd8f63c77.out
> > >> localhost: Warning: Permanently added 'localhost' (ECDSA) to the
> > >> list
> > >>> of
> > >> known hosts.
> > >> localhost: starting nodemanager, logging to
> > >> /usr/local/lib/hadoop-2.7.2/logs/yarn-root-nodemanager-
> > >>> 61cfd8f63c77.out
> > >> Gremlin REPL is not available. Cannot preprocess AsciiDoc files.
> > >> Untagged: tinkerpop:build-1519830232
> > >>
> > >> On that particular run, I'd just deleted all my Docker images
> > >>> (including
> > >> 

[jira] [Comment Edited] (TINKERPOP-1906) Make ResponseException explorable

[Roman Kreisel (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380930#comment-16380930
 ] 

Roman Kreisel edited comment on TINKERPOP-1906 at 2/28/18 7:40 PM:
---

Hi Florian,

please find the exception's [^message.txt] and [^stacktrace.txt] attached to 
this comment.

I just checked the sourcecode of 
[https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Driver/Messages/ResponseStatusCode.cs]
 and have to admit I don't quite understand why this exception has been thrown, 
but my debugger clearly tells me, it's a 
Gremlin.Net.Driver.Exceptions.ResponseException. And even in the exception's 
Text, you can read "BackendStatusCode : 429"

 

I'm using the 3.3.2-rc1 of Gremlin.NET from NuGet


was (Author: romankreisel):
Hi Florian,

please find the exception's [^message.txt] and [^stacktrace.txt] attached to 
this comment.

I just checked the sourcecode of 
[https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Driver/Messages/ResponseStatusCode.cs]
 and have to admit, i don't quite understand why this exception has been 
thrown, but my debugger clearly tells me, it's a 
Gremlin.Net.Driver.Exceptions.ResponseException. And even in the exception's 
Text, you can read "BackendStatusCode : 429"

 

I'm using the 3.3.2-rc1 of Gremlin.NET from NuGet

> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Priority: Major
> Attachments: message.txt, stacktrace.txt
>
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to 
> react on the GremlinService's Response. The only content is the exception's 
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode 
> or anything else that's responded by the service.
>  
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a 
> "Request Rate to Large" response, in case you have high load on your 
> database. In such a case, you want to be able to detect this "error" and just 
> retry after a few milliseconds (i'm not sure, but i think even a proposal for 
> this retry-timeout is given in the response)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable

[Roman Kreisel (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380930#comment-16380930
 ] 

Roman Kreisel commented on TINKERPOP-1906:
--

Hi Florian,

please find the exception's [^message.txt] and [^stacktrace.txt] attached to 
this comment.

I just checked the sourcecode of 
[https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Driver/Messages/ResponseStatusCode.cs]
 and have to admit, i don't quite understand why this exception has been 
thrown, but my debugger clearly tells me, it's a 
Gremlin.Net.Driver.Exceptions.ResponseException. And even in the exception's 
Text, you can read "BackendStatusCode : 429"

 

I'm using the 3.3.2-rc1 of Gremlin.NET from NuGet

> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Priority: Major
> Attachments: message.txt, stacktrace.txt
>
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to 
> react on the GremlinService's Response. The only content is the exception's 
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode 
> or anything else that's responded by the service.
>  
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a 
> "Request Rate to Large" response, in case you have high load on your 
> database. In such a case, you want to be able to detect this "error" and just 
> retry after a few milliseconds (i'm not sure, but i think even a proposal for 
> this retry-timeout is given in the response)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TINKERPOP-1906) Make ResponseException explorable

[Roman Kreisel (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Kreisel updated TINKERPOP-1906:
-
Attachment: message.txt
stacktrace.txt

> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Priority: Major
> Attachments: message.txt, stacktrace.txt
>
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to 
> react on the GremlinService's Response. The only content is the exception's 
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode 
> or anything else that's responded by the service.
>  
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a 
> "Request Rate to Large" response, in case you have high load on your 
> database. In such a case, you want to be able to detect this "error" and just 
> retry after a few milliseconds (i'm not sure, but i think even a proposal for 
> this retry-timeout is given in the response)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Gremlin's Anatomy Tutorial

[Stephen Mallette]

I wrote up a tutorial version of my presentation of Gremlin's Anatomy from
last week:

https://github.com/apache/tinkerpop/commit/3aa9e70ef7e50d81886954e398b4355524f7b576

I basically wanted to just introduce the component parts of Gremlin for
purposes of this tutorial. I left off the second part of my talk on
"debugging" as it didn't easily translate to tutorial/asciidoc form (the
way i presented it anyway - perhaps "Gremlin Debugging Tutorial" is a
separate body of work at some point).

Anyway, please let me know if you have any thoughts on what I wrote there,
otherwise i'm going to leave it at that.

[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable

[Florian Hockmann (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380840#comment-16380840
 ] 

Florian Hockmann commented on TINKERPOP-1906:
-

Hi Roman,

I was just hoping that you had a stack trace (or were able to produce one) as 
that should contain the actual status code in its message. A status code of 429 
would be problematic as that's not a status code we're expecting from a Gremlin 
Server, but then you shouldn't get a {{ResponseException}} in the first place. 
So it has to be another status code since you mentioned in the issue 
description that the exception you are seeing is actually a 
{{ResponseException}}.

> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Priority: Major
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to 
> react on the GremlinService's Response. The only content is the exception's 
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode 
> or anything else that's responded by the service.
>  
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a 
> "Request Rate to Large" response, in case you have high load on your 
> database. In such a case, you want to be able to detect this "error" and just 
> retry after a few milliseconds (i'm not sure, but i think even a proposal for 
> this retry-timeout is given in the response)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable

[Roman Kreisel (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380820#comment-16380820
 ] 

Roman Kreisel commented on TINKERPOP-1906:
--

Hi Florian,

i'm not a cosmos db architect, nor have I analyzed the http traffic. But 
regarding to the documentation from microsoft (*1), i'd expect a 429 (Too Many 
Requests)

*1 
https://docs.microsoft.com/en-us/rest/api/documentdb/http-status-codes-for-documentdb

> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Priority: Major
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to 
> react on the GremlinService's Response. The only content is the exception's 
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode 
> or anything else that's responded by the service.
>  
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a 
> "Request Rate to Large" response, in case you have high load on your 
> database. In such a case, you want to be able to detect this "error" and just 
> retry after a few milliseconds (i'm not sure, but i think even a proposal for 
> this retry-timeout is given in the response)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable

[Florian Hockmann (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380806#comment-16380806
 ] 

Florian Hockmann commented on TINKERPOP-1906:
-

Adding the status code as its own property is definitely a good idea. We could 
also introduce dedicated Exception classes for some status codes where a 
different error handling makes sense. The {{ServerTimeout}} status might be for 
example a good candidate as that's also something where a retry can make sense. 
When we keep the {{ResponseException}} as the base class for new exception 
classes, then this wouldn't be a breaking change.

[~RomanKreisel]: Could you check which status code you get returned in that 
case? It should be the beginning of the {{Message}} of the thrown 
{{ResponseException}}.

If you want to look at the implementation of where the exception gets thrown:
 * This is where the exception is thrown: 
[https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Driver/Messages/ResponseStatus.cs#L47]
 * And this method shows the status codes that are treated as errors: 
[https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Driver/Messages/ResponseStatusCode.cs#L45]

The status codes themselves are explained here, as they aren't directly the 
HTTP status codes: 
[http://tinkerpop.apache.org/docs/3.3.1/dev/provider/#_graph_driver_provider_requirements]

 

Regarding the discussion on the mailing list about adding meta data: It might 
be possible that that's also what they had in mind with the meta data, but I 
think that we can already improve error handling in the driver just based on 
the status codes that we already have.

> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Priority: Major
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to 
> react on the GremlinService's Response. The only content is the exception's 
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode 
> or anything else that's responded by the service.
>  
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a 
> "Request Rate to Large" response, in case you have high load on your 
> database. In such a case, you want to be able to detect this "error" and just 
> retry after a few milliseconds (i'm not sure, but i think even a proposal for 
> this retry-timeout is given in the response)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable

[Roman Kreisel (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380798#comment-16380798
 ] 

Roman Kreisel commented on TINKERPOP-1906:
--

Hi Stephen,

thank you for your quick response - I wasn't aware there is already a 
discussion running.

Anyway - the discussion even mentions ResponseStatus.Attributes - i think the 
absolute minimum would be to add the ResponseStatus to the ResponseException. 
Even right now, this would already help, since it would at least give the 
developers access to the HTTP Status. (Unless the "techical stuff" like HTTP 
code should be hidden/encapsulated)

> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Priority: Major
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to 
> react on the GremlinService's Response. The only content is the exception's 
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode 
> or anything else that's responded by the service.
>  
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a 
> "Request Rate to Large" response, in case you have high load on your 
> database. In such a case, you want to be able to detect this "error" and just 
> retry after a few milliseconds (i'm not sure, but i think even a proposal for 
> this retry-timeout is given in the response)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable

[stephen mallette (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380760#comment-16380760
 ] 

stephen mallette commented on TINKERPOP-1906:
-

I think this might relate to some of the discussion we're currently having on 
the dev list about this right now:

https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E

> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Priority: Major
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to 
> react on the GremlinService's Response. The only content is the exception's 
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode 
> or anything else that's responded by the service.
>  
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a 
> "Request Rate to Large" response, in case you have high load on your 
> database. In such a case, you want to be able to detect this "error" and just 
> retry after a few milliseconds (i'm not sure, but i think even a proposal for 
> this retry-timeout is given in the response)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TINKERPOP-1906) Make ResponseException explorable

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette updated TINKERPOP-1906:

Affects Version/s: 3.2.7

> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Priority: Major
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to 
> react on the GremlinService's Response. The only content is the exception's 
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode 
> or anything else that's responded by the service.
>  
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a 
> "Request Rate to Large" response, in case you have high load on your 
> database. In such a case, you want to be able to detect this "error" and just 
> retry after a few milliseconds (i'm not sure, but i think even a proposal for 
> this retry-timeout is given in the response)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [Discuss] Expose metadata from Gremlin Server to Clients.

[Stephen Mallette]

This newly created issue might be related to this in some way:

https://issues.apache.org/jira/browse/TINKERPOP-1906

On Wed, Feb 28, 2018 at 11:37 AM, Florian Hockmann 
wrote:

> I agree that we also should make this metadata available for traversals
> since we want to move users away from sending Gremlin scripts as strings
> and instead use Bytecode based GLVs.
>
> Regarding Gremlin.Net: I think that the implementation would be very
> similar to how it can be implemented in the Java driver as we tried to
> stay close to the Java driver in general. The only difference is
> probably that we currently don't have a ResultSet in Gremlin.Net, but
> that's only because I didn't see much value in adding that. Metadata
> would of course be a good argument to also implement a ResultSet in
> Gremlin.Net and then the implementation should be really basically the
> same as in the Java driver.
>
>
> Am 28.02.2018 um 16:15 schrieb Stephen Mallette:
> > I'm fine with using the last response message as the carrier for this
> > metadata on a particular request. I can't really tell if there is much
> work
> > to do on Gremlin Server itself here. It seems like most of the work must
> > occur on the various drivers (you mention the .NET api, but all of the
> > drivers would need to support this feature). However, I would think that
> we
> > would want Gremlin Server itself to append in some kind metadata (maybe
> > query time? something easy) so that we could write tests for the
> > drivers in TinkerPop itself. There is also the question of how we would
> > expose this metadata to GLVs which don't see response messages at all. A
> > traversal might need some metadata itself so that the user could retrieve
> > the server metadata from that. The implementation between Java and the
> GLVs
> > might be different here as the GLV traversal class is typically quite
> > lightweight and only used for generating bytecode.
> >
> > I'm not so sure I like the  SubmitAsynWithHeaders()  but I don't think
> too
> > much about how the .NET driver works. Is there a reason to not always
> > return metadata? could it be expensive to do so? If we just added an
> extra
> > method how would remote traversals configure this option? I think we need
> > another way. Generally speaking, for Java, I think I would like to see
> the
> > metadata available to the ResultSet somehow which would in turn make it
> > pretty easy to get it on to a Traversal instance once that facility was
> > made available.but as to how to enable or disable the return of the
> > metadata, i'm not sure how that should work just yet - i need to think on
> > that some more.
> >
> > For committers who work on GLVs, please take a look at this thread and
> > offer your thoughts on how this might work in the GLV driver you tend to
> > have the most knowledge on. Let's see if we can come to one nice unified
> > solution. At that point, we can setup a ticket in JIRA and go from there.
> >
> > Ashwini, thanks for offering a pull request for this by the way. Once we
> > get consensus on how to do this, we'll see if tasks need to be divided
> and
> > how you might contribute.
> >
> >
> >
> > On Mon, Feb 26, 2018 at 6:45 PM, Ashwini Singh <
> > ashws...@microsoft.com.invalid> wrote:
> >
> >> Hi Stephen,
> >>
> >> Thanks for considering the change.
> >>
> >> We would be more inclined towards the first approach since the having a
> >> ping/pong websocket message can be a bit noisy and requires
> sophisticated
> >> handling on the client driver side.
> >>
> >> For handling multiple response messages. I would suggest to rely on last
> >> message as these are the metadata for request execution. Partial
> response
> >> is very internal to the client drivers (based on limited understanding
> of
> >> tinkerpop client drivers :) , correct me if you differ) and can be
> exposed
> >> separately (if really needed later).
> >>
> >> For implementation, Let us know if we can chip in there and submit PR.
> The
> >> high level approach to achieve this is to have corresponding
> >> SubmitAsynWithHeaders()  for every SubmitAsync() that returns a
> >> encapsulated result with attributes and IReadOnlyCollectio. Let me
> know
> >> if you see any concerns adding a new API.
> >>
> >> Thanks a lot,
> >> Ashwini Singh
> >> Software Engineer @ Azure Cosmos DB
> >>
> >>
> >>
> >> -Original Message-
> >> From: Stephen Mallette 
> >> Sent: Friday, February 23, 2018 5:13 PM
> >> To: dev@tinkerpop.apache.org
> >> Subject: Re: [Discuss] Expose metadata from Gremlin Server to Clients.
> >>
> >> Adding those kinds of details was the reason we had the
> >> ResponseStatus.attributes Map. I can really only speak for the java
> driver
> >> as I only know that one really well (we might need other TinkerPop
> experts
> >> to chime in for python, .net and c#).  The java driver doesn't really
> >> present ways to get that information easily under usage that doesn't
> 

[jira] [Created] (TINKERPOP-1906) Make ResponseException explorable

[Roman Kreisel (JIRA)]

Roman Kreisel created TINKERPOP-1906:


 Summary: Make ResponseException explorable
 Key: TINKERPOP-1906
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
 Project: TinkerPop
  Issue Type: Improvement
  Components: dotnet
Reporter: Roman Kreisel


The ResponseException from Gremlin.NET doesn't give you any possibility to 
react on the GremlinService's Response. The only content is the exception's 
Message, which is just free text.

It would be great, to add some fields to expose at least the HTTP ErrorCode or 
anything else that's responded by the service.

 

Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a 
"Request Rate to Large" response, in case you have high load on your database. 
In such a case, you want to be able to detect this "error" and just retry after 
a few milliseconds (i'm not sure, but i think even a proposal for this 
retry-timeout is given in the response)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Documentation generation with Docker

[Robert Dale]

That works for me.

Robert Dale

On Wed, Feb 28, 2018 at 11:23 AM, Florian Hockmann 
wrote:

> I also ran into the exact same problem in my feature branch for the
> docker images which is why haven't added my own vote for the PR yet. But
> it's good to see that it's really completely unrelated to my changes.
>
>
> Am 28.02.2018 um 17:15 schrieb Stephen Mallette:
> > I'm still a bust - same kind of error I keep having -
> >
> >  * source:   /usr/src/tinkerpop/docs/src/recipes/olap-spark-yarn.
> asciidoc
> >target:
> >  /usr/src/tinkerpop/target/postprocess-asciidoc/recipes/
> olap-spark-yarn.asciidoc
> >progress:
> > [=>
> >   ] 65%java.io.IOException: No input paths
> > specified in job
> > Type ':help' or ':h' for help.
> > Display stack trace? [yN]pb(94); ''
> >
> >
> > Last 10 lines of
> > /usr/src/tinkerpop/target/postprocess-asciidoc/recipes/
> olap-spark-yarn.asciidoc:
> >
> > gremlin> conf.setProperty('spark.executor.extraLibraryPath',
> > "$hadoop/lib/native:$hadoop/lib/native/Linux-amd64-64")
> > ==>null
> > gremlin> conf.setProperty('gremlin.spark.persistContext', 'true')
> > ==>null
> > gremlin> graph = GraphFactory.open(conf)
> > ==>hadoopgraph[gryoinputformat->gryooutputformat]
> > gremlin> g = graph.traversal().withComputer(SparkGraphComputer)
> > ==>graphtraversalsource[hadoopgraph[gryoinputformat->gryooutputformat],
> > sparkgraphcomputer]
> > gremlin> g.V().group().by(values('name')).by(both().count())
> > gremlin>
> >
> > xargs: /usr/src/tinkerpop/docs/preprocessor/preprocess-file.sh: exited
> with
> > status 255; aborting
> >
> >
> >
> >
> > On Wed, Feb 28, 2018 at 10:46 AM, Robert Dale  wrote:
> >
> >> Yup, it's a step in the release docs.  Once updated, master builds docs
> for
> >> me.
> >>
> >> Robert Dale
> >>
> >> On Wed, Feb 28, 2018 at 10:42 AM, Stephen Mallette <
> spmalle...@gmail.com>
> >> wrote:
> >>
> >>> ah - i forgot to do that step.i'm running tp32 now to see if that
> >>> works, but i'll fix that issue on master.
> >>>
> >>> On Wed, Feb 28, 2018 at 10:41 AM, Robert Dale 
> wrote:
> >>>
>  Could it be that 'bin/gremlin.sh' is linked to a specific version?
> Does
>  this have to be updated every release?
> 
>  $ ll gremlin-console/bin/gremlin.sh
>  gremlin-console/bin/gremlin.sh ->
>  ../target/apache-tinkerpop-gremlin-console-3.3.2-
> >>> SNAPSHOT-standalone/bin/
>  gremlin.sh
> 
>  Robert Dale
> 
>  On Wed, Feb 28, 2018 at 10:37 AM, Robert Dale 
> >> wrote:
> > I got it too. tp32: good.  tp33: good. master: bad.
> >
> > Robert Dale
> >
> > On Wed, Feb 28, 2018 at 10:20 AM, Stephen Mallette <
> >>> spmalle...@gmail.com
> > wrote:
> >
> >> I'm having no success generating docs with Docker. On master i'm
>  currently
> >> getting:
> >>
> >> Starting namenodes on [localhost]
> >> localhost: Warning: Permanently added 'localhost' (ECDSA) to the
> >> list
> >>> of
> >> known hosts.
> >> localhost: starting namenode, logging to
> >> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-namenode-
> >>> 61cfd8f63c77.out
> >> localhost: Warning: Permanently added 'localhost' (ECDSA) to the
> >> list
> >>> of
> >> known hosts.
> >> localhost: starting datanode, logging to
> >> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-datanode-
> >>> 61cfd8f63c77.out
> >> Starting secondary namenodes [0.0.0.0]
> >> 0.0.0.0: Warning: Permanently added '0.0.0.0' (ECDSA) to the list
> >> of
> >> known
> >> hosts.
> >> 0.0.0.0: starting secondarynamenode, logging to
> >> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-secondarynameno
> >> de-61cfd8f63c77.out
> >> starting yarn daemons
> >> starting resourcemanager, logging to
> >> /usr/local/lib/hadoop-2.7.2/logs/yarn-root-resourcemanager-
> >> 61cfd8f63c77.out
> >> localhost: Warning: Permanently added 'localhost' (ECDSA) to the
> >> list
> >>> of
> >> known hosts.
> >> localhost: starting nodemanager, logging to
> >> /usr/local/lib/hadoop-2.7.2/logs/yarn-root-nodemanager-
> >>> 61cfd8f63c77.out
> >> Gremlin REPL is not available. Cannot preprocess AsciiDoc files.
> >> Untagged: tinkerpop:build-1519830232
> >>
> >> On that particular run, I'd just deleted all my Docker images
> >>> (including
> >> the linux image) and it still failed. Any clues as to what might be
>  wrong?
> >> am i the only person with a problem here?
> >>
> >
>
>

[jira] [Commented] (TINKERPOP-1862) TinkerGraph VertexProgram message passing doesn't work properly when using Direction.BOTH

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380678#comment-16380678
 ] 

ASF GitHub Bot commented on TINKERPOP-1862:
---

Github user PBGraff commented on the issue:

https://github.com/apache/tinkerpop/pull/801
  
OK, I've made that update and now this build passes.


> TinkerGraph VertexProgram message passing doesn't work properly when using 
> Direction.BOTH
> -
>
> Key: TINKERPOP-1862
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1862
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process, tinkergraph
>Affects Versions: 3.2.7
>Reporter: Philip Graff
>Priority: Major
>
> I think the messages are being sent properly in TinkerMessenger, but when I 
> call messenger.receiveMessages(), the vertex is getting messages from the 
> outVertex of their edges regardless of the edge direction. This is due to 
> line 71 of TinkerMessenger (linked below) which calls 
> Edge.vertices(direction).next(), thus getting the first result out of the 
> Vertex iterator. For IN or OUT, this isn't a problem. But for BOTH, following 
> line 124 of TinkerEdge (linked below), the outVertex is always returned 
> first. TinkerMessenger needs to be modified to return the correct vertex (I 
> think it's the one that != this.vertex).
> https://github.com/apache/tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/process/computer/TinkerMessenger.java#L71
> https://github.com/apache/tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerEdge.java#L124



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop issue #801: TINKERPOP-1862 TinkerMessenger proper handling of Dire...

[PBGraff]

Github user PBGraff commented on the issue:

https://github.com/apache/tinkerpop/pull/801
  
OK, I've made that update and now this build passes.


---

Re: [Discuss] Expose metadata from Gremlin Server to Clients.

[Florian Hockmann]

I agree that we also should make this metadata available for traversals
since we want to move users away from sending Gremlin scripts as strings
and instead use Bytecode based GLVs.

Regarding Gremlin.Net: I think that the implementation would be very
similar to how it can be implemented in the Java driver as we tried to
stay close to the Java driver in general. The only difference is
probably that we currently don't have a ResultSet in Gremlin.Net, but
that's only because I didn't see much value in adding that. Metadata
would of course be a good argument to also implement a ResultSet in
Gremlin.Net and then the implementation should be really basically the
same as in the Java driver.


Am 28.02.2018 um 16:15 schrieb Stephen Mallette:
> I'm fine with using the last response message as the carrier for this
> metadata on a particular request. I can't really tell if there is much work
> to do on Gremlin Server itself here. It seems like most of the work must
> occur on the various drivers (you mention the .NET api, but all of the
> drivers would need to support this feature). However, I would think that we
> would want Gremlin Server itself to append in some kind metadata (maybe
> query time? something easy) so that we could write tests for the
> drivers in TinkerPop itself. There is also the question of how we would
> expose this metadata to GLVs which don't see response messages at all. A
> traversal might need some metadata itself so that the user could retrieve
> the server metadata from that. The implementation between Java and the GLVs
> might be different here as the GLV traversal class is typically quite
> lightweight and only used for generating bytecode.
>
> I'm not so sure I like the  SubmitAsynWithHeaders()  but I don't think too
> much about how the .NET driver works. Is there a reason to not always
> return metadata? could it be expensive to do so? If we just added an extra
> method how would remote traversals configure this option? I think we need
> another way. Generally speaking, for Java, I think I would like to see the
> metadata available to the ResultSet somehow which would in turn make it
> pretty easy to get it on to a Traversal instance once that facility was
> made available.but as to how to enable or disable the return of the
> metadata, i'm not sure how that should work just yet - i need to think on
> that some more.
>
> For committers who work on GLVs, please take a look at this thread and
> offer your thoughts on how this might work in the GLV driver you tend to
> have the most knowledge on. Let's see if we can come to one nice unified
> solution. At that point, we can setup a ticket in JIRA and go from there.
>
> Ashwini, thanks for offering a pull request for this by the way. Once we
> get consensus on how to do this, we'll see if tasks need to be divided and
> how you might contribute.
>
>
>
> On Mon, Feb 26, 2018 at 6:45 PM, Ashwini Singh <
> ashws...@microsoft.com.invalid> wrote:
>
>> Hi Stephen,
>>
>> Thanks for considering the change.
>>
>> We would be more inclined towards the first approach since the having a
>> ping/pong websocket message can be a bit noisy and requires sophisticated
>> handling on the client driver side.
>>
>> For handling multiple response messages. I would suggest to rely on last
>> message as these are the metadata for request execution. Partial response
>> is very internal to the client drivers (based on limited understanding of
>> tinkerpop client drivers :) , correct me if you differ) and can be exposed
>> separately (if really needed later).
>>
>> For implementation, Let us know if we can chip in there and submit PR. The
>> high level approach to achieve this is to have corresponding
>> SubmitAsynWithHeaders()  for every SubmitAsync() that returns a
>> encapsulated result with attributes and IReadOnlyCollectio. Let me know
>> if you see any concerns adding a new API.
>>
>> Thanks a lot,
>> Ashwini Singh
>> Software Engineer @ Azure Cosmos DB
>>
>>
>>
>> -Original Message-
>> From: Stephen Mallette 
>> Sent: Friday, February 23, 2018 5:13 PM
>> To: dev@tinkerpop.apache.org
>> Subject: Re: [Discuss] Expose metadata from Gremlin Server to Clients.
>>
>> Adding those kinds of details was the reason we had the
>> ResponseStatus.attributes Map. I can really only speak for the java driver
>> as I only know that one really well (we might need other TinkerPop experts
>> to chime in for python, .net and c#).  The java driver doesn't really
>> present ways to get that information easily under usage that doesn't deal
>> directly with RequestMessage directly (which people typically don't do).
>> Another thing to think about is that since a single request might return
>> multiple ResponseMessage instances you might not want to return that kind
>> of data on every response - maybe just to be returned on the first (or 
>> last
>> message) and then we somehow preserve that information and make it
>> accessible on the result 

Re: Documentation generation with Docker

[Florian Hockmann]

I also ran into the exact same problem in my feature branch for the
docker images which is why haven't added my own vote for the PR yet. But
it's good to see that it's really completely unrelated to my changes.


Am 28.02.2018 um 17:15 schrieb Stephen Mallette:
> I'm still a bust - same kind of error I keep having -
>
>  * source:   /usr/src/tinkerpop/docs/src/recipes/olap-spark-yarn.asciidoc
>target:
>  
> /usr/src/tinkerpop/target/postprocess-asciidoc/recipes/olap-spark-yarn.asciidoc
>progress:
> [=>
>   ] 65%java.io.IOException: No input paths
> specified in job
> Type ':help' or ':h' for help.
> Display stack trace? [yN]pb(94); ''
>
>
> Last 10 lines of
> /usr/src/tinkerpop/target/postprocess-asciidoc/recipes/olap-spark-yarn.asciidoc:
>
> gremlin> conf.setProperty('spark.executor.extraLibraryPath',
> "$hadoop/lib/native:$hadoop/lib/native/Linux-amd64-64")
> ==>null
> gremlin> conf.setProperty('gremlin.spark.persistContext', 'true')
> ==>null
> gremlin> graph = GraphFactory.open(conf)
> ==>hadoopgraph[gryoinputformat->gryooutputformat]
> gremlin> g = graph.traversal().withComputer(SparkGraphComputer)
> ==>graphtraversalsource[hadoopgraph[gryoinputformat->gryooutputformat],
> sparkgraphcomputer]
> gremlin> g.V().group().by(values('name')).by(both().count())
> gremlin>
>
> xargs: /usr/src/tinkerpop/docs/preprocessor/preprocess-file.sh: exited with
> status 255; aborting
>
>
>
>
> On Wed, Feb 28, 2018 at 10:46 AM, Robert Dale  wrote:
>
>> Yup, it's a step in the release docs.  Once updated, master builds docs for
>> me.
>>
>> Robert Dale
>>
>> On Wed, Feb 28, 2018 at 10:42 AM, Stephen Mallette 
>> wrote:
>>
>>> ah - i forgot to do that step.i'm running tp32 now to see if that
>>> works, but i'll fix that issue on master.
>>>
>>> On Wed, Feb 28, 2018 at 10:41 AM, Robert Dale  wrote:
>>>
 Could it be that 'bin/gremlin.sh' is linked to a specific version? Does
 this have to be updated every release?

 $ ll gremlin-console/bin/gremlin.sh
 gremlin-console/bin/gremlin.sh ->
 ../target/apache-tinkerpop-gremlin-console-3.3.2-
>>> SNAPSHOT-standalone/bin/
 gremlin.sh

 Robert Dale

 On Wed, Feb 28, 2018 at 10:37 AM, Robert Dale 
>> wrote:
> I got it too. tp32: good.  tp33: good. master: bad.
>
> Robert Dale
>
> On Wed, Feb 28, 2018 at 10:20 AM, Stephen Mallette <
>>> spmalle...@gmail.com
> wrote:
>
>> I'm having no success generating docs with Docker. On master i'm
 currently
>> getting:
>>
>> Starting namenodes on [localhost]
>> localhost: Warning: Permanently added 'localhost' (ECDSA) to the
>> list
>>> of
>> known hosts.
>> localhost: starting namenode, logging to
>> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-namenode-
>>> 61cfd8f63c77.out
>> localhost: Warning: Permanently added 'localhost' (ECDSA) to the
>> list
>>> of
>> known hosts.
>> localhost: starting datanode, logging to
>> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-datanode-
>>> 61cfd8f63c77.out
>> Starting secondary namenodes [0.0.0.0]
>> 0.0.0.0: Warning: Permanently added '0.0.0.0' (ECDSA) to the list
>> of
>> known
>> hosts.
>> 0.0.0.0: starting secondarynamenode, logging to
>> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-secondarynameno
>> de-61cfd8f63c77.out
>> starting yarn daemons
>> starting resourcemanager, logging to
>> /usr/local/lib/hadoop-2.7.2/logs/yarn-root-resourcemanager-
>> 61cfd8f63c77.out
>> localhost: Warning: Permanently added 'localhost' (ECDSA) to the
>> list
>>> of
>> known hosts.
>> localhost: starting nodemanager, logging to
>> /usr/local/lib/hadoop-2.7.2/logs/yarn-root-nodemanager-
>>> 61cfd8f63c77.out
>> Gremlin REPL is not available. Cannot preprocess AsciiDoc files.
>> Untagged: tinkerpop:build-1519830232
>>
>> On that particular run, I'd just deleted all my Docker images
>>> (including
>> the linux image) and it still failed. Any clues as to what might be
 wrong?
>> am i the only person with a problem here?
>>
>

Re: Documentation generation with Docker

[Stephen Mallette]

I'm still a bust - same kind of error I keep having -

 * source:   /usr/src/tinkerpop/docs/src/recipes/olap-spark-yarn.asciidoc
   target:
 /usr/src/tinkerpop/target/postprocess-asciidoc/recipes/olap-spark-yarn.asciidoc
   progress:
[=>
  ] 65%java.io.IOException: No input paths
specified in job
Type ':help' or ':h' for help.
Display stack trace? [yN]pb(94); ''


Last 10 lines of
/usr/src/tinkerpop/target/postprocess-asciidoc/recipes/olap-spark-yarn.asciidoc:

gremlin> conf.setProperty('spark.executor.extraLibraryPath',
"$hadoop/lib/native:$hadoop/lib/native/Linux-amd64-64")
==>null
gremlin> conf.setProperty('gremlin.spark.persistContext', 'true')
==>null
gremlin> graph = GraphFactory.open(conf)
==>hadoopgraph[gryoinputformat->gryooutputformat]
gremlin> g = graph.traversal().withComputer(SparkGraphComputer)
==>graphtraversalsource[hadoopgraph[gryoinputformat->gryooutputformat],
sparkgraphcomputer]
gremlin> g.V().group().by(values('name')).by(both().count())
gremlin>

xargs: /usr/src/tinkerpop/docs/preprocessor/preprocess-file.sh: exited with
status 255; aborting




On Wed, Feb 28, 2018 at 10:46 AM, Robert Dale  wrote:

> Yup, it's a step in the release docs.  Once updated, master builds docs for
> me.
>
> Robert Dale
>
> On Wed, Feb 28, 2018 at 10:42 AM, Stephen Mallette 
> wrote:
>
> > ah - i forgot to do that step.i'm running tp32 now to see if that
> > works, but i'll fix that issue on master.
> >
> > On Wed, Feb 28, 2018 at 10:41 AM, Robert Dale  wrote:
> >
> > > Could it be that 'bin/gremlin.sh' is linked to a specific version? Does
> > > this have to be updated every release?
> > >
> > > $ ll gremlin-console/bin/gremlin.sh
> > > gremlin-console/bin/gremlin.sh ->
> > > ../target/apache-tinkerpop-gremlin-console-3.3.2-
> > SNAPSHOT-standalone/bin/
> > > gremlin.sh
> > >
> > > Robert Dale
> > >
> > > On Wed, Feb 28, 2018 at 10:37 AM, Robert Dale 
> wrote:
> > >
> > > > I got it too. tp32: good.  tp33: good. master: bad.
> > > >
> > > > Robert Dale
> > > >
> > > > On Wed, Feb 28, 2018 at 10:20 AM, Stephen Mallette <
> > spmalle...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > >> I'm having no success generating docs with Docker. On master i'm
> > > currently
> > > >> getting:
> > > >>
> > > >> Starting namenodes on [localhost]
> > > >> localhost: Warning: Permanently added 'localhost' (ECDSA) to the
> list
> > of
> > > >> known hosts.
> > > >> localhost: starting namenode, logging to
> > > >> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-namenode-
> > 61cfd8f63c77.out
> > > >> localhost: Warning: Permanently added 'localhost' (ECDSA) to the
> list
> > of
> > > >> known hosts.
> > > >> localhost: starting datanode, logging to
> > > >> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-datanode-
> > 61cfd8f63c77.out
> > > >> Starting secondary namenodes [0.0.0.0]
> > > >> 0.0.0.0: Warning: Permanently added '0.0.0.0' (ECDSA) to the list
> of
> > > >> known
> > > >> hosts.
> > > >> 0.0.0.0: starting secondarynamenode, logging to
> > > >> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-secondarynameno
> > > >> de-61cfd8f63c77.out
> > > >> starting yarn daemons
> > > >> starting resourcemanager, logging to
> > > >> /usr/local/lib/hadoop-2.7.2/logs/yarn-root-resourcemanager-
> > > >> 61cfd8f63c77.out
> > > >> localhost: Warning: Permanently added 'localhost' (ECDSA) to the
> list
> > of
> > > >> known hosts.
> > > >> localhost: starting nodemanager, logging to
> > > >> /usr/local/lib/hadoop-2.7.2/logs/yarn-root-nodemanager-
> > 61cfd8f63c77.out
> > > >> Gremlin REPL is not available. Cannot preprocess AsciiDoc files.
> > > >> Untagged: tinkerpop:build-1519830232
> > > >>
> > > >> On that particular run, I'd just deleted all my Docker images
> > (including
> > > >> the linux image) and it still failed. Any clues as to what might be
> > > wrong?
> > > >> am i the only person with a problem here?
> > > >>
> > > >
> > > >
> > >
> >
>

[jira] [Commented] (TINKERPOP-1586) SubgraphStrategy in OLAP

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380506#comment-16380506
 ] 

ASF GitHub Bot commented on TINKERPOP-1586:
---

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/799
  
VOTE: +1


> SubgraphStrategy in OLAP
> 
>
> Key: TINKERPOP-1586
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1586
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: stephen mallette
>Priority: Major
>
> If a vertex filter is provided in {{SubgraphStrategy}}, then it will turn any 
> edge step in the traversal into something like:
> {noformat}
> ...outE().filter(inV().vertexFilterCondittion())
> {noformat}
> This breaks any OLAP traversal (leaving the star graph) and is not even the 
> behavior that you would always want. We should have an option to disable the 
> adjacent vertex checks. In code this would just mean to replace this 
> {{else}}: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/decoration/SubgraphStrategy.java#L92
> ...with {{else if (checkAdjacentVertices)}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop issue #799: TINKERPOP-1586 Added checkAdjacentVertices option to S...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/799
  
VOTE: +1


---

Re: Documentation generation with Docker

[Robert Dale]

Yup, it's a step in the release docs.  Once updated, master builds docs for
me.

Robert Dale

On Wed, Feb 28, 2018 at 10:42 AM, Stephen Mallette 
wrote:

> ah - i forgot to do that step.i'm running tp32 now to see if that
> works, but i'll fix that issue on master.
>
> On Wed, Feb 28, 2018 at 10:41 AM, Robert Dale  wrote:
>
> > Could it be that 'bin/gremlin.sh' is linked to a specific version? Does
> > this have to be updated every release?
> >
> > $ ll gremlin-console/bin/gremlin.sh
> > gremlin-console/bin/gremlin.sh ->
> > ../target/apache-tinkerpop-gremlin-console-3.3.2-
> SNAPSHOT-standalone/bin/
> > gremlin.sh
> >
> > Robert Dale
> >
> > On Wed, Feb 28, 2018 at 10:37 AM, Robert Dale  wrote:
> >
> > > I got it too. tp32: good.  tp33: good. master: bad.
> > >
> > > Robert Dale
> > >
> > > On Wed, Feb 28, 2018 at 10:20 AM, Stephen Mallette <
> spmalle...@gmail.com
> > >
> > > wrote:
> > >
> > >> I'm having no success generating docs with Docker. On master i'm
> > currently
> > >> getting:
> > >>
> > >> Starting namenodes on [localhost]
> > >> localhost: Warning: Permanently added 'localhost' (ECDSA) to the list
> of
> > >> known hosts.
> > >> localhost: starting namenode, logging to
> > >> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-namenode-
> 61cfd8f63c77.out
> > >> localhost: Warning: Permanently added 'localhost' (ECDSA) to the list
> of
> > >> known hosts.
> > >> localhost: starting datanode, logging to
> > >> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-datanode-
> 61cfd8f63c77.out
> > >> Starting secondary namenodes [0.0.0.0]
> > >> 0.0.0.0: Warning: Permanently added '0.0.0.0' (ECDSA) to the list of
> > >> known
> > >> hosts.
> > >> 0.0.0.0: starting secondarynamenode, logging to
> > >> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-secondarynameno
> > >> de-61cfd8f63c77.out
> > >> starting yarn daemons
> > >> starting resourcemanager, logging to
> > >> /usr/local/lib/hadoop-2.7.2/logs/yarn-root-resourcemanager-
> > >> 61cfd8f63c77.out
> > >> localhost: Warning: Permanently added 'localhost' (ECDSA) to the list
> of
> > >> known hosts.
> > >> localhost: starting nodemanager, logging to
> > >> /usr/local/lib/hadoop-2.7.2/logs/yarn-root-nodemanager-
> 61cfd8f63c77.out
> > >> Gremlin REPL is not available. Cannot preprocess AsciiDoc files.
> > >> Untagged: tinkerpop:build-1519830232
> > >>
> > >> On that particular run, I'd just deleted all my Docker images
> (including
> > >> the linux image) and it still failed. Any clues as to what might be
> > wrong?
> > >> am i the only person with a problem here?
> > >>
> > >
> > >
> >
>

Re: Documentation generation with Docker

[Stephen Mallette]

ah - i forgot to do that step.i'm running tp32 now to see if that
works, but i'll fix that issue on master.

On Wed, Feb 28, 2018 at 10:41 AM, Robert Dale  wrote:

> Could it be that 'bin/gremlin.sh' is linked to a specific version? Does
> this have to be updated every release?
>
> $ ll gremlin-console/bin/gremlin.sh
> gremlin-console/bin/gremlin.sh ->
> ../target/apache-tinkerpop-gremlin-console-3.3.2-SNAPSHOT-standalone/bin/
> gremlin.sh
>
> Robert Dale
>
> On Wed, Feb 28, 2018 at 10:37 AM, Robert Dale  wrote:
>
> > I got it too. tp32: good.  tp33: good. master: bad.
> >
> > Robert Dale
> >
> > On Wed, Feb 28, 2018 at 10:20 AM, Stephen Mallette  >
> > wrote:
> >
> >> I'm having no success generating docs with Docker. On master i'm
> currently
> >> getting:
> >>
> >> Starting namenodes on [localhost]
> >> localhost: Warning: Permanently added 'localhost' (ECDSA) to the list of
> >> known hosts.
> >> localhost: starting namenode, logging to
> >> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-namenode-61cfd8f63c77.out
> >> localhost: Warning: Permanently added 'localhost' (ECDSA) to the list of
> >> known hosts.
> >> localhost: starting datanode, logging to
> >> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-datanode-61cfd8f63c77.out
> >> Starting secondary namenodes [0.0.0.0]
> >> 0.0.0.0: Warning: Permanently added '0.0.0.0' (ECDSA) to the list of
> >> known
> >> hosts.
> >> 0.0.0.0: starting secondarynamenode, logging to
> >> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-secondarynameno
> >> de-61cfd8f63c77.out
> >> starting yarn daemons
> >> starting resourcemanager, logging to
> >> /usr/local/lib/hadoop-2.7.2/logs/yarn-root-resourcemanager-
> >> 61cfd8f63c77.out
> >> localhost: Warning: Permanently added 'localhost' (ECDSA) to the list of
> >> known hosts.
> >> localhost: starting nodemanager, logging to
> >> /usr/local/lib/hadoop-2.7.2/logs/yarn-root-nodemanager-61cfd8f63c77.out
> >> Gremlin REPL is not available. Cannot preprocess AsciiDoc files.
> >> Untagged: tinkerpop:build-1519830232
> >>
> >> On that particular run, I'd just deleted all my Docker images (including
> >> the linux image) and it still failed. Any clues as to what might be
> wrong?
> >> am i the only person with a problem here?
> >>
> >
> >
>

Re: Documentation generation with Docker

[Robert Dale]

Could it be that 'bin/gremlin.sh' is linked to a specific version? Does
this have to be updated every release?

$ ll gremlin-console/bin/gremlin.sh
gremlin-console/bin/gremlin.sh ->
../target/apache-tinkerpop-gremlin-console-3.3.2-SNAPSHOT-standalone/bin/gremlin.sh

Robert Dale

On Wed, Feb 28, 2018 at 10:37 AM, Robert Dale  wrote:

> I got it too. tp32: good.  tp33: good. master: bad.
>
> Robert Dale
>
> On Wed, Feb 28, 2018 at 10:20 AM, Stephen Mallette 
> wrote:
>
>> I'm having no success generating docs with Docker. On master i'm currently
>> getting:
>>
>> Starting namenodes on [localhost]
>> localhost: Warning: Permanently added 'localhost' (ECDSA) to the list of
>> known hosts.
>> localhost: starting namenode, logging to
>> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-namenode-61cfd8f63c77.out
>> localhost: Warning: Permanently added 'localhost' (ECDSA) to the list of
>> known hosts.
>> localhost: starting datanode, logging to
>> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-datanode-61cfd8f63c77.out
>> Starting secondary namenodes [0.0.0.0]
>> 0.0.0.0: Warning: Permanently added '0.0.0.0' (ECDSA) to the list of
>> known
>> hosts.
>> 0.0.0.0: starting secondarynamenode, logging to
>> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-secondarynameno
>> de-61cfd8f63c77.out
>> starting yarn daemons
>> starting resourcemanager, logging to
>> /usr/local/lib/hadoop-2.7.2/logs/yarn-root-resourcemanager-
>> 61cfd8f63c77.out
>> localhost: Warning: Permanently added 'localhost' (ECDSA) to the list of
>> known hosts.
>> localhost: starting nodemanager, logging to
>> /usr/local/lib/hadoop-2.7.2/logs/yarn-root-nodemanager-61cfd8f63c77.out
>> Gremlin REPL is not available. Cannot preprocess AsciiDoc files.
>> Untagged: tinkerpop:build-1519830232
>>
>> On that particular run, I'd just deleted all my Docker images (including
>> the linux image) and it still failed. Any clues as to what might be wrong?
>> am i the only person with a problem here?
>>
>
>

Re: Documentation generation with Docker

[Robert Dale]

I got it too. tp32: good.  tp33: good. master: bad.

Robert Dale

On Wed, Feb 28, 2018 at 10:20 AM, Stephen Mallette 
wrote:

> I'm having no success generating docs with Docker. On master i'm currently
> getting:
>
> Starting namenodes on [localhost]
> localhost: Warning: Permanently added 'localhost' (ECDSA) to the list of
> known hosts.
> localhost: starting namenode, logging to
> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-namenode-61cfd8f63c77.out
> localhost: Warning: Permanently added 'localhost' (ECDSA) to the list of
> known hosts.
> localhost: starting datanode, logging to
> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-datanode-61cfd8f63c77.out
> Starting secondary namenodes [0.0.0.0]
> 0.0.0.0: Warning: Permanently added '0.0.0.0' (ECDSA) to the list of known
> hosts.
> 0.0.0.0: starting secondarynamenode, logging to
> /usr/local/lib/hadoop-2.7.2/logs/hadoop-root-secondarynamenode-
> 61cfd8f63c77.out
> starting yarn daemons
> starting resourcemanager, logging to
> /usr/local/lib/hadoop-2.7.2/logs/yarn-root-resourcemanager-61cfd8f63c77.
> out
> localhost: Warning: Permanently added 'localhost' (ECDSA) to the list of
> known hosts.
> localhost: starting nodemanager, logging to
> /usr/local/lib/hadoop-2.7.2/logs/yarn-root-nodemanager-61cfd8f63c77.out
> Gremlin REPL is not available. Cannot preprocess AsciiDoc files.
> Untagged: tinkerpop:build-1519830232
>
> On that particular run, I'd just deleted all my Docker images (including
> the linux image) and it still failed. Any clues as to what might be wrong?
> am i the only person with a problem here?
>

Documentation generation with Docker

[Stephen Mallette]

I'm having no success generating docs with Docker. On master i'm currently
getting:

Starting namenodes on [localhost]
localhost: Warning: Permanently added 'localhost' (ECDSA) to the list of
known hosts.
localhost: starting namenode, logging to
/usr/local/lib/hadoop-2.7.2/logs/hadoop-root-namenode-61cfd8f63c77.out
localhost: Warning: Permanently added 'localhost' (ECDSA) to the list of
known hosts.
localhost: starting datanode, logging to
/usr/local/lib/hadoop-2.7.2/logs/hadoop-root-datanode-61cfd8f63c77.out
Starting secondary namenodes [0.0.0.0]
0.0.0.0: Warning: Permanently added '0.0.0.0' (ECDSA) to the list of known
hosts.
0.0.0.0: starting secondarynamenode, logging to
/usr/local/lib/hadoop-2.7.2/logs/hadoop-root-secondarynamenode-61cfd8f63c77.out
starting yarn daemons
starting resourcemanager, logging to
/usr/local/lib/hadoop-2.7.2/logs/yarn-root-resourcemanager-61cfd8f63c77.out
localhost: Warning: Permanently added 'localhost' (ECDSA) to the list of
known hosts.
localhost: starting nodemanager, logging to
/usr/local/lib/hadoop-2.7.2/logs/yarn-root-nodemanager-61cfd8f63c77.out
Gremlin REPL is not available. Cannot preprocess AsciiDoc files.
Untagged: tinkerpop:build-1519830232

On that particular run, I'd just deleted all my Docker images (including
the linux image) and it still failed. Any clues as to what might be wrong?
am i the only person with a problem here?

Re: [Discuss] Expose metadata from Gremlin Server to Clients.

[Stephen Mallette]

I'm fine with using the last response message as the carrier for this
metadata on a particular request. I can't really tell if there is much work
to do on Gremlin Server itself here. It seems like most of the work must
occur on the various drivers (you mention the .NET api, but all of the
drivers would need to support this feature). However, I would think that we
would want Gremlin Server itself to append in some kind metadata (maybe
query time? something easy) so that we could write tests for the
drivers in TinkerPop itself. There is also the question of how we would
expose this metadata to GLVs which don't see response messages at all. A
traversal might need some metadata itself so that the user could retrieve
the server metadata from that. The implementation between Java and the GLVs
might be different here as the GLV traversal class is typically quite
lightweight and only used for generating bytecode.

I'm not so sure I like the  SubmitAsynWithHeaders()  but I don't think too
much about how the .NET driver works. Is there a reason to not always
return metadata? could it be expensive to do so? If we just added an extra
method how would remote traversals configure this option? I think we need
another way. Generally speaking, for Java, I think I would like to see the
metadata available to the ResultSet somehow which would in turn make it
pretty easy to get it on to a Traversal instance once that facility was
made available.but as to how to enable or disable the return of the
metadata, i'm not sure how that should work just yet - i need to think on
that some more.

For committers who work on GLVs, please take a look at this thread and
offer your thoughts on how this might work in the GLV driver you tend to
have the most knowledge on. Let's see if we can come to one nice unified
solution. At that point, we can setup a ticket in JIRA and go from there.

Ashwini, thanks for offering a pull request for this by the way. Once we
get consensus on how to do this, we'll see if tasks need to be divided and
how you might contribute.



On Mon, Feb 26, 2018 at 6:45 PM, Ashwini Singh <
ashws...@microsoft.com.invalid> wrote:

> Hi Stephen,
>
> Thanks for considering the change.
>
> We would be more inclined towards the first approach since the having a
> ping/pong websocket message can be a bit noisy and requires sophisticated
> handling on the client driver side.
>
> For handling multiple response messages. I would suggest to rely on last
> message as these are the metadata for request execution. Partial response
> is very internal to the client drivers (based on limited understanding of
> tinkerpop client drivers :) , correct me if you differ) and can be exposed
> separately (if really needed later).
>
> For implementation, Let us know if we can chip in there and submit PR. The
> high level approach to achieve this is to have corresponding
> SubmitAsynWithHeaders()  for every SubmitAsync() that returns a
> encapsulated result with attributes and IReadOnlyCollectio. Let me know
> if you see any concerns adding a new API.
>
> Thanks a lot,
> Ashwini Singh
> Software Engineer @ Azure Cosmos DB
>
>
>
> -Original Message-
> From: Stephen Mallette 
> Sent: Friday, February 23, 2018 5:13 PM
> To: dev@tinkerpop.apache.org
> Subject: Re: [Discuss] Expose metadata from Gremlin Server to Clients.
>
> Adding those kinds of details was the reason we had the
> ResponseStatus.attributes Map. I can really only speak for the java driver
> as I only know that one really well (we might need other TinkerPop experts
> to chime in for python, .net and c#).  The java driver doesn't really
> present ways to get that information easily under usage that doesn't deal
> directly with RequestMessage directly (which people typically don't do).
> Another thing to think about is that since a single request might return
> multiple ResponseMessage instances you might not want to return that kind
> of data on every response - maybe just to be returned on the first (or last
> message) and then we somehow preserve that information and make it
> accessible on the result somehowwe sorta have some kinda of precedent
> for that with side-effect data generated by bytecode based traversals - we
> can probably build in something similar for this sort of thing.
>
> I also toyed with the idea of using ping/pong websocket messages to carry
> general information about the server to the client. Not sure if any of the
> metadata you want to send back would fit in there, but that could be
> another option.
>
> Does any of that sound helpful?
>
> On Fri, Feb 23, 2018 at 3:41 PM, Ashwini Singh <
> ashws...@microsoft.com.invalid> wrote:
>
> > Hi All,
> >
> > We are working on to expose metadata as part of gremlin to response to
> > client. The metadata is simply a property bag to provide special
> > message/hints to the client. But currently client libraries strip off
> > everything and only return the data to the client.
> >
> 

[jira] [Commented] (TINKERPOP-1862) TinkerGraph VertexProgram message passing doesn't work properly when using Direction.BOTH

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380270#comment-16380270
 ] 

ASF GitHub Bot commented on TINKERPOP-1862:
---

Github user spmallette commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/801#discussion_r171238657
  
--- Diff: 
tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerFactory.java
 ---
@@ -149,6 +149,13 @@ public static void generateKitchenSink(final 
TinkerGraph graph) {
 g.addV("loops").property(T.id, 1000).property("name", 
"loop").as("me").
   addE("self").to("me").
   iterate();
+final String LABEL = "message_passing_test";
+final String EDGE_LABEL = "msg_pass_test_edge";
+final String PROPERTY_IN = "propertyin";
+Vertex a = graph.addVertex(T.id, 2000, T.label, LABEL, 
PROPERTY_IN, "a");
--- End diff --

all of these sample graphs need a "name" property of some sort. that's why 
the build is currently failing for me.  please "final" the two `Vertex` 
variables. 


> TinkerGraph VertexProgram message passing doesn't work properly when using 
> Direction.BOTH
> -
>
> Key: TINKERPOP-1862
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1862
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process, tinkergraph
>Affects Versions: 3.2.7
>Reporter: Philip Graff
>Priority: Major
>
> I think the messages are being sent properly in TinkerMessenger, but when I 
> call messenger.receiveMessages(), the vertex is getting messages from the 
> outVertex of their edges regardless of the edge direction. This is due to 
> line 71 of TinkerMessenger (linked below) which calls 
> Edge.vertices(direction).next(), thus getting the first result out of the 
> Vertex iterator. For IN or OUT, this isn't a problem. But for BOTH, following 
> line 124 of TinkerEdge (linked below), the outVertex is always returned 
> first. TinkerMessenger needs to be modified to return the correct vertex (I 
> think it's the one that != this.vertex).
> https://github.com/apache/tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/process/computer/TinkerMessenger.java#L71
> https://github.com/apache/tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerEdge.java#L124



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop pull request #801: TINKERPOP-1862 TinkerMessenger proper handling ...

[spmallette]

Github user spmallette commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/801#discussion_r171238657
  
--- Diff: 
tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerFactory.java
 ---
@@ -149,6 +149,13 @@ public static void generateKitchenSink(final 
TinkerGraph graph) {
 g.addV("loops").property(T.id, 1000).property("name", 
"loop").as("me").
   addE("self").to("me").
   iterate();
+final String LABEL = "message_passing_test";
+final String EDGE_LABEL = "msg_pass_test_edge";
+final String PROPERTY_IN = "propertyin";
+Vertex a = graph.addVertex(T.id, 2000, T.label, LABEL, 
PROPERTY_IN, "a");
--- End diff --

all of these sample graphs need a "name" property of some sort. that's why 
the build is currently failing for me.  please "final" the two `Vertex` 
variables. 


---