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

[Ashwini Singh]

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.
>
> Specifically, We want to expose details like Request Charge, Rate 
> limiting/Retry policy details etc. In the other scenarios in Cosmos DB 
> we provide these details to the client is through response headers. We 
> did some investigation around this and one of the options is expose 
> these is through response attributes. Gremlin Server can add metadata 
> as part of gremlin response attributes (For example, set the property 
> bag on ResponseStatus.Attributes for Gremlin.Net) that can be 
> serialized by the client drivers to the clients.
>
> We  would like to learn more if there are precedence around this and 
> if there are any recommended ways to achieve this in Gremlin protocol 
> and client drivers.
>
> Thanks a lot,
> Ashwini Singh
> Software Engineer @ Azure Cosmos DB
>
>

[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=16377512#comment-16377512
 ] 

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

Github user PBGraff commented on the issue:

https://github.com/apache/tinkerpop/pull/801
  
I'm not sure why this is failing, it's due to something with the 
javascript. I don't know how my changes potentially affected that.


> 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
  
I'm not sure why this is failing, it's due to something with the 
javascript. I don't know how my changes potentially affected that.


---

[jira] [Created] (TINKERPOP-1903) Credentials DSL should use the Java annotation processor

[stephen mallette (JIRA)]

stephen mallette created TINKERPOP-1903:
---

 Summary: Credentials DSL should use the Java annotation processor
 Key: TINKERPOP-1903
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1903
 Project: TinkerPop
  Issue Type: Improvement
  Components: server
Affects Versions: 3.2.7
Reporter: stephen mallette


This content is a bit outdated - 
http://tinkerpop.apache.org/docs/current/reference/#credentials-dsl

uses the old method of DSL development prior to when we established the 
annotation processor - need to fix both the code itself and the documentation.



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