[jira] [Updated] (TINKERPOP-2337) In upgrade guide for 3.4.2, the option RemoteConnection.PER_REQUEST_TIMEOUT does not exist

2020-02-12 Thread Nicolas Trangosi (Jira)


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

Nicolas Trangosi updated TINKERPOP-2337:

Description: 
in  the file {{docs/src/upgrade/release-3.4.x.asciidoc}} the sentence
 {{ List vertices = g.with(RemoteConnection.PER_REQUEST_TIMEOUT, 
500).V().out("knows").toList()}} 
 should be replaced by
 {{ List vertices = g.with(Tokens.ARGS_EVAL_TIMEOUT, 
500L).V().out("knows").toList()}}

 Note: a Long should be 

This option is only documented in upgrade guide, it could be useful to document 
all options in main documentation.

  was:
in  the file {{docs/src/upgrade/release-3.4.x.asciidoc}} the sentence
 {{ List vertices = g.with(RemoteConnection.PER_REQUEST_TIMEOUT, 
500).V().out("knows").toList()}} 
 should be replaced by
 {{ List vertices = g.with(Tokens.ARGS_EVAL_TIMEOUT, 
500).V().out("knows").toList()}}

 

This option is only documented in upgrade guide, it could be useful to document 
all options in main documentation.


> In upgrade guide for 3.4.2, the option RemoteConnection.PER_REQUEST_TIMEOUT 
> does not exist
> --
>
> Key: TINKERPOP-2337
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2337
> Project: TinkerPop
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 3.4.2, 3.4.3, 3.4.4, 3.4.5
>Reporter: Nicolas Trangosi
>Priority: Minor
>
> in  the file {{docs/src/upgrade/release-3.4.x.asciidoc}} the sentence
>  {{ List vertices = g.with(RemoteConnection.PER_REQUEST_TIMEOUT, 
> 500).V().out("knows").toList()}} 
>  should be replaced by
>  {{ List vertices = g.with(Tokens.ARGS_EVAL_TIMEOUT, 
> 500L).V().out("knows").toList()}}
>  Note: a Long should be 
> This option is only documented in upgrade guide, it could be useful to 
> document all options in main documentation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (TINKERPOP-2337) In upgrade guide for 3.4.2, the option RemoteConnection.PER_REQUEST_TIMEOUT does not exist

2020-02-12 Thread Nicolas Trangosi (Jira)


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

Nicolas Trangosi updated TINKERPOP-2337:

Description: 
in  the file {{docs/src/upgrade/release-3.4.x.asciidoc}} the sentence
 {{ List vertices = g.with(RemoteConnection.PER_REQUEST_TIMEOUT, 
500).V().out("knows").toList()}} 
 should be replaced by
 {{ List vertices = g.with(Tokens.ARGS_EVAL_TIMEOUT, 
500L).V().out("knows").toList()}}

 Note: a Long should be used as argument instead of an integer else the 
following exception is thrown:
{noformat}
java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long
at 
org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteConnection.getRequestOptions(DriverRemoteConnection.java:238)
at 
org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteConnection.submitAsync(DriverRemoteConnection.java:225)
at 
org.apache.tinkerpop.gremlin.process.remote.traversal.step.map.RemoteStep.promise(RemoteStep.java:89)
at 
org.apache.tinkerpop.gremlin.process.remote.traversal.step.map.RemoteStep.processNextStart(RemoteStep.java:65)
at 
org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:128)
at 
org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:38)
at 
org.apache.tinkerpop.gremlin.process.traversal.Traversal.fill(Traversal.java:180)
at 
org.apache.tinkerpop.gremlin.process.traversal.Traversal.toList(Traversal.java:118)
{noformat}



This option is only documented in upgrade guide, it could be useful to document 
all options in main documentation.

  was:
in  the file {{docs/src/upgrade/release-3.4.x.asciidoc}} the sentence
 {{ List vertices = g.with(RemoteConnection.PER_REQUEST_TIMEOUT, 
500).V().out("knows").toList()}} 
 should be replaced by
 {{ List vertices = g.with(Tokens.ARGS_EVAL_TIMEOUT, 
500L).V().out("knows").toList()}}

 Note: a Long should be 

This option is only documented in upgrade guide, it could be useful to document 
all options in main documentation.


> In upgrade guide for 3.4.2, the option RemoteConnection.PER_REQUEST_TIMEOUT 
> does not exist
> --
>
> Key: TINKERPOP-2337
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2337
> Project: TinkerPop
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 3.4.2, 3.4.3, 3.4.4, 3.4.5
>Reporter: Nicolas Trangosi
>Priority: Minor
>
> in  the file {{docs/src/upgrade/release-3.4.x.asciidoc}} the sentence
>  {{ List vertices = g.with(RemoteConnection.PER_REQUEST_TIMEOUT, 
> 500).V().out("knows").toList()}} 
>  should be replaced by
>  {{ List vertices = g.with(Tokens.ARGS_EVAL_TIMEOUT, 
> 500L).V().out("knows").toList()}}
>  Note: a Long should be used as argument instead of an integer else the 
> following exception is thrown:
> {noformat}
> java.lang.ClassCastException: java.lang.Integer cannot be cast to 
> java.lang.Long
> at 
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteConnection.getRequestOptions(DriverRemoteConnection.java:238)
> at 
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteConnection.submitAsync(DriverRemoteConnection.java:225)
> at 
> org.apache.tinkerpop.gremlin.process.remote.traversal.step.map.RemoteStep.promise(RemoteStep.java:89)
> at 
> org.apache.tinkerpop.gremlin.process.remote.traversal.step.map.RemoteStep.processNextStart(RemoteStep.java:65)
> at 
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:128)
> at 
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:38)
> at 
> org.apache.tinkerpop.gremlin.process.traversal.Traversal.fill(Traversal.java:180)
> at 
> org.apache.tinkerpop.gremlin.process.traversal.Traversal.toList(Traversal.java:118)
> {noformat}
> This option is only documented in upgrade guide, it could be useful to 
> document all options in main documentation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (TINKERPOP-2338) drop() not removing all edge/meta properties

2020-02-12 Thread Stephen Mallette (Jira)


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

Stephen Mallette updated TINKERPOP-2338:

Issue Type: Bug  (was: Improvement)

> drop() not removing all edge/meta properties
> 
>
> Key: TINKERPOP-2338
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2338
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.4.5
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Critical
>
> From Gremlin Users:
> https://groups.google.com/d/msg/gremlin-users/wB0a9uP98Zw/zoZrNk8GFwAJ
> {code}
> gremlin> g.E().property("myprop", true).iterate()
> gremlin> g.E().has("myprop").count().next()
> ==>6
> gremlin> g.E().properties("myprop").drop().iterate()
> gremlin> g.E().has("myprop").count().next()
> ==>5
> {code}
> Obviously, all "myprop" should get removed. The issue has to do with property 
> equality from:
> http://tinkerpop.apache.org/docs/3.4.5/upgrade/#_properties_equality
> and {{LazyBarrierStrategy}} which bulks and yields just one property for 
> {{drop()}}:
> {code}
> gremlin> 
> g.withoutStrategies(LazyBarrierStrategy).E().properties("myprop").drop()
> gremlin> g.E().has("myprop").count().next()
> ==>0
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (TINKERPOP-2338) drop() not removing all edge/meta properties

2020-02-12 Thread Stephen Mallette (Jira)
Stephen Mallette created TINKERPOP-2338:
---

 Summary: drop() not removing all edge/meta properties
 Key: TINKERPOP-2338
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2338
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.4.5
Reporter: Stephen Mallette
Assignee: Stephen Mallette


>From Gremlin Users:

https://groups.google.com/d/msg/gremlin-users/wB0a9uP98Zw/zoZrNk8GFwAJ

{code}
gremlin> g.E().property("myprop", true).iterate()
gremlin> g.E().has("myprop").count().next()
==>6
gremlin> g.E().properties("myprop").drop().iterate()
gremlin> g.E().has("myprop").count().next()
==>5
{code}

Obviously, all "myprop" should get removed. The issue has to do with property 
equality from:

http://tinkerpop.apache.org/docs/3.4.5/upgrade/#_properties_equality

and {{LazyBarrierStrategy}} which bulks and yields just one property for 
{{drop()}}:

{code}
gremlin> 
g.withoutStrategies(LazyBarrierStrategy).E().properties("myprop").drop()
gremlin> g.E().has("myprop").count().next()
==>0
{code}





--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [tinkerpop] jorgebay commented on issue #1243: js: add session connection

2020-02-12 Thread GitHub
Thanks @heljoyLiu for the patch.

Sorry I didn't have time to review it yet, I'll do it this week.

[ Full content available at: https://github.com/apache/tinkerpop/pull/1243 ]
This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org


[jira] [Commented] (TINKERPOP-2192) Gremlin.Net.Driver.Connection.Parse throws a NullReferenceException

2020-02-12 Thread Dzmitry L (Jira)


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

Dzmitry L commented on TINKERPOP-2192:
--

Hi, any updates here? From time to time I'm facing same exception.

v 3.4.4
{code:java}
System.NullReferenceException: Object reference not set to an instance of an 
object. at Gremlin.Net.Driver.Connection.Parse(Byte[] received) at 
Gremlin.Net.Driver.Connection.ReceiveMessagesAsync() at 
Gremlin.Net.Driver.ProxyConnection.SubmitAsync[T](RequestMessage 
requestMessage) at 
Gremlin.Net.Driver.GremlinClient.SubmitAsync[T](RequestMessage requestMessage) 
at Gremlin.Net.Driver.GremlinClientExtensions.SubmitAsync[T](IGremlinClient 
gremlinClient, String requestScript, Dictionary`2 bindings){code}

> Gremlin.Net.Driver.Connection.Parse throws a NullReferenceException
> ---
>
> Key: TINKERPOP-2192
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2192
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet
>Affects Versions: 3.4.1
>Reporter: Florian Hockmann
>Priority: Minor
>
> The Parse method has only three objects on which we call methods of which two 
> are {{readonly}}. So the problem is most likely in the error handling:
> {code}
> if (_callbackByRequestId.TryRemove(receivedMsg.RequestId, out var 
> responseHandler))
>  {
>  responseHandler.HandleFailure(e);
> }
>  {code}
> Here, {{responseHandler}} can be null if the callback handler for that 
> request id was not found. So we just need a null check. (We can't notify 
> anyone about a failure any way in this case.)
> Stack trace:
> {code}
> System.NullReferenceException: Object reference not set to an instance of an 
> object.
>at Gremlin.Net.Driver.Connection.Parse(Byte[] received)
>at Gremlin.Net.Driver.Connection.ReceiveMessagesAsync()
>at Gremlin.Net.Driver.ProxyConnection.SubmitAsync[T](RequestMessage 
> requestMessage)
>at Gremlin.Net.Driver.GremlinClient.SubmitAsync[T](RequestMessage 
> requestMessage)
>at 
> Gremlin.Net.Driver.Remote.DriverRemoteConnection.SubmitBytecodeAsync(Guid 
> requestid, Bytecode bytecode)
>at 
> Gremlin.Net.Driver.Remote.DriverRemoteConnection.SubmitAsync[S,E](Bytecode 
> bytecode)
>at Gremlin.Net.Process.Remote.RemoteStrategy.ApplyAsync[S,E](ITraversal`2 
> traversal)
>at Gremlin.Net.Process.Traversal.DefaultTraversal`2.ApplyStrategiesAsync()
>at 
> Gremlin.Net.Process.Traversal.DefaultTraversal`2.Promise[TReturn](Func`2 
> callback)
>  {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (TINKERPOP-2019) Gremlin.Net.Driver.WebSocketConnection throws System.InvalidOperationException

2020-02-12 Thread Dzmitry L (Jira)


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

Dzmitry L commented on TINKERPOP-2019:
--

Hi. I've got same exception using v 3.4.4 on .net core 3.1. App spins in a 
docker container based on

mcr.microsoft.com{color:#ff}/{color}dotnet{color:#ff}/{color}core{color:#ff}/{color}sdk:3.1
 image.
{code:java}
System.InvalidOperationException: There is already one outstanding 
'ReceiveAsync' call for this WebSocket instance. ReceiveAsync and SendAsync can 
be called simultaneously, but at most one outstanding operation for each of 
them is allowed at the same time. at 
System.Net.WebSockets.ManagedWebSocket.ThrowOperationInProgress(String 
methodName) at 
System.Net.WebSockets.ManagedWebSocket.ReceiveAsync(ArraySegment`1 buffer, 
CancellationToken cancellationToken) --- End of stack trace from previous 
location where exception was thrown --- {code}

> Gremlin.Net.Driver.WebSocketConnection throws System.InvalidOperationException
> --
>
> Key: TINKERPOP-2019
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2019
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet
>Affects Versions: 3.3.3
> Environment: Azure App Service
>Reporter: Sami
>Priority: Critical
>
> We're getting the following {{System.InvalidOperationException}} error 
> message:
> {code:c#}
> "There is already one outstanding 'SendAsync' call for this WebSocket 
> instance. ReceiveAsync and SendAsync can be called simultaneously, but at 
> most one outstanding operation for each of them is allowed at the same time.
> Problem Id:
> System.InvalidOperationException at 
> Gremlin.Net.Driver.WebSocketConnection+d__5.MoveNext"{code}
>  
>  We get this exception sporadically and only a few times out of thousands. 
> Unfortunately we have not been able to reproduce it.
>   
>  I understand that when dealing with web sockets, it is allowed to have only 
> a single pending "send" or a single pending "receive".
>   
>  After looking at GitHub's WebSocketConnection class, I don't see any 
> orchestration between SendMessageAsync's {{_client.SendAsync}} (currently 
> line 54) and ReceiveMessageAsync's {{_client.ReceiveAsync}} (currently line 
> 66). 
>   
>  Reference Link: 
>  
> [https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Driver/WebSocketConnection.cs]
>   
>  I'm wondering if not having orchestration in the WebSocketConnection class 
> to keep the single pending "send" or a single pending "receive" rule may be 
> the cause. 
>   
>  In our .NET Core web api application, we create the GremlinConnection as a 
> singleton in Startup.cs and then have one central call that makes Gremlin 
> calls; i.e. it's a very straightforward implementation.
>   
>  Startup.cs:
> {code:c#}
> public void ConfigureServices(IServiceCollection services)
> {
> //...other stuff removed for brevity
> services.AddSingleton();
> }{code}
>  
>  Reader.cs:
> {code:c#}
> public async Task> ExecuteGremlinQuery(string 
> query)
> {
> try
> {
> return await _gremlinConnection.Client.SubmitAsync(query);
> }
> catch (Gremlin.Net.Driver.Exceptions.ResponseException responseException)
> {
> //our error handling removed for brevity!
> }
> }{code}
>   
>  We use the Gremlin.Net version 3.3.3 nuget package and the 
> Microsoft.NETCore.App SDK
>   
>  Would it be possible to identify if this is indeed a bug on Gremlin.NET? 
>  And if it is, any thoughts on a best-practice (temporary) work-around that 
> we can implement?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (TINKERPOP-2338) drop() not removing all edge/meta properties

2020-02-12 Thread Stephen Mallette (Jira)


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

Stephen Mallette commented on TINKERPOP-2338:
-

Tried a few solutions to this one but nothing quite worked right. [~dkuppitz] 
seemed to agree with me that this issue is only a problem with {{drop()}} in 
place so after some thought decided to change {{LazyBarrierStrategy}} to not be 
applied when that step is present. Added some tests to try to make sure there 
aren't regressions. 

> drop() not removing all edge/meta properties
> 
>
> Key: TINKERPOP-2338
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2338
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.4.5
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Critical
>
> From Gremlin Users:
> https://groups.google.com/d/msg/gremlin-users/wB0a9uP98Zw/zoZrNk8GFwAJ
> {code}
> gremlin> g.E().property("myprop", true).iterate()
> gremlin> g.E().has("myprop").count().next()
> ==>6
> gremlin> g.E().properties("myprop").drop().iterate()
> gremlin> g.E().has("myprop").count().next()
> ==>5
> {code}
> Obviously, all "myprop" should get removed. The issue has to do with property 
> equality from:
> http://tinkerpop.apache.org/docs/3.4.5/upgrade/#_properties_equality
> and {{LazyBarrierStrategy}} which bulks and yields just one property for 
> {{drop()}}:
> {code}
> gremlin> 
> g.withoutStrategies(LazyBarrierStrategy).E().properties("myprop").drop()
> gremlin> g.E().has("myprop").count().next()
> ==>0
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[DISCUSS] release 3.4.6

2020-02-12 Thread Stephen Mallette
To my recollection we haven't released with a bug that made me think about
immediately re-releasing a patch since 2011, but it looks like 3.4.5 has
something not so nice in it. It was brought to light on gremlin-users today
and I created this JIRA for it:

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

While the bug has a workaround it's not nice and existing Gremlin matching
that pattern will immediately stop behaving properly on upgrade. Given that
the bug is related to graph mutations I find that a bit high on the
worrisome scale.

I suppose the good news is that we learned about the problem quickly before
a ton of new code went to 3.4-dev and there is a fix that is surgical and
touches very little code. So, we could reasonably get this change through
review, merge it to 3.4-dev, create 3.4.6 artifacts and prepare for VOTE. I
don't see the need for a week long code freeze - we just skip to release
VOTE.

So, I suppose the points for discussion here are:

1. Is the bug bad enough to warrant an immediate release of 3.4.6 (note
3.3.11 is unaffected)?
2. If so, are we good with a quick review/merge and an immediate build of a
3.4.6 artifact for VOTE or should we perhaps take a bit more time to see if
other bad news comes in?