[jira] [Closed] (TINKERPOP-2230) match() step unexpected behaviours

2019-06-18 Thread stephen mallette (JIRA)


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

stephen mallette closed TINKERPOP-2230.
---

> match() step unexpected behaviours
> --
>
> Key: TINKERPOP-2230
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2230
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.4.1
>Reporter: Fabio Lorenzi
>Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: gremlin
> Fix For: 3.3.8, 3.4.3, 3.5.0
>
>
> On the well known software graph:
> {code:java}
> gremlin> g.V().match(
> ..1> __.as('a').out('knows').as('b'),
> ..2> __.as('b').out('created').as('c'))
> ==>[a:v[1],b:v[4],c:v[5]]
> ==>[a:v[1],b:v[4],c:v[3]]
> gremlin> g.V().match(
> ..1> __.as('b').out('created').as('c'),
> ..2> __.as('a').out('knows').as('b'))
> The provided match pattern is unsolvable: [[MatchStartStep(a), 
> VertexStep(OUT,[knows],vertex), MatchEndStep(b)], [MatchStartStep(b), 
> VertexStep(OUT,[created],vertex), MatchEndStep(c)]]
> {code}
> with the second one being solvable as well (I think). (?)
> Quoting [~dkuppitz]:
> "I just noticed that the error message of my failing traversal actually 
> contains a solvable form of patterns. It's really confusing; if you want, 
> create a Jira ticket for that issue, perhaps someone dares to analyze that 
> crazy code"
> please see 
> [this|https://stackoverflow.com/questions/56218188/match-clause-is-unsolvable-behavior-is-not-clear/56260508#56260508]
>  for more information.



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


[jira] [Updated] (TINKERPOP-2247) Server should respect charset specified in request header

2019-06-18 Thread stephen mallette (JIRA)


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

stephen mallette updated TINKERPOP-2247:

Affects Version/s: 3.3.7
  Component/s: server
   Issue Type: Improvement  (was: Wish)

> Server should respect charset specified in request header
> -
>
> Key: TINKERPOP-2247
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2247
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.3.7
>Reporter: Divij Vaidya
>Priority: Minor
>
> Currently, the server uses UTF-8 as its default charset and that is hardcoded 
> in the system [1], irrespective of the content-type provided in the request. 
> This task is to read the charset from the HTTP Content-Type header and use 
> the charset to encode the response string.
>  
> [1][https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/handler/HttpGremlinEndpointHandler.java#L254]



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


[jira] [Updated] (TINKERPOP-2246) Consolidate the error propagation to the client

2019-06-18 Thread stephen mallette (JIRA)


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

stephen mallette updated TINKERPOP-2246:

Affects Version/s: 3.4.2

> Consolidate the error propagation to the client
> ---
>
> Key: TINKERPOP-2246
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2246
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.4.2
>Reporter: Divij Vaidya
>Priority: Minor
>
> Some places in the code base use the ResponseHandlerContext which ensures 
> that only a single response is sent for a particular request [1] but other 
> places do not [2]. This task is to use the ResponseContext consistently 
> across the code base to prevent cases where client gets two messages for the 
> same request (this can break the client when it has removed the RequestQueue 
> thinking that the query is complete and yet a message comes for that request 
> queue).
> [1] 
> [https://github.com/apache/tinkerpop/blob/d1a3fa147d1f009ae57274827c9b59426dfc6e58/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/AbstractOpProcessor.java#L100]
> [[2] 
> https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/traversal/TraversalOpProcessor.java#L315|https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/traversal/TraversalOpProcessor.java#L315]



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


[jira] [Commented] (TINKERPOP-2245) [Refactor] Consolidate the executor for bytecode & string based client

2019-06-18 Thread stephen mallette (JIRA)


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

stephen mallette commented on TINKERPOP-2245:
-

so scary, but, yes, this is an area of technical debt that exists. 
unfortunately the {{GremlinExecutor}} did not quite hit the layer of 
abstraction i was hoping to hit when it was first developed. we then developed 
bytecode several years after the fact and sorta wedged it in there. there is a 
fair bit of code/function duplication that could be eradicated across Gremlin 
Server. 

> [Refactor] Consolidate the executor for bytecode & string based client
> --
>
> Key: TINKERPOP-2245
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2245
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.4.2
>Reporter: Divij Vaidya
>Priority: Minor
>
> We have two code paths in the server which perform (more or less) the same 
> functions. One is the executor for string based queries and other is the 
> executor for bytecode. This code can be refactored together so that the logic 
> to handle timeout, handle exception during execution, handle exception before 
> execution and others can consolidated. 
> [https://github.com/apache/tinkerpop/blob/master/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/engine/GremlinExecutor.java#L246]
> and
> [https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/traversal/TraversalOpProcessor.java#L333]



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


[jira] [Updated] (TINKERPOP-2245) [Refactor] Consolidate the executor for bytecode & string based client

2019-06-18 Thread stephen mallette (JIRA)


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

stephen mallette updated TINKERPOP-2245:

Affects Version/s: 3.4.2

> [Refactor] Consolidate the executor for bytecode & string based client
> --
>
> Key: TINKERPOP-2245
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2245
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.4.2
>Reporter: Divij Vaidya
>Priority: Minor
>
> We have two code paths in the server which perform (more or less) the same 
> functions. One is the executor for string based queries and other is the 
> executor for bytecode. This code can be refactored together so that the logic 
> to handle timeout, handle exception during execution, handle exception before 
> execution and others can consolidated. 
> [https://github.com/apache/tinkerpop/blob/master/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/engine/GremlinExecutor.java#L246]
> and
> [https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/traversal/TraversalOpProcessor.java#L333]



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


[jira] [Commented] (TINKERPOP-2248) Instability of driver for blocked requests

2019-06-18 Thread ASF GitHub Bot (JIRA)


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

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

spmallette commented on pull request #1146: TINKERPOP-2248 Force replacement of 
connections on certain errors
URL: https://github.com/apache/tinkerpop/pull/1146
 
 
   https://issues.apache.org/jira/browse/TINKERPOP-2248
   
   Relying only on the `Connection.isDead()` check to determine connection 
replacement seemed to introduce a regression as of 
2cd84ff1f3944d67d44cbba5bb032a1c57377975 The `shouldBlockRequestWhenTooBig` was 
failing somewhat randomly since that change. Not sure if there is a better way 
to make `isDead()` be the only check needed for connection replacement in this 
context, but this change brings the logic back that checks exception types that 
were forcing replacement prior to this change. 
   
   @divijvaidya would you mind having a look at this change? perhaps you are 
aware of better solutions or perhaps I misinterpreted something in my analysis 
that you could correct?
   
   All tests pass with `docker/build.sh -t -i`
   
   VOTE +1
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


> Instability of driver for blocked requests
> --
>
> Key: TINKERPOP-2248
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2248
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver
>Affects Versions: 3.3.7
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
>
> I'm not sure what's causing this, because there haven't been changes to this 
> area of code that would likely have an ill effect, but the 
> {{shouldBlockRequestWhenTooBig}} integration test is failing with some 
> consistency which is making travis unhelpful. 
> https://api.travis-ci.org/v3/job/546837334/log.txt
> I'm thinking that it might be related to:
> https://github.com/apache/tinkerpop/commit/2cd84ff1f3944d67d44cbba5bb032a1c57377975
> as a blocked request of the type in that test will throw a 
> {{CorruptedFrameException}} and this commit has something to do with that 
> specifically.



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


Re: Some Asciidoc Tips and Fixes

2019-06-18 Thread Robert Dale
Sums it up nicely.  Bonus, if you go to the '...' dropdown and select 'View
file', it looks like everything is rendered correctly.

Robert Dale


On Fri, Jun 14, 2019 at 7:39 AM Stephen Mallette 
wrote:

> I went ahead an added your tips to the dev docs:
>
>
> https://github.com/apache/tinkerpop/commit/ddac926ca8f22239e83658ffee65ec2415b3b838
>
>
> hope that looks ok.
>
> On Thu, May 30, 2019 at 8:56 AM Robert Dale  wrote:
>
> > I haven't added this to the docs yet.  As an update to #1, even `__` will
> > render as a nested emphasis if there is a following `__` in the same
> > paragraph, i.e. sentences touching, not separated by 2 or more newlines.
> > For example, http://tinkerpop.apache.org/docs/current/reference/
> >
> > The source is:
> >
> > NOTE: The `AnonymousTraversal` class above is just an alias for `__` as
> in
> > `from gremlin_python.process.graph_traversal import __ as
> > AnonymousTraversal`
> >
> > Renders as:
> >
> > The AnonymousTraversal class above is just an alias for *as infrom
> > gremlin_python.process.graph_traversal import *as AnonymousTraversal
> >
> > Should be:
> >
> > The AnonymousTraversal class above is just an alias for __ as in from
> > gremlin_python.process.graph_traversal import __ as AnonymousTraversal
> >
> > This is fixed by the same method:  `+__+`.
> >
> > Source fixed:
> >
> > NOTE: The `AnonymousTraversal` class above is just an alias for `+__+` as
> > in
> > `+from gremlin_python.process.graph_traversal import __ as
> > AnonymousTraversal+`
> >
> >
> > Robert Dale
> >
> >
> > On Tue, Apr 2, 2019 at 1:59 PM Stephen Mallette 
> > wrote:
> >
> > > eh...looks like those two sections could be better handled. the intent
> > for
> > > "Writing Documentation" was to give new contributors some basic
> > > instructions as to what was involved in doing that. the "Documentation"
> > > section is supposed to be for existing committers. maybe just push the
> > > details of of "Writing Documentation" down to "Documentation" and then
> > add
> > > your new tips there? just leave enough in "Writing Documentation" to
> > > introduce new contributors to it and then add a link to
> "Documentation"?
> > i
> > > don't have really strong feelings about how to organize it. if you
> think
> > > there is a better way to make that clean, feel free to propose
> something
> > or
> > > just leave it as it is and add your stuff where you feel it best fits.
> > >
> > > On Tue, Apr 2, 2019 at 1:28 PM Robert Dale  wrote:
> > >
> > > > Should it be there
> > > > <
> http://tinkerpop.apache.org/docs/current/dev/developer/#documentation
> > >
> > > or
> > > > here
> > > >
> > > >
> > >
> >
> http://tinkerpop.apache.org/docs/3.4.1/dev/developer/#_writing_documentation
> > > >  ?
> > > >
> > > > Robert Dale
> > > >
> > > >
> > > > On Sat, Mar 30, 2019 at 9:35 AM Stephen Mallette <
> spmalle...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > interesting - thanks for digging into this. do you mind doing a
> > > > > copy/paste/format of these tips to the dev docs so that they aren't
> > > lost
> > > > in
> > > > > the mailing list:
> > > > >
> > > > >
> > http://tinkerpop.apache.org/docs/current/dev/developer/#documentation
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Mar 27, 2019 at 6:23 AM Robert Dale 
> > wrote:
> > > > >
> > > > > > 0. Asciidoctor is not Asciidoc (applications)
> > > > > >
> > > > > > This was not immediately obvious to me when I started.  I have
> > found
> > > > that
> > > > > > Asciidoc renders the following scenarios correctly. However, our
> > > maven
> > > > > > build uses Asciidoctor which rendered incorrectly.  So if you
> write
> > > > > > asciidoc and use some tool to preview content and it looks good,
> > > verify
> > > > > > which tech it is using underneath. If it's not asciidoctor or
> > you're
> > > > not
> > > > > > sure, it would be a good idea to use the command-line asciidoctor
> > > tool
> > > > or
> > > > > > even better to use the maven build.
> > > > > >
> > > > > >
> > > > > > 1. Two anonymous traversals (__) in inline code
> > > > > > This will cause the content between the two __ to become
> emphasized
> > > > > > (italicized)
> > > > > >
> > > > > > E.g.
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tinkerpop.apache.org/docs/current/reference/#graph-traversal-steps
> > > > > >
> > > > > > To reduce the verbosity of the expression, it is good toimport
> > static
> > > > > > org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.*.***.
> > This
> > > > way,
> > > > > > instead of doing *.inE() for an anonymous traversal, it is
> possible
> > > to
> > > > > > simply write inE(). Be aware of language-specific reserved
> keywords
> > > > when
> > > > > > using anonymous traversals. For example, in and as are reserved
> > > > keywords
> > > > > in
> > > > > > Groovy, therefore you must use the verbose syntax *.in()** and
> > *.as()
> > > > to
> > > > > > avoid collisions.
> > > > > >
> > > > > > Cause:
> > > > > > Asciidoctor doesn't always do literal 

[jira] [Commented] (TINKERPOP-2243) Add user-agent to RequestOptions

2019-06-18 Thread Bryn Cooke (JIRA)


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

Bryn Cooke commented on TINKERPOP-2243:
---

BTW I do see the value in trying to generically expose the request headers to 
the client. Many of the existing Tokens should probably make their way there 
rather than residing in the payload. This will be a much larger refactor.

> Add user-agent to RequestOptions
> 
>
> Key: TINKERPOP-2243
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2243
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver, server
>Affects Versions: 3.4.2
>Reporter: Bryn Cooke
>Priority: Major
>
> It would be useful to know the 'user-agent' that is sending a request so that 
> the server can react in different ways. For instance:
>  * To log differently.
>  * To give different error messages.
> For instance, if the user is connecting via gremlin console then error 
> messages can include gremlin console specific help.



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


[jira] [Updated] (TINKERPOP-2248) Instability of driver for blocked requests

2019-06-18 Thread stephen mallette (JIRA)


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

stephen mallette updated TINKERPOP-2248:

Description: 
I'm not sure what's causing this, because there haven't been changes to this 
area of code that would likely have an ill effect, but the 
{{shouldBlockRequestWhenTooBig}} integration test is failing with some 
consistency which is making travis unhelpful. 

https://api.travis-ci.org/v3/job/546837334/log.txt

I'm thinking that it might be related to:

https://github.com/apache/tinkerpop/commit/2cd84ff1f3944d67d44cbba5bb032a1c57377975

as a blocked request of the type in that test will throw a 
{{CorruptedFrameException}} and this commit has something to do with that 
specifically.

  was:
I'm not sure what's causing this, because there haven't been changes to this 
area of code that would likely have an ill effect, but the 
{{shouldBlockRequestWhenTooBig}} integration test is failing with some 
consistency which is making travis unhelpful. 

https://api.travis-ci.org/v3/job/546837334/log.txt


> Instability of driver for blocked requests
> --
>
> Key: TINKERPOP-2248
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2248
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver
>Affects Versions: 3.3.7
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
>
> I'm not sure what's causing this, because there haven't been changes to this 
> area of code that would likely have an ill effect, but the 
> {{shouldBlockRequestWhenTooBig}} integration test is failing with some 
> consistency which is making travis unhelpful. 
> https://api.travis-ci.org/v3/job/546837334/log.txt
> I'm thinking that it might be related to:
> https://github.com/apache/tinkerpop/commit/2cd84ff1f3944d67d44cbba5bb032a1c57377975
> as a blocked request of the type in that test will throw a 
> {{CorruptedFrameException}} and this commit has something to do with that 
> specifically.



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


[jira] [Created] (TINKERPOP-2248) Instability of driver for blocked requests

2019-06-18 Thread stephen mallette (JIRA)
stephen mallette created TINKERPOP-2248:
---

 Summary: Instability of driver for blocked requests
 Key: TINKERPOP-2248
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2248
 Project: TinkerPop
  Issue Type: Bug
  Components: driver
Affects Versions: 3.3.7
Reporter: stephen mallette
Assignee: stephen mallette


I'm not sure what's causing this, because there haven't been changes to this 
area of code that would likely have an ill effect, but the 
{{shouldBlockRequestWhenTooBig}} integration test is failing with some 
consistency which is making travis unhelpful. 

https://api.travis-ci.org/v3/job/546837334/log.txt



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


[jira] [Work started] (TINKERPOP-2248) Instability of driver for blocked requests

2019-06-18 Thread stephen mallette (JIRA)


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

Work on TINKERPOP-2248 started by stephen mallette.
---
> Instability of driver for blocked requests
> --
>
> Key: TINKERPOP-2248
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2248
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver
>Affects Versions: 3.3.7
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
>
> I'm not sure what's causing this, because there haven't been changes to this 
> area of code that would likely have an ill effect, but the 
> {{shouldBlockRequestWhenTooBig}} integration test is failing with some 
> consistency which is making travis unhelpful. 
> https://api.travis-ci.org/v3/job/546837334/log.txt



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


Re: [DISCUSS] EOL 3.2.x

2019-06-18 Thread Stephen Mallette
Here is the link to the thread I started on the user list for feedback on
EOL of 3.2.x - no objections at this point:

https://groups.google.com/d/msg/gremlin-users/4MrTCON778I/HJwnGi9YBQAJ

I've updated the branch listings to reflect this direction.

On Tue, Jun 11, 2019 at 2:56 PM Stephen Mallette 
wrote:

> I think it's time to seal the tp32 branch. We haven't sent a single commit
> at it for two releases now (over 6 months)  and I can't think of why that
> would change at this point.
>
> Unless there are objections in the next 72 hours I will assume lazy
> consensus and start a thread on the user list for feedback. Assuming there
> is no objection there that causes further discussion, I will alter our dev
> documentation on the topic and we can consider the tp32 branch frozen.
>


[jira] [Commented] (TINKERPOP-2243) Add user-agent to RequestOptions

2019-06-18 Thread ASF GitHub Bot (JIRA)


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

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

BrynCooke commented on pull request #1145: TINKERPOP-2243 Add userAgent to 
RequestOptions.
URL: https://github.com/apache/tinkerpop/pull/1145
 
 
   This allows graph providers to taylor their error messages to the client.
 

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


> Add user-agent to RequestOptions
> 
>
> Key: TINKERPOP-2243
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2243
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver, server
>Affects Versions: 3.4.2
>Reporter: Bryn Cooke
>Priority: Major
>
> It would be useful to know the 'user-agent' that is sending a request so that 
> the server can react in different ways. For instance:
>  * To log differently.
>  * To give different error messages.
> For instance, if the user is connecting via gremlin console then error 
> messages can include gremlin console specific help.



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


[jira] [Commented] (TINKERPOP-2238) Fix remaining iterator leaks marked by @IgnoreIteratorLeak

2019-06-18 Thread ASF GitHub Bot (JIRA)


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

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

spmallette commented on pull request #1144: TINKERPOP-2238 Fixed all iterator 
leaks
URL: https://github.com/apache/tinkerpop/pull/1144
 
 
   https://issues.apache.org/jira/browse/TINKERPOP-2238
   
   Fixed all the iterator leaks. Remove the temporary "ignore leak" annotation. 
   
   All tests pass with `docker/build.sh -t -n -i`
   
   VOTE +1
 

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


> Fix remaining iterator leaks marked by @IgnoreIteratorLeak
> --
>
> Key: TINKERPOP-2238
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2238
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.7, 3.4.2
>Reporter: Divij Vaidya
>Assignee: stephen mallette
>Priority: Major
>
> As noted in the PR [https://github.com/apache/tinkerpop/pull/1118/] some of 
> the tests do not pass the leak detector and need to be fixed. These tests 
> have been annotated with @IgnoreIteratorLeak.
> After the tests (and associated code if required) is fixed, please delete the 
> annotation as well.



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


[jira] [Commented] (TINKERPOP-2243) Add user-agent to RequestOptions

2019-06-18 Thread Bryn Cooke (JIRA)


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

Bryn Cooke commented on TINKERPOP-2243:
---

When sending a request there is already an arbitrary map that is populated from 
the RequestOptions and could be extended to allow custom fields, but is 
probably out of scope for this ticket.

I'd be keen on not having any of this auto-magically wired up based on the 
classpath. What happens if the user has two clients in the same process but 
want different fields? What if the fields that are sent with the request are 
not static?

> Add user-agent to RequestOptions
> 
>
> Key: TINKERPOP-2243
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2243
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver, server
>Affects Versions: 3.4.2
>Reporter: Bryn Cooke
>Priority: Major
>
> It would be useful to know the 'user-agent' that is sending a request so that 
> the server can react in different ways. For instance:
>  * To log differently.
>  * To give different error messages.
> For instance, if the user is connecting via gremlin console then error 
> messages can include gremlin console specific help.



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