[jira] [Commented] (TINKERPOP-2216) Consider adding conventional status attribute key for warnings

[ASF GitHub Bot (JIRA)]

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

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

dalaro commented on pull request #1113: TINKERPOP-2216 add status attribute for 
warnings
URL: https://github.com/apache/tinkerpop/pull/1113
 
 
   JIRA link: https://issues.apache.org/jira/browse/TINKERPOP-2216
   
   There are a lot of alternative ways to approach this.  I'm just opening this 
PR, with this specific approach, because it illustrates the suggested feature a 
bit more clearly than the prose in the JIRA issue description.
   
   This adds a new {{Tokens}} string literal with the value `"warnings"`.  The 
console's `DriverRemoteAcceptor` checks for this status attribute every time it 
receives a remote resultset, printing the value above the results (to `err` 
when available).  If the value is a list, each element gets passed through 
`String#valueOf` and printed on a separate line.  Otherwise, it's just passed 
through `String#valueOf` and printed once.
   
   Testing this in isolation seems a bit tricky.  I've been testing this 
coupled with a remote graph running in Gremlin-Server. If anyone has 
suggestions about reusable test harness bits underneath 
`gremlin-console/src/test` that I should reuse for this, I'd be interested.
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Consider adding conventional status attribute key for warnings
> --
>
> Key: TINKERPOP-2216
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2216
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: console, server
>Affects Versions: 3.4.2
>Reporter: Dan LaRocque
>Priority: Minor
>
> [Status 
> attributes|http://tinkerpop.apache.org/docs/3.4.1/upgrade/#_status_attributes]
>  let server-side graph providers send arbitrary metadata alongside graph 
> resultsets.  The client can either ignore attributes or check for them.
> A remote graph implementation might want to send warning information back to 
> the client along with a resultset.  Maybe a traversal executed successfully, 
> but it contained some kind of implementation-specific antipattern that 
> justifies a warning.
> For instance, {{Tokens}} defines {{STATUS_ATTRIBUTE_EXCEPTIONS}} and 
> {{STATUS_ATTRIBUTE_STACK_TRACE}}.  Perhaps we could add a new 
> {{STATUS_ATTRIBUTE_WARNINGS}} alongside those two.  The console's 
> {{DriverRemoteAcceptor}} could check for this key when processing each result 
> set, printing the associated value (when an entry is present).
> I've already done this on the 3.4.x line.  I don't know whether this is 
> something TinkerPop would want, or whether it should remain in 
> vendor-specific extensions, or if there is some other approach that might fit 
> better; but I'll open a PR with what I've been using.



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

[jira] [Created] (TINKERPOP-2216) Consider adding conventional status attribute key for warnings

[Dan LaRocque (JIRA)]

Dan LaRocque created TINKERPOP-2216:
---

 Summary: Consider adding conventional status attribute key for 
warnings
 Key: TINKERPOP-2216
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2216
 Project: TinkerPop
  Issue Type: Improvement
  Components: console, server
Affects Versions: 3.4.2
Reporter: Dan LaRocque


[Status 
attributes|http://tinkerpop.apache.org/docs/3.4.1/upgrade/#_status_attributes] 
let server-side graph providers send arbitrary metadata alongside graph 
resultsets.  The client can either ignore attributes or check for them.

A remote graph implementation might want to send warning information back to 
the client along with a resultset.  Maybe a traversal executed successfully, 
but it contained some kind of implementation-specific antipattern that 
justifies a warning.

For instance, {{Tokens}} defines {{STATUS_ATTRIBUTE_EXCEPTIONS}} and 
{{STATUS_ATTRIBUTE_STACK_TRACE}}.  Perhaps we could add a new 
{{STATUS_ATTRIBUTE_WARNINGS}} alongside those two.  The console's 
{{DriverRemoteAcceptor}} could check for this key when processing each result 
set, printing the associated value (when an entry is present).

I've already done this on the 3.4.x line.  I don't know whether this is 
something TinkerPop would want, or whether it should remain in vendor-specific 
extensions, or if there is some other approach that might fit better; but I'll 
open a PR with what I've been using.



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

N-Tuple Transactions?

[Marko Rodriguez]

Hello Josh (others),

You mentioned a week or so ago that the n-tuple model should be able to capture 
both indices and transactions.

At the time, I scoffed at the notion. However, as you know, I have been 
recently enlightened to how n-tuples can model indices and am using it 
extensively in the spec. What I would like to contemplate now is how you figure 
transactions being modeled?

Thanks,
Marko.

http://rredux.com 

[jira] [Closed] (TINKERPOP-2190) Document Gremlin sanitization best practices

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-2190.
---
   Resolution: Done
 Assignee: stephen mallette
Fix Version/s: 3.4.2

Updated docs for to provide information on Gremlin injection - 
https://github.com/apache/tinkerpop/commit/dfca86c35c6d0d5c9d332aaa559cc25ea561b803

> Document Gremlin sanitization best practices
> 
>
> Key: TINKERPOP-2190
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2190
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.3.6, 3.4.1
>Reporter: Florian Hockmann
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.4.2
>
>
> We already have docs on how to prevent arbitrary code execution through the 
> script engine, but nothing yet about injections in Gremlin, basically the 
> equivalent of SQL injections.
>  I wrote [a post on Stack 
> Overflow|https://stackoverflow.com/questions/44473303/how-to-prevent-gremlin-injection-in-c/44538936#44538936]
>  on this topic which we can use as a basis here.
>  Possible topics include:
>  * Difference between GLVs and Gremlin scripts
>  * Demonstrate when and how injections can occur
>  * How to prevent injections
> This could either be added as an [implementation 
> recipe|http://tinkerpop.apache.org/docs/current/recipes/#_implementation_recipes]
>  or as a sub section for [Gremlin Server 
> security|http://tinkerpop.apache.org/docs/current/reference/#security].



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

[jira] [Closed] (TINKERPOP-2198) Documentation for Store contradicts itself

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-2198.
---
   Resolution: Fixed
 Assignee: stephen mallette
Fix Version/s: 3.4.2
   3.3.7

Updated the documentation to reflect the effect of {{EarlyLimitStrategy}}: 
https://github.com/apache/tinkerpop/commit/783eb0758fe5ae3fc9804438cb641bab9b4efc84

> Documentation for Store contradicts itself
> --
>
> Key: TINKERPOP-2198
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2198
> Project: TinkerPop
>  Issue Type: Bug
>  Components: documentation, process
>Affects Versions: 3.3.6
>Reporter: Martijn Dwars
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.3.7, 3.4.2
>
>
> The [Store 
> Step|http://tinkerpop.apache.org/docs/current/reference/#store-step] shows 
> the following example:
> {{gremlin> g.V().store('x').limit(1).cap('x')}}
> {{==>[v[1]]}}
>   
>  and continues with the following explanation:
>   
> {quote}It is interesting to note that there are two results in the 
> {{store()}} side-effect even though the interval selection is for 1 object. 
> Realize that when the second object is on its way to the {{range()}} filter 
> (i.e. {{[0..1]}}), it passes through {{store()}} and thus, stored before 
> filtered.
> {quote}
> The problem is that the example does _not_ show this lazy behavior. The 
> correct output would be:
> {{==>[v[1], v[2]]}}



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

[jira] [Closed] (TINKERPOP-2214) Gremlin client with version 3.2.3 connect to server with version 3.4.1 auth failed

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-2214.
---
Resolution: Not A Problem

I'm sorry, but I don't believe that there is compatibility between 3.2.3 and 
3.4.1 with respect to authentication - I can't remember exactly why, but I 
think it had something to do with an inconsistency/bug that could only be fixed 
with a breaking change and we did that somewhere between 3.2.x and 3.3.x (maybe 
it was 3.3.x and 3.4.0 though - my memory is not clear). In any case, there are 
a lot of major changes beyond just this authentication problem between the two 
versions you are trying to use. You will need to upgrade your client. Generally 
speaking, for best results, we recommend that you use the same version of 
TinkerPop on the client as the server. At the very least you should try to use 
the same "y" version of "x.y.z" on client and server - it's somewhat rare to 
find problems between "z" releases.

> Gremlin client with version 3.2.3 connect to server with version 3.4.1 auth 
> failed
> --
>
> Key: TINKERPOP-2214
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2214
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.1
>Reporter: Fang Yong
>Priority: Major
>
> When I use client with 3.2.3 version and connect to gremlin server with 
> version 3.4.1, it auth failed with the following message
> Incorrect type for : sasl - base64 encoded String is expected
> I found this message is in SaslAuthenticationHandler and when this handler 
> receive byte[] from client 3.2.3, it failed. 



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

[jira] [Created] (TINKERPOP-2215) Better exception message for connection problems

[Florian Hockmann (JIRA)]

Florian Hockmann created TINKERPOP-2215:
---

 Summary: Better exception message for connection problems
 Key: TINKERPOP-2215
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2215
 Project: TinkerPop
  Issue Type: Improvement
  Components: dotnet
Affects Versions: 3.4.1
Reporter: Florian Hockmann


The {{ConnectionPool}} currently checks whether the pool is empty and then 
tries to retrieve an available connection if it is not empty. If this fails, 
then a {{ConnectionPoolBusyException}} is thrown with this text:
{quote}All 4 connections have reached their MaxInProcessPerConnection limit of 
32. Consider increasing either the PoolSize or the MaxInProcessPerConnection 
limit.
{quote}
However, this exception can also be thrown if all connections in the pool were 
already closed and were therefore removed from the pool. The exception message 
doesn't make sense in this case.

A different exception should be thrown if the pool only contained already 
closed connections as it's important for users to know whether they actually 
executed too many requests in parallel or whether there is a connection problem.



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