[jira] [Updated] (TINKERPOP-3106) Update to Docker Compose V2
[
https://issues.apache.org/jira/browse/TINKERPOP-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann updated TINKERPOP-3106:
Description:
Docker Compose V1 has been deprecated in 2023:
[https://docs.docker.com/compose/migrate/]
We are however still using it which now results in our GLV tests failing in
GitHub Actions as they [have stopped supported
it|https://github.blog/changelog/2024-04-10-github-hosted-runner-images-deprecation-notice-docker-compose-v1/].
The biggest change between V1 and V2 is that it's now {{docker compose}}
instead of {{{}docker-compose{}}}. Maybe it's already enough if we simply make
that change.
was:
Docker Compose V1 has been deprecated in 2023:
[https://docs.docker.com/compose/migrate/]
We are however still using it which now results in our GLV tests failing in
GitHub Actions as they [have stopped supported
it|https://discord.com/channels/838910279550238720/1131259898496294973/1275808802243088437].
The biggest change between V1 and V2 is that it's now {{docker compose}}
instead of {{{}docker-compose{}}}. Maybe it's already enough if we simply make
that change.
> Update to Docker Compose V2
> ---
>
> Key: TINKERPOP-3106
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3106
> Project: TinkerPop
> Issue Type: Task
> Components: dotnet, go, javascript, python
>Reporter: Florian Hockmann
>Priority: Major
>
> Docker Compose V1 has been deprecated in 2023:
> [https://docs.docker.com/compose/migrate/]
> We are however still using it which now results in our GLV tests failing in
> GitHub Actions as they [have stopped supported
> it|https://github.blog/changelog/2024-04-10-github-hosted-runner-images-deprecation-notice-docker-compose-v1/].
> The biggest change between V1 and V2 is that it's now {{docker compose}}
> instead of {{{}docker-compose{}}}. Maybe it's already enough if we simply
> make that change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-3106) Update to Docker Compose V2
Florian Hockmann created TINKERPOP-3106:
---
Summary: Update to Docker Compose V2
Key: TINKERPOP-3106
URL: https://issues.apache.org/jira/browse/TINKERPOP-3106
Project: TinkerPop
Issue Type: Task
Components: dotnet, go, javascript, python
Reporter: Florian Hockmann
Docker Compose V1 has been deprecated in 2023:
[https://docs.docker.com/compose/migrate/]
We are however still using it which now results in our GLV tests failing in
GitHub Actions as they [have stopped supported
it|https://discord.com/channels/838910279550238720/1131259898496294973/1275808802243088437].
The biggest change between V1 and V2 is that it's now {{docker compose}}
instead of {{{}docker-compose{}}}. Maybe it's already enough if we simply make
that change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-3035) Add explicit property(IDictionary) for .NET
[
https://issues.apache.org/jira/browse/TINKERPOP-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-3035.
---
Fix Version/s: 3.6.8
3.7.3
Assignee: Florian Hockmann
Resolution: Fixed
> Add explicit property(IDictionary) for .NET
> ---
>
> Key: TINKERPOP-3035
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3035
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.6.6
>Reporter: Stephen Mallette
>Assignee: Florian Hockmann
>Priority: Minor
> Fix For: 3.6.8, 3.7.3
>
>
> There is no {{property(IDictionary)}} method for .NET to
> accompany the {{property(Map)}} step. It works because it probably piggybacks
> on {{property(object?, object?, objects[]?)}} which has all nullable
> arguments. The explicit overload with the {{IDictionary}} should be added.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-3072) Gremlin.Net Traversal enumeration error if element does not exist on .NET 8
[
https://issues.apache.org/jira/browse/TINKERPOP-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840050#comment-17840050
]
Florian Hockmann commented on TINKERPOP-3072:
-
I just checked how Gremlin-Python behaves in this scenario and it also throws
an exception which is very similar to the behavior we now have with .NET 8:
{code:python}
>>> g.V().has('name','doesnotexist').next()
Traceback (most recent call last):
File "", line 1, in
File "[...]\site-packages\gremlin_python\process\traversal.py", line 117, in
next
return self.__next__()
^^^
File "[...]\site-packages\gremlin_python\process\traversal.py", line 50, in
__next__
self.last_traverser = next(self.traversers)
^
StopIteration{code}
So, I think we should really also throw an exception for this scenario in .NET
to be consistent across GLVs. The downside is of course that this is a breaking
change, but only for users on .NET versions earlier than .NET 8 which is the
current LTS version.
I'll start a thread on the dev list to discuss how we want to deal with this as
we could either add the breaking change already on 3.6.8 / 3.7.3 or wait for
3.8.0.
> Gremlin.Net Traversal enumeration error if element does not exist on .NET 8
> ---
>
> Key: TINKERPOP-3072
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3072
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.6.7, 3.7.2
>Reporter: Florian Hockmann
>Priority: Major
>
> Similar to TINKERPOP-3029, one can unfortunately still get traversal
> enumeration errors on .NET 8 with Gremlin.Net if {{Next()}} is called when
> there is no element.
> Example:
> {code:java}
> g.V().Has("Name", "doesnotexist").Next(); {code}
> This will throw the following error:
> {code:java}
> System.InvalidOperationException: Enumeration already finished. {code}
> With .NET versions earlier than .NET 8, we simply got {{null}} back here
> instead of the exception.
> I am not sure what the correct behavior here is. The same traversal throws a
> {{NoSuchElementException}} with Gremlin-Java:
> {code:java}
> gremlin> g.V().has('name','doesnotexist').next()
> java.util.NoSuchElementException{code}
> I think Gremlin.Net should either throw a similar exception which clearly
> states the problem (instead of the {{InvalidOperationException}} which looks
> like a bug) or return {{{}null{}}}, but it should definitely do that
> consistently, irrespective of the version of .NET. If we decide on throwing
> an exception in this case, then users probably have to change their code to
> always check for element existence first via {{{}HasNext(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-3072) Gremlin.Net Traversal enumeration error if element does not exist on .NET 8
Florian Hockmann created TINKERPOP-3072:
---
Summary: Gremlin.Net Traversal enumeration error if element does
not exist on .NET 8
Key: TINKERPOP-3072
URL: https://issues.apache.org/jira/browse/TINKERPOP-3072
Project: TinkerPop
Issue Type: Bug
Components: dotnet
Affects Versions: 3.7.2, 3.6.7
Reporter: Florian Hockmann
Similar to TINKERPOP-3029, one can unfortunately still get traversal
enumeration errors on .NET 8 with Gremlin.Net if {{Next()}} is called when
there is no element.
Example:
{code:java}
g.V().Has("Name", "doesnotexist").Next(); {code}
This will throw the following error:
{code:java}
System.InvalidOperationException: Enumeration already finished. {code}
With .NET versions earlier than .NET 8, we simply got {{null}} back here
instead of the exception.
I am not sure what the correct behavior here is. The same traversal throws a
{{NoSuchElementException}} with Gremlin-Java:
{code:java}
gremlin> g.V().has('name','doesnotexist').next()
java.util.NoSuchElementException{code}
I think Gremlin.Net should either throw a similar exception which clearly
states the problem (instead of the {{InvalidOperationException}} which looks
like a bug) or return {{{}null{}}}, but it should definitely do that
consistently, irrespective of the version of .NET. If we decide on throwing an
exception in this case, then users probably have to change their code to always
check for element existence first via {{{}HasNext(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2987) "Has (Traversal Step)" and datetime() function
[
https://issues.apache.org/jira/browse/TINKERPOP-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838183#comment-17838183
]
Florian Hockmann commented on TINKERPOP-2987:
-
Sorry for the late reply, I somehow didn't see this issue until now.
Did you try to use {{DateTimeOffset}} in .NET for this property key?
Gremlin.Net should serialize {{DateTimeOffset}} so it can be used by the server
(JanusGraph Server in your case) as a Java {{Date}} and deserialize a {{Date}}
coming from the server as a {{DateTimeOffset}} in .Net.
For the Console: I think the usual behavior is that you need to use a {{Date}}
object or the {{datetime()}} function which is just a convenience function to
make working with dates easier. I guess it worked with just a {{string}} when
you created the vertex as JanusGraph automatically converted it to a {{Date}}
as it inferred the type from your schema.
> "Has (Traversal Step)" and datetime() function
> --
>
> Key: TINKERPOP-2987
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2987
> Project: TinkerPop
> Issue Type: Bug
> Components: console, dotnet
>Affects Versions: 3.5.5
> Environment: Windows 10
> TinkerPop 3.5.5
> JanusGraph 0.6.3
> Berkeley JE
>Reporter: Kensuke Ishihara
>Priority: Major
> Labels: bug
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> I created a vertex which has a date property. (I defined a schema and enabled
> schema constraints according to [Schema and Data Modeling -
> JanusGraph|https://docs.janusgraph.org/schema/].)
>
> When I wrote a query on Gremlin Console like below, it works. I mean, it is
> not necessary to use datetime() function.
> g.V().has("labelName", "propertyName", "2018-04-01T00:00:00").valueMap()
>
> But, if I accessed same vertex via another vertex, then I need datetime()
> function.
> g.V().has("anotherLabelName", "anotherPropertyName",
> "someValue").out().has("labelName", "propertyName",
> datetime("2018-04-01T00:00:00")).valueMap()
> If I didn't use datetime(), no vertex is returned.
>
> Same problem occurs on Gremlin.Net. In .Net, -.ToUniversalTime() method is
> needed at latter case- I have not found a workaround.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-3063) Concurrent queries will break authentication on .NET driver
[
https://issues.apache.org/jira/browse/TINKERPOP-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17835174#comment-17835174
]
Florian Hockmann commented on TINKERPOP-3063:
-
Yes, sure. I think this is a duplicate of TINKERPOP-3061 so I'll close it as
such.
No need to also fix this for 3.6 in my opinion, especially not just for .NET
where most users just use the latest release any way.
> Concurrent queries will break authentication on .NET driver
> ---
>
> Key: TINKERPOP-3063
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3063
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.6.6, 3.7.1
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
>
> Executing multiple queries in parallel can lead to authentication failures if
> {{MaxInProcessPerConnection}} is set to a value higher than {{1}} as the
> second request can then be send to the server while the server is still
> waiting for the authentication challenge response from the driver for the
> first query.
> A simple workaround is to set {{MaxInProcessPerConnection=1}} but this means
> of course that connection pooling will be less efficient.
> This issue also exists for other drivers:
> * Java: TINKERPOP-2132
> * JS: TINKERPOP-3061
> (I don't know about the Python and Go drivers.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-3063) Concurrent queries will break authentication on .NET driver
[
https://issues.apache.org/jira/browse/TINKERPOP-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-3063.
---
Resolution: Duplicate
> Concurrent queries will break authentication on .NET driver
> ---
>
> Key: TINKERPOP-3063
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3063
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.6.6, 3.7.1
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
>
> Executing multiple queries in parallel can lead to authentication failures if
> {{MaxInProcessPerConnection}} is set to a value higher than {{1}} as the
> second request can then be send to the server while the server is still
> waiting for the authentication challenge response from the driver for the
> first query.
> A simple workaround is to set {{MaxInProcessPerConnection=1}} but this means
> of course that connection pooling will be less efficient.
> This issue also exists for other drivers:
> * Java: TINKERPOP-2132
> * JS: TINKERPOP-3061
> (I don't know about the Python and Go drivers.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-3066) Different behaviors when adding "dedup()"
[
https://issues.apache.org/jira/browse/TINKERPOP-3066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-3066.
---
Resolution: Not A Problem
I'm closing this as its mostly a usage question for now and you also asked this
on the users mailing list which is a better place to discuss this question and
determine whether this is actually expected behavior or a bug:
https://groups.google.com/g/gremlin-users/c/Hnjp8UqJ2RU
If it's indeed a bug, then we can still create an issue here and provide a
clear description of what the expected behavior is vs the actual behavior.
> Different behaviors when adding "dedup()"
> -
>
> Key: TINKERPOP-3066
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3066
> Project: TinkerPop
> Issue Type: Bug
> Components: gremlint
>Affects Versions: 3.7.0
> Environment: Windows 10
>Reporter: Junhao lan
>Priority: Major
>
> I think the traversal is really weird.
> * first traversal: {{g.addV().addV().limit(0)}} -> creates 1 vertex
> * second traversal: {{g.addV().addV().dedup().limit(0)}} -> creates 2
> vertices
> And {{limit(0)}} is also strange and I don't really know what the expected
> behavior should be here with Gremlin.Maybe there is a bug?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-3061) Concurrent queries will break authentication on javascript driver
[
https://issues.apache.org/jira/browse/TINKERPOP-3061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827491#comment-17827491
]
Florian Hockmann commented on TINKERPOP-3061:
-
bq. for gremlin-server. Which I think maybe a better place for this kind of fix?
If we can solve this in the server somehow than that would be better of course.
But I'm not sure whether that's possible without requiring bigger changes to
the protocol itself.
The change for the driver is to simply submit a request on each connection
before users get the connection. This initial request will then trigger the
authentication mechanism. Afterwards users can directly submit multiple
requests in parallel over the connection as authentication already happened.
> Concurrent queries will break authentication on javascript driver
> -
>
> Key: TINKERPOP-3061
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3061
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.6.6, 3.7.1
>Reporter: Yang Xia
>Priority: Major
>
> Reported by tien on Discord:
> {code:java}
> import gremlin from "gremlin";
> const g = gremlin.process.AnonymousTraversalSource.traversal().withRemote(
> new gremlin.driver.DriverRemoteConnection("ws://localhost:8182/gremlin", {
> authenticator: new gremlin.driver.auth.PlainTextSaslAuthenticator(
> "admin",
> "administrator"
> ),
> })
> );
> // This will throws: Failed to authenticate (401)
> await Promise.all([g.V().toList(), g.V().toList()]);
> // This works as expected
> await g.V().toList();
> await g.V().toList(); {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-3061) Concurrent queries will break authentication on javascript driver
[
https://issues.apache.org/jira/browse/TINKERPOP-3061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17826074#comment-17826074
]
Florian Hockmann commented on TINKERPOP-3061:
-
TINKERPOP-2132 was only about the Java driver and the PR you are mentioning
therefore also only tried to fix it for that driver. This issue however is
about the JS driver and we don't have a PR ready for that.
I just created TINKERPOP-3063 for the same issue in the .NET driver. Since I am
mostly experienced in that driver, I'll submit a PR to fix it there. If that
fix however gets accepted and merged then we can probably afterwards also see
whether a similar fix also makes sense for the other drivers, like the JS one.
> Concurrent queries will break authentication on javascript driver
> -
>
> Key: TINKERPOP-3061
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3061
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.6.6, 3.7.1
>Reporter: Yang Xia
>Priority: Major
>
> Reported by tien on Discord:
> {code:java}
> import gremlin from "gremlin";
> const g = gremlin.process.AnonymousTraversalSource.traversal().withRemote(
> new gremlin.driver.DriverRemoteConnection("ws://localhost:8182/gremlin", {
> authenticator: new gremlin.driver.auth.PlainTextSaslAuthenticator(
> "admin",
> "administrator"
> ),
> })
> );
> // This will throws: Failed to authenticate (401)
> await Promise.all([g.V().toList(), g.V().toList()]);
> // This works as expected
> await g.V().toList();
> await g.V().toList(); {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-3063) Concurrent queries will break authentication on .NET driver
[
https://issues.apache.org/jira/browse/TINKERPOP-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17826071#comment-17826071
]
Florian Hockmann commented on TINKERPOP-3063:
-
I think we can simply solve this by submitting a validation request on each
connection right after establishing the connection and therefore before it can
be used to submit queries from the user. I'll submit a PR with such a solution.
> Concurrent queries will break authentication on .NET driver
> ---
>
> Key: TINKERPOP-3063
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3063
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.6.6, 3.7.1
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
>
> Executing multiple queries in parallel can lead to authentication failures if
> {{MaxInProcessPerConnection}} is set to a value higher than {{1}} as the
> second request can then be send to the server while the server is still
> waiting for the authentication challenge response from the driver for the
> first query.
> A simple workaround is to set {{MaxInProcessPerConnection=1}} but this means
> of course that connection pooling will be less efficient.
> This issue also exists for other drivers:
> * Java: TINKERPOP-2132
> * JS: TINKERPOP-3061
> (I don't know about the Python and Go drivers.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-3063) Concurrent queries will break authentication on .NET driver
Florian Hockmann created TINKERPOP-3063:
---
Summary: Concurrent queries will break authentication on .NET
driver
Key: TINKERPOP-3063
URL: https://issues.apache.org/jira/browse/TINKERPOP-3063
Project: TinkerPop
Issue Type: Bug
Components: dotnet
Affects Versions: 3.7.1, 3.6.6
Reporter: Florian Hockmann
Assignee: Florian Hockmann
Executing multiple queries in parallel can lead to authentication failures if
{{MaxInProcessPerConnection}} is set to a value higher than {{1}} as the second
request can then be send to the server while the server is still waiting for
the authentication challenge response from the driver for the first query.
A simple workaround is to set {{MaxInProcessPerConnection=1}} but this means of
course that connection pooling will be less efficient.
This issue also exists for other drivers:
* Java: TINKERPOP-2132
* JS: TINKERPOP-3061
(I don't know about the Python and Go drivers.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-3061) Concurrent queries will break authentication on javascript driver
[
https://issues.apache.org/jira/browse/TINKERPOP-3061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824291#comment-17824291
]
Florian Hockmann commented on TINKERPOP-3061:
-
I think this is a general problem of the way we handle authentication,
irrespective of the language being used. TINKERPOP-2132 discusses the same
problem for the Java driver and I know that it also exists for the .NET driver.
> Concurrent queries will break authentication on javascript driver
> -
>
> Key: TINKERPOP-3061
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3061
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.6.6, 3.7.1
>Reporter: Yang Xia
>Priority: Major
>
> Reported by tien on Discord:
> {code:java}
> import gremlin from "gremlin";
> const g = gremlin.process.AnonymousTraversalSource.traversal().withRemote(
> new gremlin.driver.DriverRemoteConnection("ws://localhost:8182/gremlin", {
> authenticator: new gremlin.driver.auth.PlainTextSaslAuthenticator(
> "admin",
> "administrator"
> ),
> })
> );
> // This will throws: Failed to authenticate (401)
> await Promise.all([g.V().toList(), g.V().toList()]);
> // This works as expected
> await g.V().toList();
> await g.V().toList(); {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-3030) Update to .NET 8
[ https://issues.apache.org/jira/browse/TINKERPOP-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann closed TINKERPOP-3030. --- Fix Version/s: 4.0.0 3.6.7 3.7.2 Resolution: Fixed > Update to .NET 8 > > > Key: TINKERPOP-3030 > URL: https://issues.apache.org/jira/browse/TINKERPOP-3030 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.5.8, 3.6.6, 3.7.1 >Reporter: Florian Hockmann >Assignee: Florian Hockmann >Priority: Blocker > Fix For: 4.0.0, 3.6.7, 3.7.2 > > > .NET 8 is now the latest LTS release so we should update to it. > We need to do that on all release branches so contributors only need to have > one version of .NET installed on their systems. > This also means that we test by default with .NET 8 which would have shown > problems like the one described in TINKERPOP-3029. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (TINKERPOP-3030) Update to .NET 8
[ https://issues.apache.org/jira/browse/TINKERPOP-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann reassigned TINKERPOP-3030: --- Assignee: Florian Hockmann > Update to .NET 8 > > > Key: TINKERPOP-3030 > URL: https://issues.apache.org/jira/browse/TINKERPOP-3030 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.5.8, 3.6.6, 3.7.1 >Reporter: Florian Hockmann >Assignee: Florian Hockmann >Priority: Minor > > .NET 8 is now the latest LTS release so we should update to it. > We need to do that on all release branches so contributors only need to have > one version of .NET installed on their systems. > This also means that we test by default with .NET 8 which would have shown > problems like the one described in TINKERPOP-3029. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-3029) Gremlin.Net: Traversal enumeration fails on .NET 8
[
https://issues.apache.org/jira/browse/TINKERPOP-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-3029.
---
Fix Version/s: 3.6.7
3.7.2
Resolution: Fixed
> Gremlin.Net: Traversal enumeration fails on .NET 8
> --
>
> Key: TINKERPOP-3029
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3029
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.5.8, 3.6.6, 3.7.1
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Critical
> Fix For: 3.6.7, 3.7.2
>
>
> This has been reported by Eric Sites on the dev mailing list:
> [https://lists.apache.org/thread/snztwgk3s18h83mx8ql455hmx6ncl2r4]
>
> I am having a lot of issues using the Gremlin.Net driver version 3.7.1 with
> .Net 8.
> It is almost entirely unusable.
> Any request that uses an Iterator throws an exception ({{{}MoveNext{}}},
> {{{}Next{}}}, {{{}Iterate{}}}).
> {{{}System.InvalidOperationException: Enumeration has not started. Call
> MoveNext{}}}.
> Tracked it down to a change in .Net 8 {{IEnumerable.Current}} behavior.
> Here is an issue about this filed in dotnet runtime:
> [https://github.com/dotnet/runtime/issues/85243]
> New bad code:
> {code:java}
> var enumerator = saves.GetEnumerator();
> while (enumerator.Current == null) // <- Throws exception now
> {
>if (!enumerator.MoveNext())
> return list;
> }
> {code}
> Should be changed to something like this:
> {code:java}
> while (enumerator.MoveNext())
> {
> var item = enumerator.Current;
> }
> {code}
> Here is an example of the issue in the Gremlin.Net code:
> [https://github.com/apache/tinkerpop/blob/e8b9532fc0ec811460e97ebf5e00b8b9ec9192ac/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/DefaultTraversal.cs#L132]
> {code:java}
> private object? GetCurrent()
> {
> // Use dynamic to object to prevent runtime dynamic conversion evaluation
> return TraverserEnumerator.Current?.Object;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-3030) Update to .NET 8
Florian Hockmann created TINKERPOP-3030: --- Summary: Update to .NET 8 Key: TINKERPOP-3030 URL: https://issues.apache.org/jira/browse/TINKERPOP-3030 Project: TinkerPop Issue Type: Improvement Components: dotnet Affects Versions: 3.7.1, 3.6.6, 3.5.8 Reporter: Florian Hockmann .NET 8 is now the latest LTS release so we should update to it. We need to do that on all release branches so contributors only need to have one version of .NET installed on their systems. This also means that we test by default with .NET 8 which would have shown problems like the one described in TINKERPOP-3029. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TINKERPOP-3029) Gremlin.Net: Traversal enumeration fails on .NET 8
Florian Hockmann created TINKERPOP-3029:
---
Summary: Gremlin.Net: Traversal enumeration fails on .NET 8
Key: TINKERPOP-3029
URL: https://issues.apache.org/jira/browse/TINKERPOP-3029
Project: TinkerPop
Issue Type: Bug
Components: dotnet
Affects Versions: 3.7.1, 3.6.6, 3.5.8
Reporter: Florian Hockmann
Assignee: Florian Hockmann
This has been reported by Eric Sites on the dev mailing list:
[https://lists.apache.org/thread/snztwgk3s18h83mx8ql455hmx6ncl2r4]
I am having a lot of issues using the Gremlin.Net driver version 3.7.1 with
.Net 8.
It is almost entirely unusable.
Any request that uses an Iterator throws an exception ({{{}MoveNext{}}},
{{{}Next{}}}, {{{}Iterate{}}}).
{{{}System.InvalidOperationException: Enumeration has not started. Call
MoveNext{}}}.
Tracked it down to a change in .Net 8 {{IEnumerable.Current}} behavior. Here
is an issue about this filed in dotnet runtime:
[https://github.com/dotnet/runtime/issues/85243]
New bad code:
{code:java}
var enumerator = saves.GetEnumerator();
while (enumerator.Current == null) // <- Throws exception now
{
if (!enumerator.MoveNext())
return list;
}
{code}
Should be changed to something like this:
{code:java}
while (enumerator.MoveNext())
{
var item = enumerator.Current;
}
{code}
Here is an example of the issue in the Gremlin.Net code:
[https://github.com/apache/tinkerpop/blob/e8b9532fc0ec811460e97ebf5e00b8b9ec9192ac/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/DefaultTraversal.cs#L132]
{code:java}
private object? GetCurrent()
{
// Use dynamic to object to prevent runtime dynamic conversion evaluation
return TraverserEnumerator.Current?.Object;
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-3018) No Syntax Highlighting for .NET Examples
[
https://issues.apache.org/jira/browse/TINKERPOP-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17788679#comment-17788679
]
Florian Hockmann commented on TINKERPOP-3018:
-
Some C# examples however have at least basic syntax highlighting:
https://tinkerpop.apache.org/docs/current/reference/#gremlin-dotnet-connecting
One difference between examples for C# and the other languages is that we
include (most of) the C# [code examples from C# source
files|https://github.com/apache/tinkerpop/blob/master/docs/src/reference/intro.asciidoc#gremlin-server]:
{code}
link:../../../gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Docs/Reference/IntroTests.cs[]
{code}
I wonder whether the combination of including the code examples and using the
tabs features to display examples for different languages together results in
getting no syntax highlighting.
In general, I implemented this approach to include code examples in the docs
from source files to ensure that the examples continue to actually work, or at
least still compile, despite changes we make in some Gremlin steps or in the
.NET GLV. However, it's of course inconsistent to only to do this for
Gremlin.NET but not for the other GLVs, therefore adds complexity for
contributors and I don't know of any problems that we actually caught because
of this approach.
So, I'm also open to moving away from this approach and directly including the
C# examples in the asciidoc files.
> No Syntax Highlighting for .NET Examples
>
>
> Key: TINKERPOP-3018
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3018
> Project: TinkerPop
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 3.6.5
>Reporter: Cole Greer
>Priority: Minor
>
> In the reference docs, the C# code examples have no syntax highlighting. The
> code examples for all other GLV's have such highlighting. This can be seen in
> the examples here:
> https://tinkerpop.apache.org/docs/3.6.5/reference/#basic-gremlin.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2984) Replace Moq mocking library in .NET tests
[ https://issues.apache.org/jira/browse/TINKERPOP-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann closed TINKERPOP-2984. --- Fix Version/s: 3.5.8 3.6.6 3.7.1 4.0.0 Resolution: Fixed > Replace Moq mocking library in .NET tests > - > > Key: TINKERPOP-2984 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2984 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.7.0, 3.5.7, 3.6.5 >Reporter: Florian Hockmann >Assignee: Florian Hockmann >Priority: Major > Fix For: 3.5.8, 3.6.6, 3.7.1, 4.0.0 > > > There has been some controversy around the .NET mocking library that we are > also using in some of our .NET unit tests: Moq. > In short, a project called "SponsorLink" has been added as a DLL to the NuGet > package which sends a hash of the email address of the developer building the > project (meaning our unit test projects) to their server. The email address > is obtained from the git config. This was done to check whether the developer > is already sponsoring the Moq project and nag them otherwise to become a > sponsor. > This is of course a privacy issue and probably in violation of the GDPR. > [This > article|https://www.bleepingcomputer.com/news/security/popular-open-source-project-moq-criticized-for-quietly-collecting-data/] > contains a longer explanation. > While SponsorLink has already been removed again, the main author stated the > intent to bring it back at a later point after finding another way without > needing to send hashed email addresses. So, I think we should better switch > to a different mocking library, especially since the introduction of > SponsorLink was done without much (/any?) advance notification or warning. > We have by the way not been affected by this as we haven't updated Moq in our > repository to a version that included SponsorLink. > I suggest that we migrate to [NSubstitute|https://nsubstitute.github.io/] > which is another big mocking library with an even easier to use API (at least > in my opinion) and very similar capabilities. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TINKERPOP-3001) Gremlin Console complains about missing serializers field
Florian Hockmann created TINKERPOP-3001:
---
Summary: Gremlin Console complains about missing serializers field
Key: TINKERPOP-3001
URL: https://issues.apache.org/jira/browse/TINKERPOP-3001
Project: TinkerPop
Issue Type: Bug
Components: driver
Affects Versions: 3.6.5, 3.7.0
Reporter: Florian Hockmann
Gremlin Console logs a warning when I execute {{:remote connect
tinkerpop.server conf/remote.yaml}} (without changing that config file in any
way):
{code:java}
$ bin/gremlin.sh
\,,,/
(o o)
-oOOo-(3)-oOOo-
plugin activated: tinkerpop.server
plugin activated: tinkerpop.utilities
plugin activated: tinkerpop.tinkergraph
gremlin> :remote connect tinkerpop.server conf/remote.yaml
Oct 12, 2023 4:58:14 PM org.yaml.snakeyaml.internal.Logger warn
WARNING: Failed to find field for
org.apache.tinkerpop.gremlin.driver.Settings.serializers
==>Configured localhost/127.0.0.1:8182
{code}
It however still seems to work:
{code:java}
gremlin> :> 1+1
==>2
gremlin> :> g.V().count()
==>0
{code}
and the configured serializer from {{conf/remote.yaml}} is also used.
This was originally reported in the [JanusGraph issue
tracker|https://github.com/JanusGraph/janusgraph/issues/3979].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-2984) Replace Moq mocking library in .NET tests
Florian Hockmann created TINKERPOP-2984: --- Summary: Replace Moq mocking library in .NET tests Key: TINKERPOP-2984 URL: https://issues.apache.org/jira/browse/TINKERPOP-2984 Project: TinkerPop Issue Type: Improvement Components: dotnet Affects Versions: 3.6.5, 3.5.7, 3.7.0 Reporter: Florian Hockmann Assignee: Florian Hockmann There has been some controversy around the .NET mocking library that we are also using in some of our .NET unit tests: Moq. In short, a project called "SponsorLink" has been added as a DLL to the NuGet package which sends a hash of the email address of the developer building the project (meaning our unit test projects) to their server. The email address is obtained from the git config. This was done to check whether the developer is already sponsoring the Moq project and nag them otherwise to become a sponsor. This is of course a privacy issue and probably in violation of the GDPR. [This article|https://www.bleepingcomputer.com/news/security/popular-open-source-project-moq-criticized-for-quietly-collecting-data/] contains a longer explanation. While SponsorLink has already been removed again, the main author stated the intent to bring it back at a later point after finding another way without needing to send hashed email addresses. So, I think we should better switch to a different mocking library, especially since the introduction of SponsorLink was done without much (/any?) advance notification or warning. We have by the way not been affected by this as we haven't updated Moq in our repository to a version that included SponsorLink. I suggest that we migrate to [NSubstitute|https://nsubstitute.github.io/] which is another big mocking library with an even easier to use API (at least in my opinion) and very similar capabilities. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2976) InvalidOperationException: Collection was modified in GraphBinary serialization
[
https://issues.apache.org/jira/browse/TINKERPOP-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-2976.
---
Fix Version/s: 3.5.8
3.6.6
3.7.1
Resolution: Fixed
> InvalidOperationException: Collection was modified in GraphBinary
> serialization
> ---
>
> Key: TINKERPOP-2976
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2976
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.5.6, 3.6.4
>Reporter: Florian Hockmann
>Priority: Minor
> Fix For: 3.5.8, 3.6.6, 3.7.1
>
>
> This was first reported for JanusGraph.Net:
> [https://github.com/JanusGraph/janusgraph-dotnet/issues/140]
> but the issue is most likely in Gremlin.Net.
> {code:java}
> System.InvalidOperationException: Collection was modified; enumeration
> operation may not execute.
> at
> System.Collections.Generic.Dictionary2.KeyCollection.Enumerator.MoveNext()
> at
> Gremlin.Net.Structure.IO.GraphBinary.TypeSerializerRegistry.GetSerializerFor(Type
> valueType)
> at Gremlin.Net.Structure.IO.GraphBinary.GraphBinaryWriter.WriteAsync(Object
> value, Stream stream, CancellationToken cancellationToken)
> [...]{code}
> The problem is most likely that the driver iterates over all supported types
> in a {{foreach}} loop to find a type to which the type to be serialized can
> be assigned which means that the same serializer can be used. Then this
> serializer is registered for the new type which modifies the collection the
> {{foreach}} is iterated on, leading to this error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-2976) InvalidOperationException: Collection was modified in GraphBinary serialization
Florian Hockmann created TINKERPOP-2976:
---
Summary: InvalidOperationException: Collection was modified in
GraphBinary serialization
Key: TINKERPOP-2976
URL: https://issues.apache.org/jira/browse/TINKERPOP-2976
Project: TinkerPop
Issue Type: Bug
Components: dotnet
Affects Versions: 3.6.4, 3.5.6
Reporter: Florian Hockmann
This was first reported for JanusGraph.Net:
[https://github.com/JanusGraph/janusgraph-dotnet/issues/140]
but the issue is most likely in Gremlin.Net.
{code:java}
System.InvalidOperationException: Collection was modified; enumeration
operation may not execute.
at System.Collections.Generic.Dictionary2.KeyCollection.Enumerator.MoveNext()
at
Gremlin.Net.Structure.IO.GraphBinary.TypeSerializerRegistry.GetSerializerFor(Type
valueType)
at Gremlin.Net.Structure.IO.GraphBinary.GraphBinaryWriter.WriteAsync(Object
value, Stream stream, CancellationToken cancellationToken)
[...]{code}
The problem is most likely that the driver iterates over all supported types in
a {{foreach}} loop to find a type to which the type to be serialized can be
assigned which means that the same serializer can be used. Then this serializer
is registered for the new type which modifies the collection the {{foreach}} is
iterated on, leading to this error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2944) Memory leak in Gremlin.Net driver if CancellationToken is used
[
https://issues.apache.org/jira/browse/TINKERPOP-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-2944.
---
Fix Version/s: 3.7.0
3.5.7
3.6.4
Resolution: Fixed
> Memory leak in Gremlin.Net driver if CancellationToken is used
> --
>
> Key: TINKERPOP-2944
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2944
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.6.2, 3.5.5, 3.6.3, 3.5.6
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.7.0, 3.5.7, 3.6.4
>
>
> We have noticed in my team at G DATA that a .NET service has been using an
> increasing amount of memory since we began to propagate the
> {{CancellationToken}} into the Gremlin.Net traversal executions which was
> introduced in TINKERPOP-2794.
> We could track this down with memory profiling to [this place in the
> driver|https://github.com/apache/tinkerpop/blob/5c8af70c7fac3ee98df36d250b05320e67ff1b96/gremlin-dotnet/src/Gremlin.Net/Driver/Connection.cs#L94]
> where we register a callback to execute when cancellation is requested.
> These registered callbacks are only cleaned up when the whole {{Connection}}
> object gets disposed. Since the callback contains a reference to the full
> {{RequestMessage}} of the traversal, it can contain a lot of data. This is
> something that I've completely overlooked when I added support for
> cancellation.
> The driver should clean up those callbacks when they are not needed any more
> because the request has been processed completely (either successfully or
> with an error).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2944) Memory leak in Gremlin.Net driver if CancellationToken is used
[
https://issues.apache.org/jira/browse/TINKERPOP-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann updated TINKERPOP-2944:
Description:
We have noticed in my team at G DATA that a .NET service has been using an
increasing amount of memory since we began to propagate the
{{CancellationToken}} into the Gremlin.Net traversal executions which was
introduced in TINKERPOP-2794.
We could track this down with memory profiling to [this place in the
driver|https://github.com/apache/tinkerpop/blob/5c8af70c7fac3ee98df36d250b05320e67ff1b96/gremlin-dotnet/src/Gremlin.Net/Driver/Connection.cs#L94]
where we register a callback to execute when cancellation is requested. These
registered callbacks are only cleaned up when the whole {{Connection}} object
gets disposed. Since the callback contains a reference to the full
{{RequestMessage}} of the traversal, it can contain a lot of data. This is
something that I've completely overlooked when I added support for cancellation.
The driver should clean up those callbacks when they are not needed any more
because the request has been processed completely (either successfully or with
an error).
was:
We have noticed in my team at G DATA that a .NET service has been using an
increasing amount of memory since we began to propagate the
{{CancellationToken}} into the Gremlin.Net traversal executions which was
introduced in TINKERPOP-2794.
We could track this down with memory profiling to [this place in the
driver|https://github.com/FlorianHockmann/tinkerpop/blob/5c8af70c7fac3ee98df36d250b05320e67ff1b96/gremlin-dotnet/src/Gremlin.Net/Driver/Connection.cs#L94]
where we register a callback to execute when cancellation is requested. These
registered callbacks are only cleaned up when the whole {{Connection}} object
gets disposed. Since the callback contains a reference to the full
{{RequestMessage}} of the traversal, it can contain a lot of data. This is
something that I've completely overlooked when I added support for cancellation.
The driver should clean up those callbacks when they are not needed any more
because the request has been processed completely (either successfully or with
an error).
> Memory leak in Gremlin.Net driver if CancellationToken is used
> --
>
> Key: TINKERPOP-2944
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2944
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.6.2, 3.5.5, 3.6.3, 3.5.6
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
>
> We have noticed in my team at G DATA that a .NET service has been using an
> increasing amount of memory since we began to propagate the
> {{CancellationToken}} into the Gremlin.Net traversal executions which was
> introduced in TINKERPOP-2794.
> We could track this down with memory profiling to [this place in the
> driver|https://github.com/apache/tinkerpop/blob/5c8af70c7fac3ee98df36d250b05320e67ff1b96/gremlin-dotnet/src/Gremlin.Net/Driver/Connection.cs#L94]
> where we register a callback to execute when cancellation is requested.
> These registered callbacks are only cleaned up when the whole {{Connection}}
> object gets disposed. Since the callback contains a reference to the full
> {{RequestMessage}} of the traversal, it can contain a lot of data. This is
> something that I've completely overlooked when I added support for
> cancellation.
> The driver should clean up those callbacks when they are not needed any more
> because the request has been processed completely (either successfully or
> with an error).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-2944) Memory leak in Gremlin.Net driver if CancellationToken is used
Florian Hockmann created TINKERPOP-2944:
---
Summary: Memory leak in Gremlin.Net driver if CancellationToken is
used
Key: TINKERPOP-2944
URL: https://issues.apache.org/jira/browse/TINKERPOP-2944
Project: TinkerPop
Issue Type: Bug
Components: dotnet
Affects Versions: 3.5.5, 3.6.2, 3.6.3, 3.5.6
Reporter: Florian Hockmann
Assignee: Florian Hockmann
We have noticed in my team at G DATA that a .NET service has been using an
increasing amount of memory since we began to propagate the
{{CancellationToken}} into the Gremlin.Net traversal executions which was
introduced in TINKERPOP-2794.
We could track this down with memory profiling to [this place in the
driver|https://github.com/FlorianHockmann/tinkerpop/blob/5c8af70c7fac3ee98df36d250b05320e67ff1b96/gremlin-dotnet/src/Gremlin.Net/Driver/Connection.cs#L94]
where we register a callback to execute when cancellation is requested. These
registered callbacks are only cleaned up when the whole {{Connection}} object
gets disposed. Since the callback contains a reference to the full
{{RequestMessage}} of the traversal, it can contain a lot of data. This is
something that I've completely overlooked when I added support for cancellation.
The driver should clean up those callbacks when they are not needed any more
because the request has been processed completely (either successfully or with
an error).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2918) Utils.GenerateUserAgent assumes Gremlin.Net.dll to be present when, in some environments, it is not.
[
https://issues.apache.org/jira/browse/TINKERPOP-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann updated TINKERPOP-2918:
Affects Version/s: 3.5.5
> Utils.GenerateUserAgent assumes Gremlin.Net.dll to be present when, in some
> environments, it is not.
>
>
> Key: TINKERPOP-2918
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2918
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.6.2, 3.5.5
>Reporter: Daniel C. Weber
>Priority: Blocker
>
> The dotnet driver in v3.6.2 adds the ability to add a user agent to the
> request.
> To get the user agent name, Gremlin.Net.Process.Utils.GenerateUserAgent uses
> AssemblyName.GetAssemblyName("Gremlin.Net.dll") (see
> [here|https://github.com/apache/tinkerpop/blob/125e5bf4560546c9727dd25ff4d590f34c7d625b/gremlin-dotnet/src/Gremlin.Net/Process/Utils.cs#L81])
> Because the dll is referenced in a relative manner, in some environments
> (Visual studio debugging and Docker deployment for me), this results in a
> FileNotFoundException. In my specific local case, the path prefixed is the
> path where the csproj is.
> However, it works in a different project (also VS locally). I have no idea
> yet why. Also, I would file a pull request that would just use
> GetExecutingAssembly() instead of AssemblyName.GetAssemblyName (because the
> executing code is in that specific dll), but there's probably a reason for it
> not being used. Then again, using GetExecutingAssembly for the application
> name seems odd, was that supposed to be GetEntryAssembly?
> Will happily provide more insight and code.
> cc: [~Florian Hockmann]
> Edit: Proposed change in https://github.com/apache/tinkerpop/pull/2005
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2085) Remove dependency on Mono
[
https://issues.apache.org/jira/browse/TINKERPOP-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17677469#comment-17677469
]
Florian Hockmann commented on TINKERPOP-2085:
-
DocFX finally supports .NET 6:
[https://github.com/dotnet/docfx/releases/tag/v2.60.0]
So, we can already remove Mono from the documentation part.
There also seems to finally be some progress for the NuGet issue where we
currently cannot set the NuGet key: [https://github.com/NuGet/Home/pull/12321]
> Remove dependency on Mono
> -
>
> Key: TINKERPOP-2085
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2085
> Project: TinkerPop
> Issue Type: Improvement
> Components: build-release, dotnet
>Affects Versions: 3.2.10
>Reporter: Florian Hockmann
>Priority: Minor
>
> We currently rely on Mono to push NuGet packages and to create the
> Gremlin.Net.Template package.
> To push the packages, we can now also simply use [{{dotnet nuget
> push}}|https://docs.microsoft.com/dotnet/core/tools/dotnet-nuget-push]
> and for dotnet templates, there seems to be [a
> workaround|https://github.com/NuGet/Home/issues/4254#issuecomment-372795990]
> that uses a dummy {{.csproj}} file which enables {{dotnet pack}} to create a
> valid NuGet package for a dotnet template.
> So, we don't have to use Mono any more at all and we also shouldn't need to
> download nuget.exe any more during the build.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-2853) Gremlin.Net driver should throw better exception message for unsupported GraphBinary type
Florian Hockmann created TINKERPOP-2853:
---
Summary: Gremlin.Net driver should throw better exception message
for unsupported GraphBinary type
Key: TINKERPOP-2853
URL: https://issues.apache.org/jira/browse/TINKERPOP-2853
Project: TinkerPop
Issue Type: Task
Components: dotnet
Affects Versions: 3.5.4, 3.6.1
Reporter: Florian Hockmann
The driver currently throws an exception that isn't very telling:
{code:java}
System.Collections.Generic.KeyNotFoundException : The given key
'janusgraph.RelationIdentifier' was not present in the dictionary. {code}
It would be good if it would instead clearly state that no serializer was found
for the GraphBinary type. This was first reported [on the janusgraph-users
list|https://lists.lfaidata.foundation/g/janusgraph-users/message/6673].
The exception gets thrown
[here|https://github.com/apache/tinkerpop/blob/60b2792d63604b3baec68201adf35ed7f1d1e558/gremlin-dotnet/src/Gremlin.Net/Structure/IO/GraphBinary/TypeSerializerRegistry.cs#L282]
for types received from the server where no serializer is registered for the
driver.
For the write path however, the exception thrown [is already more
telling|https://github.com/apache/tinkerpop/blob/60b2792d63604b3baec68201adf35ed7f1d1e558/gremlin-dotnet/src/Gremlin.Net/Structure/IO/GraphBinary/TypeSerializerRegistry.cs#L224].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2348) Enable nullable checks
[
https://issues.apache.org/jira/browse/TINKERPOP-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-2348.
---
Fix Version/s: 3.7.0
Resolution: Fixed
I'm closing this already although nullable checks are not enabled yet in the
test projects as we can still do that later as it doesn't affect users. It only
improves the code for ourselves during development.
> Enable nullable checks
> --
>
> Key: TINKERPOP-2348
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2348
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.4.11
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Minor
> Fix For: 3.7.0
>
>
> Gremlin.NET should enable [nullable
> checks|https://devblogs.microsoft.com/dotnet/embracing-nullable-reference-types/]
> to clearly communicate to users what can be {{null}} in Gremlin.NET and also
> to possibly find possible {{NullReferenceExceptions}} easier in our own code.
> The recommendation from Microsoft is to update libraries during the so-called
> _"nullable rollout phase"_ which ends in November with the expected release
> of .NET 5 which should have nullable checks enabled by default.
> We can add .NET Core 3.1 as an additional target framework to get the
> nullable checks and still also target .NET Standard to stay platform
> independent and to also still support .NET Framework and older .NET Core
> versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2828) Golang driver cannot deserialize edge id
[
https://issues.apache.org/jira/browse/TINKERPOP-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17637664#comment-17637664
]
Florian Hockmann commented on TINKERPOP-2828:
-
{quote}Do you think it would be better to not throw an error and rather return
nil in case of Janus?
{quote}
I think it's the right thing to do for Gremlin-Go to throw an error if it
encounters a type during deserialization for which it has no deserializer
configured. That way, you as the user notice that something is not working like
you expected and you can now decide how to deal with it. If it would simply
return {{nil}} instead, then you wouldn't know whether the value is simply
missing or whether it couldn't be deserialized by the driver.
Now, you can handle it either by implementing a deserializer for that type on
your own (which you could make available for other JanusGraph users to use) or
by working around this limitation, meaning that your traversals should not
return a {{RelationIdentifier}} any more.
If you're interested in writing your own serializer / deserializer, then taking
a look at the current Gremlin-Go serializers is probably a good idea:
[https://github.com/apache/tinkerpop/blob/master/gremlin-go/driver/graphBinary.go]
and for the JanusGraph {{{}RelationIdentifier{}}}, you can for example check
out the .NET implementation:
[https://github.com/JanusGraph/janusgraph-dotnet/blob/master/src/JanusGraph.Net/IO/GraphBinary/Types/RelationIdentifierSerializer.cs]
{quote}Is it possible to somehow detect the type and transparently use the
correct deserializer?
{quote}
The problem is that Gremlin-Go simply has no serializer for the JanusGraph type
{{{}RelationIdentifier{}}}. If it would have one, then it could of course also
select it.
> Golang driver cannot deserialize edge id
>
>
> Key: TINKERPOP-2828
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2828
> Project: TinkerPop
> Issue Type: Bug
> Components: go
>Affects Versions: 3.6.1, 3.5.4
>Reporter: Navgeet
>Priority: Major
> Labels: golang
> Attachments: main.go
>
>
> The issue occurs when we call {{ElementMap}} for edges. On further debugging,
> I found {{label}} can be deserialized but not {{{}id{}}}.
>
> {noformat}
> Error occurred during operation gremlinServerWSProtocol.readLoop(): 'E0408:
> unknown data type to deserialize 0x0'
> Read loop error 'E0408: unknown data type to deserialize 0x0', closing read
> loop.
> Connection error callback invoked, closing protocol.
> E0408: unknown data type to deserialize 0x0
> {noformat}
> Please see attached code for reproducing the issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2828) Golang driver cannot deserialize edge id
[
https://issues.apache.org/jira/browse/TINKERPOP-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17637278#comment-17637278
]
Florian Hockmann commented on TINKERPOP-2828:
-
Are you running into that problem with TinkerGraph or some other graph
provider? JanusGraph for example has its own type {{RelationIdentifier}} for
edge ids which naturally cannot be deserialized by Gremlin-Go as Gremlin has no
knowledge of such a provider-specific type. If that's the case here, you can
either implement a custom deserializer yourself for that type or see whether
you can change your application to work without needing to return edge ids.
If you for example already run into that problem when you really just want to
create a new edge ({{{}g.addE().from([...]).to([...]){}}}) which by default
also returns the edge, then you can just modify the traversal to not return the
edge any more: {{{}g.addE().from([...]).to([...]).none(){}}}.
> Golang driver cannot deserialize edge id
>
>
> Key: TINKERPOP-2828
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2828
> Project: TinkerPop
> Issue Type: Bug
> Components: go
>Affects Versions: 3.6.1, 3.5.4
>Reporter: Navgeet
>Priority: Major
> Labels: golang
> Attachments: main.go
>
>
> The issue occurs when we call {{ElementMap}} for edges. On further debugging,
> I found {{label}} can be deserialized but not {{{}id{}}}.
>
> {noformat}
> Error occurred during operation gremlinServerWSProtocol.readLoop(): 'E0408:
> unknown data type to deserialize 0x0'
> Read loop error 'E0408: unknown data type to deserialize 0x0', closing read
> loop.
> Connection error callback invoked, closing protocol.
> E0408: unknown data type to deserialize 0x0
> {noformat}
> Please see attached code for reproducing the issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2471) Add logging to Gremlin.Net driver
[ https://issues.apache.org/jira/browse/TINKERPOP-2471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann closed TINKERPOP-2471. --- Fix Version/s: 3.7.0 3.6.2 3.5.5 Assignee: Florian Hockmann Resolution: Fixed > Add logging to Gremlin.Net driver > - > > Key: TINKERPOP-2471 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2471 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Reporter: Florian Hockmann >Assignee: Florian Hockmann >Priority: Minor > Fix For: 3.7.0, 3.6.2, 3.5.5 > > > It would be helpful to have logging in the driver to get insights into its > internal state. Examples for events that we could log are: > * A connection is dead & will be replaced. > * The pool is empty, so we cannot get a connection for the current request > (but will probably try again) > This should make it more transparent for users how the driver operates and > what its current state is. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2794) Allow cancellation of Gremlin.Net async methods
[ https://issues.apache.org/jira/browse/TINKERPOP-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann closed TINKERPOP-2794. --- Fix Version/s: 3.7.0 3.6.2 3.5.5 Resolution: Fixed > Allow cancellation of Gremlin.Net async methods > --- > > Key: TINKERPOP-2794 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2794 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Reporter: Bill Poole >Assignee: Florian Hockmann >Priority: Major > Fix For: 3.7.0, 3.6.2, 3.5.5 > > > Gremlin.Net async methods such as Promise do not accept a CancellationToken > parameter and cannot therefore be cancelled. Applications often need to be > closed quickly/responsively when a user quits or an application server > component is shut down/rebooted - e.g., during cluster auto > scaling/rebalancing. > All async methods should accept a CancellationToken parameter (which can be > given a default value of 'default'). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-1853) Use generic version of ITraversal for arguments in Traversal API
[
https://issues.apache.org/jira/browse/TINKERPOP-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-1853.
---
Resolution: Won't Do
As noted, we would probably have to break the translation of Gremlin traversals
to .NET to make this possible and this feature doesn't seem important enough to
do that.
> Use generic version of ITraversal for arguments in Traversal API
>
>
> Key: TINKERPOP-1853
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1853
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.3.0, 3.2.6
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Minor
>
> Currently, we use {{ITraversal}} as the type for arguments in the traversal
> API of Gremlin.Net when a traversal is expected:
> {code}
> public GraphTraversal< S , E2 > Choose (ITraversal traversalPredicate,
> ITraversal trueChoice)
> {code}
> The Java equivalent is more useful as it only allows {{Traversal}} for
> the second argument:
> {code}
> public default GraphTraversal choose(final Traversal
> traversalPredicate, final Traversal trueChoice)
> {code}
> We should also use the generic type {{ITraversal}} in Gremlin.Net
> in those cases. Then it wouldn't be necessary to specify the type for the
> arguments and the step as it can be interfered from the type of the arguments.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2786) Allow large result sets to be streamed to the client
[ https://issues.apache.org/jira/browse/TINKERPOP-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann closed TINKERPOP-2786. --- Resolution: Duplicate > Allow large result sets to be streamed to the client > > > Key: TINKERPOP-2786 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2786 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.6.1 >Reporter: Bill Poole >Priority: Major > > When working with larger result sets, it is beneficial for memory management > to process each chunk of data as it is returned from the gremlin server. This > is possible with the Javascript client library as stated > [here|https://tinkerpop.apache.org/docs/current/reference/#_processing_results_as_they_are_returned_from_the_gremlin_server]. > This should also be possible with the .NET client. > Ideally, it would be possible for a traversal to return an async enumerator > (IAsyncEnumerable). Perhaps add a PromiseStream method to supplement the > Promise method? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (TINKERPOP-2794) Allow cancellation of Gremlin.Net async methods
[ https://issues.apache.org/jira/browse/TINKERPOP-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann reassigned TINKERPOP-2794: --- Assignee: Florian Hockmann > Allow cancellation of Gremlin.Net async methods > --- > > Key: TINKERPOP-2794 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2794 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Reporter: Bill Poole >Assignee: Florian Hockmann >Priority: Major > > Gremlin.Net async methods such as Promise do not accept a CancellationToken > parameter and cannot therefore be cancelled. Applications often need to be > closed quickly/responsively when a user quits or an application server > component is shut down/rebooted - e.g., during cluster auto > scaling/rebalancing. > All async methods should accept a CancellationToken parameter (which can be > given a default value of 'default'). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2794) Allow cancellation of Gremlin.Net async methods
[
https://issues.apache.org/jira/browse/TINKERPOP-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600722#comment-17600722
]
Florian Hockmann commented on TINKERPOP-2794:
-
We basically already have a ticket for this: TINKERPOP-2210.
That was originally mainly focused on .NET, but since we first need support for
cancellation on the server, we decided that it should be implement there first.
I'm wondering however whether we should maybe just add support for cancellation
already in .NET so that the client can at least release its resources and shut
down, although the server might still evaluate traversals sent by that client,
where the results will be ignored. We should probably just document clearly
that the {{CancellationToken}} will not stop the server from evaluating a
traversal that was already sent.
So, my suggestion here would be that we don't treat this as a duplicate of
TINKERPOP-2210 which is now mainly about supporting proper cancellation
server-side and instead simply at {{CancellationTokens}} in .NET to close open
connections.
> Allow cancellation of Gremlin.Net async methods
> ---
>
> Key: TINKERPOP-2794
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2794
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Reporter: Bill Poole
>Priority: Major
>
> Gremlin.Net async methods such as Promise do not accept a CancellationToken
> parameter and cannot therefore be cancelled. Applications often need to be
> closed quickly/responsively when a user quits or an application server
> component is shut down/rebooted - e.g., during cluster auto
> scaling/rebalancing.
> All async methods should accept a CancellationToken parameter (which can be
> given a default value of 'default').
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-2788) Gremlin.Net incorrectly serializes custom types without type information for GraphSON 3
Florian Hockmann created TINKERPOP-2788:
---
Summary: Gremlin.Net incorrectly serializes custom types without
type information for GraphSON 3
Key: TINKERPOP-2788
URL: https://issues.apache.org/jira/browse/TINKERPOP-2788
Project: TinkerPop
Issue Type: Bug
Components: dotnet, server
Affects Versions: 3.5.4, 3.6.1
Reporter: Florian Hockmann
Gremlin.Net incorrectly serializes an object of a custom type for GraphSON 3 if
it doesn't have a custom serializer for that type. It simply passes the object
to its underlying JSON serializer which results in a JSON serialization without
any type information.
I think this shouldn't be possible as we always expect types with GraphSON 3
[as per the
specs|https://tinkerpop.apache.org/docs/current/dev/io/#graphson-3d0]:
> GraphSON 3.0 does not have an option to be typeless. Types are always
> embedded except for strings and boolean values which are inferred from JSON
> types.
Example code to reproduce:
{code:java}
var xxx = new[] { new XXX { X = 1, Y = 2 }, new XXX { X = 3, Y = 4 } };
var graphSon = writer.WriteObject(xxx);
// graphSon = "{"@type":"g:List","@value":[{"X":1,"Y":2},{"X":3,"Y":4}]}" {code}
But the problem doesn't seem to be limited to .NET as the server also
successfully responds to a request with such a custom type if it's used in a
traversal:
{code:java}
var xxx = new[] { new XXX { X = 1, Y = 2 }, new XXX { X = 3, Y = 4 } };
var result = (List)await g.Inject(xxx).Promise(t => t.ToList());
foreach (var x in result)
{
foreach (var pair in (Dictionary)x)
{
Console.WriteLine($"{pair.Key}: {pair.Value}");
}
}
/*… which displays:
X: 1
Y: 2
X: 3
Y: 4*/{code}
This was first reported [on the janusgraph-users mailing
list|https://lists.lfaidata.foundation/g/janusgraph-users/message/6612] by
[~billpoole].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2751) Transaction: tx.commit() hangs up in javascript client-lib
[
https://issues.apache.org/jira/browse/TINKERPOP-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17550852#comment-17550852
]
Florian Hockmann commented on TINKERPOP-2751:
-
You're using TinkerGraph here which doesn't support transactions. You need to
use a graph provider that supports transactions like Neo4j-Gremlin as [shown in
the reference
docs|https://tinkerpop.apache.org/docs/current/reference/#_configuring].
I guess it's unfortunate that the driver just hangs there instead of throwing
some exceptions that informs about the lacking support for transactions.
[~spmallette] Any idea whether we could improve this behavior with reasonable
effort?
> Transaction: tx.commit() hangs up in javascript client-lib
> --
>
> Key: TINKERPOP-2751
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2751
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript, server
>Affects Versions: 3.6.0
>Reporter: Stefan Templin
>Priority: Minor
> Labels: Transaction
>
> Hi,
> I am trying to get transactions working for a while now, but no matter what i
> do, i can't get the transaction to commit.
> h3. My Setup:
> * Running gremlin-server 3.6.0 in Docker on localhost using the
> default-configuration.
> {code}
> version: '3.7'
> services:
> gremlin:
> image: tinkerpop/gremlin-server:3.6.0
> container_name: gremlin
> restart: always
> ports:
> - "8182:8182"
> {code}
> * Javascript-Gremlin-lib 3.6.0
> h3. Problem:
> Im executing the following code:
>
> {code:js}
> const dc = new DriverRemoteConnection('ws://localhost:8182/gremlin', {
> 'rejectUnauthorized': false});
> const g = traversal().withRemote(dc);
> const tx = g.tx();
> const gtx = tx.begin();
> try {
> await gtx.addV('person').iterate();
> await gtx.addV('software').iterate();
> await tx.commit();
> // stuck here
> console.log('here')
> } catch (err) {
> await tx.rollback();
> } finally {
> await dc.close();
> }{code}
> The code just will never get past 'await tx.commit()', no error, nothing. It
> just hangs up there. The code before that is properly executed and the Graph
> contains both vertices.
> Am I doing anything wrong there, or are transactions not working properly?
> Hope you can help me with that.
>
> Kind regards,
> Stefan
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (TINKERPOP-2738) Apply new ASF data privacy policy to comply with GDPR
Florian Hockmann created TINKERPOP-2738: --- Summary: Apply new ASF data privacy policy to comply with GDPR Key: TINKERPOP-2738 URL: https://issues.apache.org/jira/browse/TINKERPOP-2738 Project: TinkerPop Issue Type: Improvement Components: documentation Reporter: Florian Hockmann The ASF has a new data privacy policy to comply with the GDPR (the European Union's General Data Protection Regulation) and we - like all other ASF projects - were asked to update our project homepage accordingly. The new privacy policy can be found at: https://privacy.apache.org/policies/privacy-policy-public.html and there is an FAQ for projects that describes necessary changes: https://privacy.apache.org/faq/committers.html Since we don't use Google Analytics, it looks like we only need to do two things here: # Add a link to this privacy policy to our homepage. # Stop loading Google fonts from Google servers and instead host them ourselves. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (TINKERPOP-2717) Gremlin.NET : WebSocketConnection does not check for MessageType.Close, causing error InvalidOperationException: "Received data deserialized into null object message.
[
https://issues.apache.org/jira/browse/TINKERPOP-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-2717.
---
Fix Version/s: 3.6.0
3.5.3
Assignee: Florian Hockmann
Resolution: Fixed
> Gremlin.NET : WebSocketConnection does not check for MessageType.Close,
> causing error InvalidOperationException: "Received data deserialized into
> null object message. Cannot operate on it."
> -
>
> Key: TINKERPOP-2717
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2717
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.4.13, 3.5.2
>Reporter: Oliver Towers
>Assignee: Florian Hockmann
>Priority: Minor
> Fix For: 3.6.0, 3.5.3
>
>
> h2. Issue:
> If the server sends a valid Close websocket message to the client, the client
> will throw {{InvalidOperationException}} rather than acknowledge/cleanup the
> connection gracefully.
> See relevant point where exception is thrown.
> [here|https://github.com/apache/tinkerpop/blob/7835e7a2c3b19a14f196525da844a2e35ba5a105/gremlin-dotnet/src/Gremlin.Net/Driver/Connection.cs#L123]
> Close messages from the server can be expected when the server is doing a
> graceful shutdown, and clients would be expected to reconnect.
> h2. Details:
> A Close websocket message being received by ClientWebSocket,
> [WebSocketReceiveResult.MessageType|https://docs.microsoft.com/en-us/dotnet/api/system.net.websockets.websocketreceiveresult.messagetype?view=net-6.0]
> will return {{MessageType.Close}}. In this case, the message buffer will be
> zero-bytes, see these
> [remarks|https://docs.microsoft.com/en-us/dotnet/api/system.net.websockets.websocketreceiveresult.count?view=net-6.0#remarks].
> Currently, Gremlin.NET does not check for this message type in
> [WebSocketConnection.ReceiveMessageAsync|https://github.com/apache/tinkerpop/blob/7835e7a2c3b19a14f196525da844a2e35ba5a105/gremlin-dotnet/src/Gremlin.Net/Driver/WebSocketConnection.cs#L92]
> and return a zero-length buffer. In
> [Connection.HandleReceiveAsync|https://github.com/apache/tinkerpop/blob/7835e7a2c3b19a14f196525da844a2e35ba5a105/gremlin-dotnet/src/Gremlin.Net/Driver/Connection.cs#L118],
> the attempt to deserialize the empty buffer returns `null` and the check
> fails.
> h2. Potential Fix
> # If `MessageType == Close` Throw a new connection closed exception from
> {{WebSocketConnection.ReceiveMessageAsync}} which includes
> {{WebSocketReceiveResult.CloseStatus}} and
> {{WebSocketReceiveResult.CloseDescription}} in the exception message and as
> properties.
> # This will be caught in {{Connection.HandleRecieveAsync}} and treated as
> fatal and will call {{CloseConnectionBecauseOfFailureAsync}} and will handle
> completing the close handshake, and notifies pending requests on the
> connection with the closed connection exception.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (TINKERPOP-2367) Gremlin Translators for .NET
[ https://issues.apache.org/jira/browse/TINKERPOP-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann closed TINKERPOP-2367. --- Fix Version/s: 3.6.0 3.5.3 Resolution: Fixed > Gremlin Translators for .NET > > > Key: TINKERPOP-2367 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2367 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet, translator >Affects Versions: 3.4.6 >Reporter: Stephen Mallette >Assignee: Florian Hockmann >Priority: Trivial > Fix For: 3.6.0, 3.5.3 > > > There is often a need to convert bytecode to its script like representation > and it is helpful to be able to do this natively in all programming > languages. While there is support for this feature in Java and Javascript > this functionality does not yet exist in .NET. > https://github.com/apache/tinkerpop/blob/3.4.6/gremlin-javascript/src/main/javascript/gremlin-javascript/lib/process/translator.js > https://github.com/apache/tinkerpop/blob/3.4.6/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/jsr223/GroovyTranslator.java -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (TINKERPOP-2726) Python's GroovyTranslator translates boolean wrong
[
https://issues.apache.org/jira/browse/TINKERPOP-2726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-2726.
---
Fix Version/s: 3.6.0
3.5.3
Resolution: Fixed
> Python's GroovyTranslator translates boolean wrong
> --
>
> Key: TINKERPOP-2726
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2726
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.5.2
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Trivial
> Fix For: 3.6.0, 3.5.3
>
>
> While working on a GroovyTranslator for .NET (TINKERPOP-2367), I used the
> extensive Python test suite as a reference and noticed that boolean values
> aren't translated correctly:
> {{True}} gets translated simply as {{{}True{}}}, but it should be {{true}} in
> Groovy.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (TINKERPOP-2705) Support null as an argument where it makes sense in Gremlin.NET
[
https://issues.apache.org/jira/browse/TINKERPOP-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-2705.
---
Fix Version/s: 3.6.0
Resolution: Fixed
> Support null as an argument where it makes sense in Gremlin.NET
> ---
>
> Key: TINKERPOP-2705
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2705
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.5.2
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Minor
> Fix For: 3.6.0
>
>
> We improved support for {{null}} in the last few releases, but Gremlin.NET
> still throws a {{NullReferenceExceptions}} if {{null}} is provided in some
> places, especially when it's not obvious that {{null}} is a valid argument
> value.
> We should find these places and then either allow {{null}} there or throw an
> {{ArgumentNullException}} if we're really sure that {{null}} cannot be a
> valid argument there. In places where we don't know for sure whether {{null}}
> is always invalid or not, we should probably allow it in Gremlin.NET so that
> the server can decide how to handle it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (TINKERPOP-2727) HasContainer should allow a null key
Florian Hockmann created TINKERPOP-2727:
---
Summary: HasContainer should allow a null key
Key: TINKERPOP-2727
URL: https://issues.apache.org/jira/browse/TINKERPOP-2727
Project: TinkerPop
Issue Type: Improvement
Components: process
Affects Versions: 3.5.2
Reporter: Florian Hockmann
TINKERPOP-2605 changed {{null}} semantics to allow {{null}} as an argument in
more places so that {{has(null)}} should not throw a NPE any more and instead
filter all traversers out.
{{HasContainer}} however still throws a NPE if the {{key}} is {{{}null{}}}.
I discovered this when trying to update JanusGraph [as that folds in a
{{HasContainer}} like
this|https://github.com/JanusGraph/janusgraph/blob/4246d49cee46d549d752515f3956cd2d59f1fd0a/janusgraph-core/src/main/java/org/janusgraph/graphdb/tinkerpop/optimize/step/HasStepFolder.java#L266]
which leads to the NPE and thus failing tests.
The same behavior can also be produced with just TinkerGraph and for example
the following traversals:
{code:java}
g.V().has(null, 1)
g.V().has(null, P.neq(null)){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (TINKERPOP-2726) Python's GroovyTranslator translates boolean wrong
Florian Hockmann created TINKERPOP-2726:
---
Summary: Python's GroovyTranslator translates boolean wrong
Key: TINKERPOP-2726
URL: https://issues.apache.org/jira/browse/TINKERPOP-2726
Project: TinkerPop
Issue Type: Improvement
Components: python
Affects Versions: 3.5.2
Reporter: Florian Hockmann
Assignee: Florian Hockmann
While working on a GroovyTranslator for .NET (TINKERPOP-2367), I used the
extensive Python test suite as a reference and noticed that boolean values
aren't translated correctly:
{{True}} gets translated simply as {{{}True{}}}, but it should be {{true}} in
Groovy.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (TINKERPOP-2719) hasNext is called on TraverserIterator after transaction is committed
[
https://issues.apache.org/jira/browse/TINKERPOP-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-2719.
---
Fix Version/s: 3.6.0
3.5.3
Assignee: Florian Hockmann
Resolution: Fixed
> hasNext is called on TraverserIterator after transaction is committed
> -
>
> Key: TINKERPOP-2719
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2719
> Project: TinkerPop
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.2
>Reporter: Florian G
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.6.0, 3.5.3
>
>
> In {{{}TraversalOpProcessor{}}}, the {{hasNext()}} [function is
> called|https://github.com/apache/tinkerpop/blob/a52887d084053cd420580a0c0a80e745b49ee252/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/traversal/TraversalOpProcessor.java#L428]
> on a {{TraversalIterator}} object after the transaction [is
> committed|https://github.com/apache/tinkerpop/blob/a52887d084053cd420580a0c0a80e745b49ee252/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/traversal/TraversalOpProcessor.java#L414].
> This causes issues if the database tries to further execute the traversal
> upon the {{hasNext()}} call but has no access to the transaction anymore.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (TINKERPOP-2723) Make GraphBinary the default serialization format for .NET and Python
Florian Hockmann created TINKERPOP-2723: --- Summary: Make GraphBinary the default serialization format for .NET and Python Key: TINKERPOP-2723 URL: https://issues.apache.org/jira/browse/TINKERPOP-2723 Project: TinkerPop Issue Type: Improvement Components: dotnet, python Reporter: Florian Hockmann Fix For: 3.6.0 .NET and Python have support for GraphBinary at least since 3.5.0 but kept GraphSON 3 by default. It now seems safe to make GraphBinary the default in 3.6.0. Mostly as a reminder so we don't forget it: We also need to update the docs accordingly. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (TINKERPOP-2717) Gremlin.NET : WebSocketConnection does not check for MessageType.Close, causing error InvalidOperationException: "Received data deserialized into null object messag
[
https://issues.apache.org/jira/browse/TINKERPOP-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502133#comment-17502133
]
Florian Hockmann commented on TINKERPOP-2717:
-
Hey [~olivertowers], thanks for this bug report and the thorough analysis! Your
suggestion for the fix also sounds good to me. Would you like to create a pull
request to fix this?
> Gremlin.NET : WebSocketConnection does not check for MessageType.Close,
> causing error InvalidOperationException: "Received data deserialized into
> null object message. Cannot operate on it."
> -
>
> Key: TINKERPOP-2717
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2717
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.4.13, 3.5.2
>Reporter: Oliver Towers
>Priority: Minor
>
> h2. Issue:
> If the server sends a valid Close websocket message to the client, the client
> will throw {{InvalidOperationException}} rather than acknowledge/cleanup the
> connection gracefully.
> See relevant point where exception is thrown.
> [here|https://github.com/apache/tinkerpop/blob/7835e7a2c3b19a14f196525da844a2e35ba5a105/gremlin-dotnet/src/Gremlin.Net/Driver/Connection.cs#L123]
> Close messages from the server can be expected when the server is doing a
> graceful shutdown, and clients would be expected to reconnect.
> h2. Details:
> A Close websocket message being received by ClientWebSocket,
> [WebSocketReceiveResult.MessageType|https://docs.microsoft.com/en-us/dotnet/api/system.net.websockets.websocketreceiveresult.messagetype?view=net-6.0]
> will return {{MessageType.Close}}. In this case, the message buffer will be
> zero-bytes, see these
> [remarks|https://docs.microsoft.com/en-us/dotnet/api/system.net.websockets.websocketreceiveresult.count?view=net-6.0#remarks].
> Currently, Gremlin.NET does not check for this message type in
> [WebSocketConnection.ReceiveMessageAsync|https://github.com/apache/tinkerpop/blob/7835e7a2c3b19a14f196525da844a2e35ba5a105/gremlin-dotnet/src/Gremlin.Net/Driver/WebSocketConnection.cs#L92]
> and return a zero-length buffer. In
> [Connection.HandleReceiveAsync|https://github.com/apache/tinkerpop/blob/7835e7a2c3b19a14f196525da844a2e35ba5a105/gremlin-dotnet/src/Gremlin.Net/Driver/Connection.cs#L118],
> the attempt to deserialize the empty buffer returns `null` and the check
> fails.
> h2. Potential Fix
> # If `MessageType == Close` Throw a new connection closed exception from
> {{WebSocketConnection.ReceiveMessageAsync}} which includes
> {{WebSocketReceiveResult.CloseStatus}} and
> {{WebSocketReceiveResult.CloseDescription}} in the exception message and as
> properties.
> # This will be caught in {{Connection.HandleRecieveAsync}} and treated as
> fatal and will call {{CloseConnectionBecauseOfFailureAsync}} and will handle
> completing the close handshake, and notifies pending requests on the
> connection with the closed connection exception.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (TINKERPOP-2367) Gremlin Translators for .NET
[ https://issues.apache.org/jira/browse/TINKERPOP-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann reassigned TINKERPOP-2367: --- Assignee: Florian Hockmann > Gremlin Translators for .NET > > > Key: TINKERPOP-2367 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2367 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet, translator >Affects Versions: 3.4.6 >Reporter: Stephen Mallette >Assignee: Florian Hockmann >Priority: Trivial > > There is often a need to convert bytecode to its script like representation > and it is helpful to be able to do this natively in all programming > languages. While there is support for this feature in Java and Javascript > this functionality does not yet exist in .NET. > https://github.com/apache/tinkerpop/blob/3.4.6/gremlin-javascript/src/main/javascript/gremlin-javascript/lib/process/translator.js > https://github.com/apache/tinkerpop/blob/3.4.6/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/jsr223/GroovyTranslator.java -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (TINKERPOP-2705) Support null as an argument where it makes sense in Gremlin.NET
[
https://issues.apache.org/jira/browse/TINKERPOP-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann reassigned TINKERPOP-2705:
---
Assignee: Florian Hockmann
> Support null as an argument where it makes sense in Gremlin.NET
> ---
>
> Key: TINKERPOP-2705
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2705
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.5.2
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Minor
>
> We improved support for {{null}} in the last few releases, but Gremlin.NET
> still throws a {{NullReferenceExceptions}} if {{null}} is provided in some
> places, especially when it's not obvious that {{null}} is a valid argument
> value.
> We should find these places and then either allow {{null}} there or throw an
> {{ArgumentNullException}} if we're really sure that {{null}} cannot be a
> valid argument there. In places where we don't know for sure whether {{null}}
> is always invalid or not, we should probably allow it in Gremlin.NET so that
> the server can decide how to handle it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (TINKERPOP-2518) Enhance .NET gherkin framework to deal with more advanced assertions
[ https://issues.apache.org/jira/browse/TINKERPOP-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann closed TINKERPOP-2518. --- Fix Version/s: 3.6.0 3.5.3 Resolution: Fixed > Enhance .NET gherkin framework to deal with more advanced assertions > > > Key: TINKERPOP-2518 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2518 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.5.0 >Reporter: Stephen Mallette >Assignee: Florian Hockmann >Priority: Major > Fix For: 3.6.0, 3.5.3 > > > There are two pull requests which introduced some "ignores" for tests in .NET: > https://github.com/apache/tinkerpop/pull/1383 > https://github.com/apache/tinkerpop/pull/1387 > In both cases the Gremlin seems to work fine but the assertions aren't robust > enough in the framework to handle the results (i think). We should try to > settle this before 3.5.0 release. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (TINKERPOP-2705) Support null as an argument where it makes sense in Gremlin.NET
Florian Hockmann created TINKERPOP-2705:
---
Summary: Support null as an argument where it makes sense in
Gremlin.NET
Key: TINKERPOP-2705
URL: https://issues.apache.org/jira/browse/TINKERPOP-2705
Project: TinkerPop
Issue Type: Improvement
Components: dotnet
Affects Versions: 3.5.2
Reporter: Florian Hockmann
We improved support for {{null}} in the last few releases, but Gremlin.NET
still throws a {{NullReferenceExceptions}} if {{null}} is provided in some
places, especially when it's not obvious that {{null}} is a valid argument
value.
We should find these places and then either allow {{null}} there or throw an
{{ArgumentNullException}} if we're really sure that {{null}} cannot be a valid
argument there. In places where we don't know for sure whether {{null}} is
always invalid or not, we should probably allow it in Gremlin.NET so that the
server can decide how to handle it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (TINKERPOP-2682) Enable WebSocket compression in .NET by default
[
https://issues.apache.org/jira/browse/TINKERPOP-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-2682.
---
Fix Version/s: 3.6.0
3.5.3
Resolution: Fixed
> Enable WebSocket compression in .NET by default
> ---
>
> Key: TINKERPOP-2682
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2682
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.5.1
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Minor
> Fix For: 3.6.0, 3.5.3
>
>
> .NET 6 added support for WebSocket compression to .NET:
> [https://devblogs.microsoft.com/dotnet/announcing-net-6/#websocket-compression]
> Users can already enable that by themselves as it has been added as a
> property {{DangerousDeflate}} to the {{ClientWebSocketOptions}} which can be
> configured via the {{webSocketConfiguration}} of the {{GremlinClient}}
> constructor in Gremlin.Net.
> Since we have enabled compression by default in Python and Java, it makes
> sense to also enable it by default in .NET. We can of course only do that for
> .NET 6 which is why we'll have to add that as an additional target framework
> to Gremlin.Net.
> The .NET 6 announcement mentions that WebSocket compression together with
> encrypted content is susceptible to attacks like CRIME and BREACH that can
> reveal the encrypted content if an attacker is able to control data that is
> sent together with the encrypted content over the same WebSocket connection.
> That is why the property to enable compression is called
> {_}Dangerous{_}Deflate and why compression can also be disabled on a
> per-message basis
> ([source|https://github.com/dotnet/runtime/issues/31088#issuecomment-804359919]).
> I suggest we can account for these possible attacks by disabling compression
> for the authentication messages we send to the server which contain
> credentials and by adding a note to the docs about this with a recommendation
> to disable compression if an application needs to send sensitive data, but
> also data controlled by (potentially untrusted) users to the server.
> Since the attacker additionally needs to be able to monitor the network
> traffic between the client and the server, I guess >99% of applications are
> not affected by this and will therefore benefit from enabling compression by
> default.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (TINKERPOP-2695) Support NaN/Inf in Parser and Gherkin
[ https://issues.apache.org/jira/browse/TINKERPOP-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann updated TINKERPOP-2695: Fix Version/s: (was: 3.5.3) > Support NaN/Inf in Parser and Gherkin > - > > Key: TINKERPOP-2695 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2695 > Project: TinkerPop > Issue Type: Improvement > Components: language >Affects Versions: 3.6.0 >Reporter: Mike Personick >Priority: Minor > Fix For: 3.6.0 > > > Add support for NaN and Inf/-Inf in the parser and in the Gherkin test suite. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (TINKERPOP-2695) Support NaN/Inf in Parser and Gherkin
[ https://issues.apache.org/jira/browse/TINKERPOP-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann closed TINKERPOP-2695. --- Fix Version/s: 3.6.0 3.5.3 Assignee: Florian Hockmann Resolution: Fixed > Support NaN/Inf in Parser and Gherkin > - > > Key: TINKERPOP-2695 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2695 > Project: TinkerPop > Issue Type: Improvement > Components: language >Affects Versions: 3.6.0 >Reporter: Mike Personick >Assignee: Florian Hockmann >Priority: Minor > Fix For: 3.6.0, 3.5.3 > > > Add support for NaN and Inf/-Inf in the parser and in the Gherkin test suite. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (TINKERPOP-2695) Support NaN/Inf in Parser and Gherkin
[ https://issues.apache.org/jira/browse/TINKERPOP-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann reopened TINKERPOP-2695: - Assignee: (was: Florian Hockmann) Sorry, I accidentally closed the wrong issue. Reopening this one. > Support NaN/Inf in Parser and Gherkin > - > > Key: TINKERPOP-2695 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2695 > Project: TinkerPop > Issue Type: Improvement > Components: language >Affects Versions: 3.6.0 >Reporter: Mike Personick >Priority: Minor > Fix For: 3.6.0, 3.5.3 > > > Add support for NaN and Inf/-Inf in the parser and in the Gherkin test suite. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (TINKERPOP-2700) WebSocket compression may lead to attacks (CRIME / BREACH)
Florian Hockmann created TINKERPOP-2700: --- Summary: WebSocket compression may lead to attacks (CRIME / BREACH) Key: TINKERPOP-2700 URL: https://issues.apache.org/jira/browse/TINKERPOP-2700 Project: TinkerPop Issue Type: Improvement Components: driver, python Affects Versions: 3.5.2 Reporter: Florian Hockmann As noted in TINKERPOP-2682, WS compression can make an application vulnerable to attacks. That is why it should probably be disabled if an application sends sensitive data as well as data that could be controlled by a potentially untrusted user. So, we should make it possible for users to disable compression and inform about this problematic in our docs. We can optionally also disable compression ourselves for messages that contain an authentication response (that's how it's implemented right now for .NET in the PR for TINKERPOP-2682). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (TINKERPOP-2518) Enhance .NET gherkin framework to deal with more advanced assertions
[ https://issues.apache.org/jira/browse/TINKERPOP-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann reassigned TINKERPOP-2518: --- Assignee: Florian Hockmann > Enhance .NET gherkin framework to deal with more advanced assertions > > > Key: TINKERPOP-2518 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2518 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.5.0 >Reporter: Stephen Mallette >Assignee: Florian Hockmann >Priority: Major > > There are two pull requests which introduced some "ignores" for tests in .NET: > https://github.com/apache/tinkerpop/pull/1383 > https://github.com/apache/tinkerpop/pull/1387 > In both cases the Gremlin seems to work fine but the assertions aren't robust > enough in the framework to handle the results (i think). We should try to > settle this before 3.5.0 release. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (TINKERPOP-2689) VertexProperty Gherkin support for .NET
[ https://issues.apache.org/jira/browse/TINKERPOP-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann closed TINKERPOP-2689. --- Fix Version/s: 3.6.0 Resolution: Fixed > VertexProperty Gherkin support for .NET > --- > > Key: TINKERPOP-2689 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2689 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.6.0 >Reporter: Mike Personick >Priority: Minor > Fix For: 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (TINKERPOP-2688) Investigate two .NET test failures
[ https://issues.apache.org/jira/browse/TINKERPOP-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann closed TINKERPOP-2688. --- Fix Version/s: 3.6.0 Resolution: Fixed > Investigate two .NET test failures > -- > > Key: TINKERPOP-2688 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2688 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.6.0 >Reporter: Mike Personick >Priority: Minor > Fix For: 3.6.0 > > > Get these two (currently ignored) tests working in .NET: > [g_V_properties_order|https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Gherkin/GherkinTestRunner.cs#L88] > [g_V_properties_order_id|https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Gherkin/GherkinTestRunner.cs#L89] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (TINKERPOP-2682) Enable WebSocket compression in .NET by default
[
https://issues.apache.org/jira/browse/TINKERPOP-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann reassigned TINKERPOP-2682:
---
Assignee: Florian Hockmann
> Enable WebSocket compression in .NET by default
> ---
>
> Key: TINKERPOP-2682
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2682
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.5.1
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Minor
>
> .NET 6 added support for WebSocket compression to .NET:
> [https://devblogs.microsoft.com/dotnet/announcing-net-6/#websocket-compression]
> Users can already enable that by themselves as it has been added as a
> property {{DangerousDeflate}} to the {{ClientWebSocketOptions}} which can be
> configured via the {{webSocketConfiguration}} of the {{GremlinClient}}
> constructor in Gremlin.Net.
> Since we have enabled compression by default in Python and Java, it makes
> sense to also enable it by default in .NET. We can of course only do that for
> .NET 6 which is why we'll have to add that as an additional target framework
> to Gremlin.Net.
> The .NET 6 announcement mentions that WebSocket compression together with
> encrypted content is susceptible to attacks like CRIME and BREACH that can
> reveal the encrypted content if an attacker is able to control data that is
> sent together with the encrypted content over the same WebSocket connection.
> That is why the property to enable compression is called
> {_}Dangerous{_}Deflate and why compression can also be disabled on a
> per-message basis
> ([source|https://github.com/dotnet/runtime/issues/31088#issuecomment-804359919]).
> I suggest we can account for these possible attacks by disabling compression
> for the authentication messages we send to the server which contain
> credentials and by adding a note to the docs about this with a recommendation
> to disable compression if an application needs to send sensitive data, but
> also data controlled by (potentially untrusted) users to the server.
> Since the attacker additionally needs to be able to monitor the network
> traffic between the client and the server, I guess >99% of applications are
> not affected by this and will therefore benefit from enabling compression by
> default.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (TINKERPOP-2651) Update to .NET 6
[ https://issues.apache.org/jira/browse/TINKERPOP-2651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann closed TINKERPOP-2651. --- Fix Version/s: 3.6.0 3.5.2 Assignee: Florian Hockmann Resolution: Fixed > Update to .NET 6 > > > Key: TINKERPOP-2651 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2651 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.4.12, 3.5.1 >Reporter: Florian Hockmann >Assignee: Florian Hockmann >Priority: Minor > Fix For: 3.6.0, 3.5.2 > > > [.NET 6 was released on November > 8|https://devblogs.microsoft.com/dotnet/announcing-net-6/] and it is now the > latest LTS release. > This includes (at least) updates in these places: > * the Docker build > * GH Actions > * Updating the Gremlin.Net.Template > * the contributing docs > We need to do that on all release branches so contributors only need to have > one version of .NET installed on their systems. > We can optionally also improve the codebase by using newer language features > as a part of this. > This will also enable us to add support for nullable annotations / checks: > TINKERPOP-2348. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (TINKERPOP-2682) Enable WebSocket compression in .NET by default
Florian Hockmann created TINKERPOP-2682:
---
Summary: Enable WebSocket compression in .NET by default
Key: TINKERPOP-2682
URL: https://issues.apache.org/jira/browse/TINKERPOP-2682
Project: TinkerPop
Issue Type: Improvement
Components: dotnet
Affects Versions: 3.5.1
Reporter: Florian Hockmann
.NET 6 added support for WebSocket compression to .NET:
[https://devblogs.microsoft.com/dotnet/announcing-net-6/#websocket-compression]
Users can already enable that by themselves as it has been added as a property
{{DangerousDeflate}} to the {{ClientWebSocketOptions}} which can be configured
via the {{webSocketConfiguration}} of the {{GremlinClient}} constructor in
Gremlin.Net.
Since we have enabled compression by default in Python and Java, it makes sense
to also enable it by default in .NET. We can of course only do that for .NET 6
which is why we'll have to add that as an additional target framework to
Gremlin.Net.
The .NET 6 announcement mentions that WebSocket compression together with
encrypted content is susceptible to attacks like CRIME and BREACH that can
reveal the encrypted content if an attacker is able to control data that is
sent together with the encrypted content over the same WebSocket connection.
That is why the property to enable compression is called {_}Dangerous{_}Deflate
and why compression can also be disabled on a per-message basis
([source|https://github.com/dotnet/runtime/issues/31088#issuecomment-804359919]).
I suggest we can account for these possible attacks by disabling compression
for the authentication messages we send to the server which contain credentials
and by adding a note to the docs about this with a recommendation to disable
compression if an application needs to send sensitive data, but also data
controlled by (potentially untrusted) users to the server.
Since the attacker additionally needs to be able to monitor the network traffic
between the client and the server, I guess >99% of applications are not
affected by this and will therefore benefit from enabling compression by
default.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (TINKERPOP-2651) Update to .NET 6
[ https://issues.apache.org/jira/browse/TINKERPOP-2651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17469336#comment-17469336 ] Florian Hockmann commented on TINKERPOP-2651: - Just as a reminder: After updating to .NET 6, we can also update the System.Text.Json dependency to version 6. For more information, see [this comment|https://github.com/apache/tinkerpop/pull/1521#issuecomment-1005726077]. > Update to .NET 6 > > > Key: TINKERPOP-2651 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2651 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.4.12, 3.5.1 >Reporter: Florian Hockmann >Priority: Minor > > [.NET 6 was released on November > 8|https://devblogs.microsoft.com/dotnet/announcing-net-6/] and it is now the > latest LTS release. > This includes (at least) updates in these places: > * the Docker build > * GH Actions > * Updating the Gremlin.Net.Template > * the contributing docs > We need to do that on all release branches so contributors only need to have > one version of .NET installed on their systems. > We can optionally also improve the codebase by using newer language features > as a part of this. > This will also enable us to add support for nullable annotations / checks: > TINKERPOP-2348. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (TINKERPOP-2651) Update to .NET 6
[ https://issues.apache.org/jira/browse/TINKERPOP-2651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17445979#comment-17445979 ] Florian Hockmann commented on TINKERPOP-2651: - Yes, we support [.NET Standard 2.0 which is supported (/implemented) by|https://dotnet.microsoft.com/platform/dotnet-standard#versions] .NET Core 2.0 and higher (including .NET 5 and 6), .NET Framework 4.6.1 and higher, and Mono 5.4 and higher. This ticket is basically only to update the SDK (except for the Gremlin.Net.Template where it's also the target framework) that we use to build and test Gremlin.Net. I know this is confusing with all the different .NET Core, .NET Framework, .NET Standard, and now .NET versions. I hope that Microsoft really sticks to their plan to only go forward with .NET without any new .NET Core / Standard / Framework. > Update to .NET 6 > > > Key: TINKERPOP-2651 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2651 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.4.12, 3.5.1 >Reporter: Florian Hockmann >Priority: Minor > > [.NET 6 was released on November > 8|https://devblogs.microsoft.com/dotnet/announcing-net-6/] and it is now the > latest LTS release. > This includes (at least) updates in these places: > * the Docker build > * GH Actions > * Updating the Gremlin.Net.Template > * the contributing docs > We need to do that on all release branches so contributors only need to have > one version of .NET installed on their systems. > We can optionally also improve the codebase by using newer language features > as a part of this. > This will also enable us to add support for nullable annotations / checks: > TINKERPOP-2348. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (TINKERPOP-2651) Update to .NET 6
Florian Hockmann created TINKERPOP-2651: --- Summary: Update to .NET 6 Key: TINKERPOP-2651 URL: https://issues.apache.org/jira/browse/TINKERPOP-2651 Project: TinkerPop Issue Type: Improvement Components: dotnet Affects Versions: 3.5.1, 3.4.12 Reporter: Florian Hockmann [.NET 6 was released on November 8|https://devblogs.microsoft.com/dotnet/announcing-net-6/] and it is now the latest LTS release. This includes (at least) updates in these places: * the Docker build * GH Actions * Updating the Gremlin.Net.Template * the contributing docs We need to do that on all release branches so contributors only need to have one version of .NET installed on their systems. We can optionally also improve the codebase by using newer language features as a part of this. This will also enable us to add support for nullable annotations / checks: TINKERPOP-2348. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (TINKERPOP-2646) Make .NET StreamExtensions public for GraphBinary
[
https://issues.apache.org/jira/browse/TINKERPOP-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-2646.
---
Fix Version/s: 3.6.0
3.5.2
Assignee: Florian Hockmann
Resolution: Fixed
> Make .NET StreamExtensions public for GraphBinary
> -
>
> Key: TINKERPOP-2646
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2646
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.5.1
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Minor
> Fix For: 3.6.0, 3.5.2
>
>
> We added some extensions methods to the {{Stream}} class which are useful to
> implement GraphBinary serializers as that requires a lot of writing and
> reading of various types to streams:
> [https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Structure/IO/GraphBinary/StreamExtensions.cs]
> We should make these extensions public to make them accessible for users and
> driver providers for their own custom GraphBinary types.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (TINKERPOP-2646) Make .NET StreamExtensions public for GraphBinary
Florian Hockmann created TINKERPOP-2646:
---
Summary: Make .NET StreamExtensions public for GraphBinary
Key: TINKERPOP-2646
URL: https://issues.apache.org/jira/browse/TINKERPOP-2646
Project: TinkerPop
Issue Type: Improvement
Components: dotnet
Affects Versions: 3.5.1
Reporter: Florian Hockmann
We added some extensions methods to the {{Stream}} class which are useful to
implement GraphBinary serializers as that requires a lot of writing and reading
of various types to streams:
[https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Structure/IO/GraphBinary/StreamExtensions.cs]
We should make these extensions public to make them accessible for users and
driver providers for their own custom GraphBinary types.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (TINKERPOP-2378) Make C# DSL to be more closer to standard (lower case extensions)
[ https://issues.apache.org/jira/browse/TINKERPOP-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17434862#comment-17434862 ] Florian Hockmann commented on TINKERPOP-2378: - I agree with Stephen that having a PascalCase and a camelCase version of each step in C# would be confusing and would also pollute the code a lot. I'm also wondering whether that would really solve the problem you describe, [~dzmitry.lahoda], as you would still have to add generic type arguments in C# as they cannot be interfered from usage oftentimes even though it's possible in Java / Groovy. Overall, the approach we've taken with providing [Translators|https://tinkerpop.apache.org/docs/current/upgrade/#_translators] that can for example translate from Gremlin-Java into Gremlin.NET seems to be the better solution for this kind of workflow in my opinion. We already have a translator in Java to do this and TINKERPOP-2367 addresses implementing this also in .NET. So my take here would be to close this as _Won't do_ but I'm of course also open for other suggestions/arguments if others think that this might be a good addition to Gremlin.NET / GLVs in general (although Gremlin.NET is currently mostly affected by this). > Make C# DSL to be more closer to standard (lower case extensions) > -- > > Key: TINKERPOP-2378 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2378 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.4.6 >Reporter: Dzmitry.Lahoda >Priority: Minor > Labels: c#, dot_net, dsl, generator > Original Estimate: 72h > Remaining Estimate: 72h > > Usually, I prototype queries via gremlin console or azure cosmos console. I > use first small letter in traversal steps. For example, 'outE`. Porting to > strongly typed DSL requires to update all lower case steps into upper. Like, > 'OutE`. It is very tedious process. Could we have `outE` and `OutE` > projections for C#? It would make my life much more pleasant and C# closer to > Gremlin standard. All such cases of differences do apply. C# has extensions > and static using and case sensitive and dynamic. So most stuff in place to > make C# to Groovy almost one to one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2556) Support remote transactions in .NET
[
https://issues.apache.org/jira/browse/TINKERPOP-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-2556.
---
Fix Version/s: 3.5.2
3.6.0
Resolution: Fixed
> Support remote transactions in .NET
> ---
>
> Key: TINKERPOP-2556
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2556
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.5.0
>Reporter: Stephen Mallette
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.6.0, 3.5.2
>
>
> TINKERPOP-2537 introduced remote transactions with {{g.tx()}} for use with
> Java. The same functionality should be made available in .NET.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-1853) Use generic version of ITraversal for arguments in Traversal API
[
https://issues.apache.org/jira/browse/TINKERPOP-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17431251#comment-17431251
]
Florian Hockmann commented on TINKERPOP-1853:
-
I've spent some time working on this but now I'm not sure any more whether it's
actually feasible to get a working implementation that still allows the
{{DotNetTranslator}} to produce valid C# traversals. One example where I
noticed this in our test suite is this overload:
{code:c#}
public GraphTraversal To (ITraversal toVertex) {code}
which I would now like to change into:
{code:c#}
public GraphTraversal To (ITraversal toVertex) {code}
I think that is a nice improvement for most use cases as it still allows
something like {{To(__.V())}} or {{To(__.AddV())}} but we cannot produce
working code with the translator for something like {{to(__.select('v'))}} as
the translator would need to translate this into
{{To(__.Select('v'))}}. However, I don't know how we could change the
translator to use the correct generic type parameter for {{Select}} here
without making it a lot more complex. (Right now, it always uses {{object}} as
the type parameter which works without these changes.) It would at least need
to inspect what kind of type the outer step needs (here {{To()}} needs an
{{ITraversal}}). The translator however only operates on {{Bytecode}}
which doesn't have such type information.
This is now only for the {{To()}} step but I think that the same could apply
for most if not all steps that take a traversal as an argument.
While this seems to be a nice improvement in my opinion as it would reduce the
need to provide generic type parameters in some places and make it harder to
produce invalid {{Bytecode}} from Gremlin.NET, I'm not sure any more if it's
really worth the effort given the problems with the {{DotNetTranslator}}. I'm
however open for any suggestions here. So, I pushed my current changes which at
least result in a clean build as a WIP here:
[https://github.com/apache/tinkerpop/tree/TINKERPOP-1853]
If nobody has a good idea how the problem with the code translation could be
solved, then I'll probably close this as _won't do_.
> Use generic version of ITraversal for arguments in Traversal API
>
>
> Key: TINKERPOP-1853
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1853
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.3.0, 3.2.6
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Minor
>
> Currently, we use {{ITraversal}} as the type for arguments in the traversal
> API of Gremlin.Net when a traversal is expected:
> {code}
> public GraphTraversal< S , E2 > Choose (ITraversal traversalPredicate,
> ITraversal trueChoice)
> {code}
> The Java equivalent is more useful as it only allows {{Traversal}} for
> the second argument:
> {code}
> public default GraphTraversal choose(final Traversal
> traversalPredicate, final Traversal trueChoice)
> {code}
> We should also use the generic type {{ITraversal}} in Gremlin.Net
> in those cases. Then it wouldn't be necessary to specify the type for the
> arguments and the step as it can be interfered from the type of the arguments.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (TINKERPOP-2556) Support remote transactions in .NET
[
https://issues.apache.org/jira/browse/TINKERPOP-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann reassigned TINKERPOP-2556:
---
Assignee: Florian Hockmann
> Support remote transactions in .NET
> ---
>
> Key: TINKERPOP-2556
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2556
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.5.0
>Reporter: Stephen Mallette
>Assignee: Florian Hockmann
>Priority: Major
>
> TINKERPOP-2537 introduced remote transactions with {{g.tx()}} for use with
> Java. The same functionality should be made available in .NET.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (TINKERPOP-1853) Use generic version of ITraversal for arguments in Traversal API
[
https://issues.apache.org/jira/browse/TINKERPOP-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann reassigned TINKERPOP-1853:
---
Assignee: Florian Hockmann
> Use generic version of ITraversal for arguments in Traversal API
>
>
> Key: TINKERPOP-1853
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1853
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.3.0, 3.2.6
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Minor
>
> Currently, we use {{ITraversal}} as the type for arguments in the traversal
> API of Gremlin.Net when a traversal is expected:
> {code}
> public GraphTraversal< S , E2 > Choose (ITraversal traversalPredicate,
> ITraversal trueChoice)
> {code}
> The Java equivalent is more useful as it only allows {{Traversal}} for
> the second argument:
> {code}
> public default GraphTraversal choose(final Traversal
> traversalPredicate, final Traversal trueChoice)
> {code}
> We should also use the generic type {{ITraversal}} in Gremlin.Net
> in those cases. Then it wouldn't be necessary to specify the type for the
> arguments and the step as it can be interfered from the type of the arguments.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-1853) Use generic version of ITraversal for arguments in Traversal API
[
https://issues.apache.org/jira/browse/TINKERPOP-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416473#comment-17416473
]
Florian Hockmann commented on TINKERPOP-1853:
-
I still think that this would improve the usability of Gremlin.NET. I guess I
never implemented this because I didn't want to mess more with the old code
generation logic we had that was already quite complicated. But given that we
now don't generate the code any more, I want to look into how much work it
would be to address this manually. But if I come to the conclusion that it's
too much work for now, then I'll close the issue as it's already nearly 4 years
old and we don't have to keep it forever without actually implementing anything.
> Use generic version of ITraversal for arguments in Traversal API
>
>
> Key: TINKERPOP-1853
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1853
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.3.0, 3.2.6
>Reporter: Florian Hockmann
>Priority: Minor
>
> Currently, we use {{ITraversal}} as the type for arguments in the traversal
> API of Gremlin.Net when a traversal is expected:
> {code}
> public GraphTraversal< S , E2 > Choose (ITraversal traversalPredicate,
> ITraversal trueChoice)
> {code}
> The Java equivalent is more useful as it only allows {{Traversal}} for
> the second argument:
> {code}
> public default GraphTraversal choose(final Traversal
> traversalPredicate, final Traversal trueChoice)
> {code}
> We should also use the generic type {{ITraversal}} in Gremlin.Net
> in those cases. Then it wouldn't be necessary to specify the type for the
> arguments and the step as it can be interfered from the type of the arguments.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2570) Support custom type in GraphBinary for .NET
[
https://issues.apache.org/jira/browse/TINKERPOP-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-2570.
---
Fix Version/s: 3.5.2
3.6.0
Assignee: Florian Hockmann
Resolution: Fixed
> Support custom type in GraphBinary for .NET
> ---
>
> Key: TINKERPOP-2570
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2570
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.5.0
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.6.0, 3.5.2
>
>
> 3.5.0 added GraphBinary for Gremlin.NET but I forgot to add support for the
> [{{Custom}} type|https://tinkerpop.apache.org/docs/3.5.0/dev/io/#_custom]
> which allows users / providers to implement serializers for their own types.
> We should add that type so users and providers can implement their own
> serializers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2556) Support remote transactions in .NET
[
https://issues.apache.org/jira/browse/TINKERPOP-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17413157#comment-17413157
]
Florian Hockmann commented on TINKERPOP-2556:
-
{quote}Few providers are on 3.5.0 yet so perhaps it's a non-issue for them at
this stage.
{quote}
Oh right, I didn't think about that. So, we probably can still target 3.5.x for
this.
I started a DISCUSS thread as you suggested:
[https://lists.apache.org/thread.html/r04afd845357c191d018d0202e5e370633840ad3e83e7c7abefba58cd%40%3Cdev.tinkerpop.apache.org%3E]
> Support remote transactions in .NET
> ---
>
> Key: TINKERPOP-2556
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2556
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.5.0
>Reporter: Stephen Mallette
>Priority: Major
>
> TINKERPOP-2537 introduced remote transactions with {{g.tx()}} for use with
> Java. The same functionality should be made available in .NET.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2556) Support remote transactions in .NET
[
https://issues.apache.org/jira/browse/TINKERPOP-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17412977#comment-17412977
]
Florian Hockmann commented on TINKERPOP-2556:
-
Yes, exactly. This would of course affect graph providers who implemented their
own driver, but I think only one provider did that which is DataStax. Users
could however also be affected if they for example implemented the interface in
their tests to get a fake remote connection.
Do you think that we should still do it in 3.5 then?
> Support remote transactions in .NET
> ---
>
> Key: TINKERPOP-2556
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2556
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.5.0
>Reporter: Stephen Mallette
>Priority: Major
>
> TINKERPOP-2537 introduced remote transactions with {{g.tx()}} for use with
> Java. The same functionality should be made available in .NET.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2556) Support remote transactions in .NET
[
https://issues.apache.org/jira/browse/TINKERPOP-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17412563#comment-17412563
]
Florian Hockmann commented on TINKERPOP-2556:
-
I wanted to start working on this today but quickly ran into a problem: It
looks like we need to extend the [{{IRemoteConnection}}
interface|https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Process/Remote/IRemoteConnection.cs]
for this to support transactions (the Java version has a {{tx()}} method, the
JS version has {{createSession()}}, {{commit()}}, and {{rollback()}}), but this
would be a breaking change. Unfortunately, we also cannot use [default
implementations|https://devblogs.microsoft.com/dotnet/default-implementations-in-interfaces/]
yet which would remedy this as we could simply throw an exception about
transactions not being supported by default, as those are only available since
.NET Standard 2.1 / .NET Core 3.0 and we are still on .NET Standard 2.0.
Dropping support for .NET Standard 2.0 would be an even bigger breaking change.
So, I think that we will only be able to add this with 3.6.0 for .NET.
> Support remote transactions in .NET
> ---
>
> Key: TINKERPOP-2556
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2556
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.5.0
>Reporter: Stephen Mallette
>Priority: Major
>
> TINKERPOP-2537 introduced remote transactions with {{g.tx()}} for use with
> Java. The same functionality should be made available in .NET.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (TINKERPOP-2614) Gremlin.NET should throw if already iterated traversal gets modulated
Florian Hockmann created TINKERPOP-2614:
---
Summary: Gremlin.NET should throw if already iterated traversal
gets modulated
Key: TINKERPOP-2614
URL: https://issues.apache.org/jira/browse/TINKERPOP-2614
Project: TinkerPop
Issue Type: Improvement
Components: dotnet
Affects Versions: 3.5.1, 3.4.12
Reporter: Florian Hockmann
It is not possible to modulate a traversal that was already iterated.
Gremlin-Java makes that clear by throwing an exception:
{code:java}
gremlin> t = g.V().has('test','test'); []
gremlin> t.hasNext()
==>true
gremlin> t.property('test','test').iterate()
The traversal strategies are complete and the traversal can no longer be
modulated
{code}
Gremlin.NET however does not throw an exception which can be confusing as users
might expect this to work.
This problem was reported by a user on SO:
[https://stackoverflow.com/q/69031410/6753576]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2358) Potential connection leak on client disposing
[ https://issues.apache.org/jira/browse/TINKERPOP-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann closed TINKERPOP-2358. --- Fix Version/s: 3.6.0 3.5.1 3.4.12 Resolution: Fixed > Potential connection leak on client disposing > - > > Key: TINKERPOP-2358 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2358 > Project: TinkerPop > Issue Type: Bug > Components: dotnet >Affects Versions: 3.4.6 >Reporter: Dzmitry L >Assignee: Florian Hockmann >Priority: Minor > Fix For: 3.4.12, 3.5.1, 3.6.0 > > > Potential issue may happen if you decide to call "Dispose" on a client while > "PopulatePoolAsync" is active. "Dispose" closes all connections from the > pool, but does not stop "PopulatePoolAsync". So after "PopulatePoolAsync" > finish you will have unclosed connections. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2581) Gremlin.NET throwing an exception when having to deserialize Numbers in edges
[
https://issues.apache.org/jira/browse/TINKERPOP-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17364911#comment-17364911
]
Florian Hockmann commented on TINKERPOP-2581:
-
Looks like I misunderstood your issue description. I thought that you only ran
into this problem by using GraphSON 3 and that using GraphSON 2 already fixed
it, but you really meant that it would be possible to work around this by
extending from {{GraphSON2Reader}}.
This makes it of course worse for Cosmos DB users, but your conclusion seems
correct to me. It has only worked so far with Gremlin.NET because it was too
lax and allowed non-typed values in GraphSON 2. If Cosmos DB sends non-typed
numerical values back, then that's a bug in Cosmos DB. Your best option is
probably to create them a ticket to notify them about this problem. Otherwise,
Cosmos DB users won't be able to update to newer Gremlin.NET versions.
> Gremlin.NET throwing an exception when having to deserialize Numbers in edges
> -
>
> Key: TINKERPOP-2581
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2581
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.5.0
> Environment: Azure CosmosDB graph
>Reporter: Fredy
>Priority: Major
>
> We use Gremlin.NET against a CosmosDB graph and have upgraded our projects
> from 3.4.10 to 3.5.0 which I understand changed serialization to use
> System.Text.Json.
> We discovered that many of our queries that ended up retrieving edges were
> failing with the following ArgumentOutOfRangeException exception:
> {code:java}
> JSON type not supported.Parameter name: ValueKindActual value was Number.
> {code}
>
> We determined this happens for queries retrieving edges that have Number type
> JSON properties, most likely because Number is not considered in the ToObject
> method:
> [https://github.com/apache/tinkerpop/blob/a7181e23421818948de3624743d79361524c0013/gremlin-dotnet/src/Gremlin.Net/Structure/IO/GraphSON/GraphSONReader.cs#L103]
>
> A workaround that seems to work is instantiate our Gremlin.NET client with a
> subclass of GraphSON2Reader that accounts for this, but for the time being
> we've decided to rollback the update instead.
>
> Here's some code that triggers the issue, at least when using the CosmosDB
> backend which is what we use:
> {code:java}
> using Gremlin.Net.Driver;
> using Gremlin.Net.Structure.IO.GraphSON;
> using System;
> using System.Text.Json;
> using System.Threading.Tasks;namespace GremlinNetTest
> {
> class Program
> {
> static async Task Main(string[] _)
> {
> var (hostname, port, username, password) = (
> "",
> 443,
> "",
> ""
> );
> var server = new GremlinServer(hostname, port, enableSsl: true,
> username, password);
> var client = new GremlinClient(server, new
> GraphSON2MessageSerializer(new GraphSON2Reader(), new GraphSON2Writer()));
> // Create vertexes.
> var (v1Id, v2Id) = (Guid.NewGuid().ToString(),
> Guid.NewGuid().ToString());
> await
> client.SubmitAsync($"g.addV('item').property('id','{v1Id}').property('pk','0')");
> await
> client.SubmitAsync($"g.addV('item').property('id','{v2Id}').property('pk','0')");
> // Create edge with string property works.
> await
> client.SubmitAsync($"g.V(['0','{v1Id}']).addE('works').to(g.V(['0','{v2Id}'])).property('hello','world')");
> // Create edge with number property fails to deserialize result.
> // ** FAILS **
> await
> client.SubmitAsync($"g.V(['0','{v1Id}']).addE('fails').to(g.V(['0','{v2Id}'])).property('number',
> 1)");
> await
> client.SubmitAsync($"g.V(['0','{v1Id}']).addE('fails').to(g.V(['0','{v2Id}'])).property('long',
> 3147483647)");
> await
> client.SubmitAsync($"g.V(['0','{v1Id}']).addE('fails').to(g.V(['0','{v2Id}'])).property('decimal',
> 1.5)");
> // ** /FAILS **// Create edge with number property
> works to deserialize result with custom reader.
> var clientWithCustomReader = new GremlinClient(server, new
> GraphSON2MessageSerializer(new CustomReader(), new GraphSON2Writer()));
> await
> clientWithCustomReader.SubmitAsync($"g.V(['0','{v1Id}']).addE('works').to(g.V(['0','{v2Id}'])).property('number',
> 1)");
> await
> clientWithCustomReader.SubmitAsync($"g.V(['0','{v1Id}']).addE('works').to(g.V(['0','{v2Id}'])).property('long',
> 3147483647)");
> await
> clientWithCustomReader.SubmitAsync($"g.V(['0','{v1Id}']).addE('works').to(g.V(['0','{v2Id}'])).property('decimal',
[jira] [Closed] (TINKERPOP-2581) Gremlin.NET throwing an exception when having to deserialize Numbers in edges
[
https://issues.apache.org/jira/browse/TINKERPOP-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-2581.
---
Resolution: Not A Bug
> Gremlin.NET throwing an exception when having to deserialize Numbers in edges
> -
>
> Key: TINKERPOP-2581
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2581
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.5.0
> Environment: Azure CosmosDB graph
>Reporter: Fredy
>Priority: Major
>
> We use Gremlin.NET against a CosmosDB graph and have upgraded our projects
> from 3.4.10 to 3.5.0 which I understand changed serialization to use
> System.Text.Json.
> We discovered that many of our queries that ended up retrieving edges were
> failing with the following ArgumentOutOfRangeException exception:
> {code:java}
> JSON type not supported.Parameter name: ValueKindActual value was Number.
> {code}
>
> We determined this happens for queries retrieving edges that have Number type
> JSON properties, most likely because Number is not considered in the ToObject
> method:
> [https://github.com/apache/tinkerpop/blob/a7181e23421818948de3624743d79361524c0013/gremlin-dotnet/src/Gremlin.Net/Structure/IO/GraphSON/GraphSONReader.cs#L103]
>
> A workaround that seems to work is instantiate our Gremlin.NET client with a
> subclass of GraphSON2Reader that accounts for this, but for the time being
> we've decided to rollback the update instead.
>
> Here's some code that triggers the issue, at least when using the CosmosDB
> backend which is what we use:
> {code:java}
> using Gremlin.Net.Driver;
> using Gremlin.Net.Structure.IO.GraphSON;
> using System;
> using System.Text.Json;
> using System.Threading.Tasks;namespace GremlinNetTest
> {
> class Program
> {
> static async Task Main(string[] _)
> {
> var (hostname, port, username, password) = (
> "",
> 443,
> "",
> ""
> );
> var server = new GremlinServer(hostname, port, enableSsl: true,
> username, password);
> var client = new GremlinClient(server, new
> GraphSON2MessageSerializer(new GraphSON2Reader(), new GraphSON2Writer()));
> // Create vertexes.
> var (v1Id, v2Id) = (Guid.NewGuid().ToString(),
> Guid.NewGuid().ToString());
> await
> client.SubmitAsync($"g.addV('item').property('id','{v1Id}').property('pk','0')");
> await
> client.SubmitAsync($"g.addV('item').property('id','{v2Id}').property('pk','0')");
> // Create edge with string property works.
> await
> client.SubmitAsync($"g.V(['0','{v1Id}']).addE('works').to(g.V(['0','{v2Id}'])).property('hello','world')");
> // Create edge with number property fails to deserialize result.
> // ** FAILS **
> await
> client.SubmitAsync($"g.V(['0','{v1Id}']).addE('fails').to(g.V(['0','{v2Id}'])).property('number',
> 1)");
> await
> client.SubmitAsync($"g.V(['0','{v1Id}']).addE('fails').to(g.V(['0','{v2Id}'])).property('long',
> 3147483647)");
> await
> client.SubmitAsync($"g.V(['0','{v1Id}']).addE('fails').to(g.V(['0','{v2Id}'])).property('decimal',
> 1.5)");
> // ** /FAILS **// Create edge with number property
> works to deserialize result with custom reader.
> var clientWithCustomReader = new GremlinClient(server, new
> GraphSON2MessageSerializer(new CustomReader(), new GraphSON2Writer()));
> await
> clientWithCustomReader.SubmitAsync($"g.V(['0','{v1Id}']).addE('works').to(g.V(['0','{v2Id}'])).property('number',
> 1)");
> await
> clientWithCustomReader.SubmitAsync($"g.V(['0','{v1Id}']).addE('works').to(g.V(['0','{v2Id}'])).property('long',
> 3147483647)");
> await
> clientWithCustomReader.SubmitAsync($"g.V(['0','{v1Id}']).addE('works').to(g.V(['0','{v2Id}'])).property('decimal',
> 1.5)");
> }
> }public class CustomReader : GraphSON2Reader
> {
> public override dynamic ToObject(JsonElement graphSon)
> {
> if (graphSon.ValueKind == JsonValueKind.Number)
> {
> if (graphSon.TryGetInt32(out int intValue)) return intValue;
> if (graphSon.TryGetInt64(out long longValue)) return
> longValue;
> if (graphSon.TryGetDecimal(out decimal decimalValue)) return
> decimalValue;
> }
> return base.ToObject(graphSon);
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2581) Gremlin.NET throwing an exception when having to deserialize Numbers in edges
[
https://issues.apache.org/jira/browse/TINKERPOP-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17364895#comment-17364895
]
Florian Hockmann commented on TINKERPOP-2581:
-
This sounds to me like Cosmos DB didn't send a valid GraphSON 3 message as
[GraphSON 3
specifies|https://tinkerpop.apache.org/docs/current/dev/io/#_integer_2] that
numerical types should be serialized like an object. The Cosmos DB docs also
still [mention that they don't support GraphSON
3|https://docs.microsoft.com/en-us/azure/cosmos-db/gremlin-support#unsupported-features].
So, this is not a bug in Gremlin.NET but a known limitation of Cosmos DB.
> Gremlin.NET throwing an exception when having to deserialize Numbers in edges
> -
>
> Key: TINKERPOP-2581
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2581
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.5.0
> Environment: Azure CosmosDB graph
>Reporter: Fredy
>Priority: Major
>
> We use Gremlin.NET against a CosmosDB graph and have upgraded our projects
> from 3.4.10 to 3.5.0 which I understand changed serialization to use
> System.Text.Json.
> We discovered that many of our queries that ended up retrieving edges were
> failing with the following ArgumentOutOfRangeException exception:
> {code:java}
> JSON type not supported.Parameter name: ValueKindActual value was Number.
> {code}
>
> We determined this happens for queries retrieving edges that have Number type
> JSON properties, most likely because Number is not considered in the ToObject
> method:
> [https://github.com/apache/tinkerpop/blob/a7181e23421818948de3624743d79361524c0013/gremlin-dotnet/src/Gremlin.Net/Structure/IO/GraphSON/GraphSONReader.cs#L103]
>
> A workaround that seems to work is instantiate our Gremlin.NET client with a
> subclass of GraphSON2Reader that accounts for this, but for the time being
> we've decided to rollback the update instead.
>
> Here's some code that triggers the issue, at least when using the CosmosDB
> backend which is what we use:
> {code:java}
> using Gremlin.Net.Driver;
> using Gremlin.Net.Structure.IO.GraphSON;
> using System;
> using System.Text.Json;
> using System.Threading.Tasks;namespace GremlinNetTest
> {
> class Program
> {
> static async Task Main(string[] _)
> {
> var (hostname, port, username, password) = (
> "",
> 443,
> "",
> ""
> );
> var server = new GremlinServer(hostname, port, enableSsl: true,
> username, password);
> var client = new GremlinClient(server, new
> GraphSON2MessageSerializer(new GraphSON2Reader(), new GraphSON2Writer()));
> // Create vertexes.
> var (v1Id, v2Id) = (Guid.NewGuid().ToString(),
> Guid.NewGuid().ToString());
> await
> client.SubmitAsync($"g.addV('item').property('id','{v1Id}').property('pk','0')");
> await
> client.SubmitAsync($"g.addV('item').property('id','{v2Id}').property('pk','0')");
> // Create edge with string property works.
> await
> client.SubmitAsync($"g.V(['0','{v1Id}']).addE('works').to(g.V(['0','{v2Id}'])).property('hello','world')");
> // Create edge with number property fails to deserialize result.
> // ** FAILS **
> await
> client.SubmitAsync($"g.V(['0','{v1Id}']).addE('fails').to(g.V(['0','{v2Id}'])).property('number',
> 1)");
> await
> client.SubmitAsync($"g.V(['0','{v1Id}']).addE('fails').to(g.V(['0','{v2Id}'])).property('long',
> 3147483647)");
> await
> client.SubmitAsync($"g.V(['0','{v1Id}']).addE('fails').to(g.V(['0','{v2Id}'])).property('decimal',
> 1.5)");
> // ** /FAILS **// Create edge with number property
> works to deserialize result with custom reader.
> var clientWithCustomReader = new GremlinClient(server, new
> GraphSON2MessageSerializer(new CustomReader(), new GraphSON2Writer()));
> await
> clientWithCustomReader.SubmitAsync($"g.V(['0','{v1Id}']).addE('works').to(g.V(['0','{v2Id}'])).property('number',
> 1)");
> await
> clientWithCustomReader.SubmitAsync($"g.V(['0','{v1Id}']).addE('works').to(g.V(['0','{v2Id}'])).property('long',
> 3147483647)");
> await
> clientWithCustomReader.SubmitAsync($"g.V(['0','{v1Id}']).addE('works').to(g.V(['0','{v2Id}'])).property('decimal',
> 1.5)");
> }
> }public class CustomReader : GraphSON2Reader
> {
> public override dynamic ToObject(JsonElement graphSon)
> {
> if (graphSon.ValueKind == JsonValueKind.Number)
> {
> if (graphSon.
[jira] [Closed] (TINKERPOP-2577) Remove unused test coverage dependencies from Gremlin.NET
[ https://issues.apache.org/jira/browse/TINKERPOP-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann closed TINKERPOP-2577. --- Fix Version/s: 3.6.0 3.5.1 3.4.12 Assignee: Florian Hockmann Resolution: Fixed > Remove unused test coverage dependencies from Gremlin.NET > - > > Key: TINKERPOP-2577 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2577 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.5.0 >Reporter: Florian Hockmann >Assignee: Florian Hockmann >Priority: Trivial > Fix For: 3.4.12, 3.5.1, 3.6.0 > > > Dependabot just created two PRs to update test dependencies in Gremlin.NET > that are still leftovers from the pre-TinkerPop days of Gremlin.NET and that > we haven't used since then (at least not that I know of): > [https://github.com/apache/tinkerpop/pull/1429] > [https://github.com/apache/tinkerpop/pull/1430] > We should simply remove these two dependencies to clean the test projects up. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TINKERPOP-2577) Remove unused test coverage dependencies from Gremlin.NET
Florian Hockmann created TINKERPOP-2577: --- Summary: Remove unused test coverage dependencies from Gremlin.NET Key: TINKERPOP-2577 URL: https://issues.apache.org/jira/browse/TINKERPOP-2577 Project: TinkerPop Issue Type: Improvement Components: dotnet Affects Versions: 3.5.0 Reporter: Florian Hockmann Dependabot just created two PRs to update test dependencies in Gremlin.NET that are still leftovers from the pre-TinkerPop days of Gremlin.NET and that we haven't used since then (at least not that I know of): [https://github.com/apache/tinkerpop/pull/1429] [https://github.com/apache/tinkerpop/pull/1430] We should simply remove these two dependencies to clean the test projects up. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2576) Setup automatic updates via Dependabot for Gremlin.NET
[
https://issues.apache.org/jira/browse/TINKERPOP-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-2576.
---
Fix Version/s: 3.6.0
3.5.1
Assignee: Florian Hockmann
Resolution: Fixed
> Setup automatic updates via Dependabot for Gremlin.NET
> --
>
> Key: TINKERPOP-2576
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2576
> Project: TinkerPop
> Issue Type: Improvement
> Components: build-release, dotnet
>Affects Versions: 3.5.0
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.5.1, 3.6.0
>
>
> We had [some discussions in the
> past|https://lists.apache.org/thread.html/1cc0a5d79c3c66b6294c5f27c40c440df761e64e723732d058f114b6%40%3Cdev.tinkerpop.apache.org%3E]
> already about Dependabot. One of the problems that we had with it was that
> we mainly wanted to enable it for the GLVs like Gremlin.NET but we used to
> generate the {{.csproj}} file for that from a template so Dependabot couldn't
> create meaningful PRs as it would not update the template.
> Since we have already removed this generation on {{3.5-dev}} and {{master}},
> we can now set up Dependabot for these two branches.
> I want to start using Dependabot for Gremlin.NET but we can of course later
> on also use it for other parts if we want to.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (TINKERPOP-2576) Setup automatic updates via Dependabot for Gremlin.NET
Florian Hockmann created TINKERPOP-2576:
---
Summary: Setup automatic updates via Dependabot for Gremlin.NET
Key: TINKERPOP-2576
URL: https://issues.apache.org/jira/browse/TINKERPOP-2576
Project: TinkerPop
Issue Type: Improvement
Components: dotnet
Reporter: Florian Hockmann
We had [some discussions in the
past|https://lists.apache.org/thread.html/1cc0a5d79c3c66b6294c5f27c40c440df761e64e723732d058f114b6%40%3Cdev.tinkerpop.apache.org%3E]
already about Dependabot. One of the problems that we had with it was that we
mainly wanted to enable it for the GLVs like Gremlin.NET but we used to
generate the {{.csproj}} file for that from a template so Dependabot couldn't
create meaningful PRs as it would not update the template.
Since we have already removed this generation on {{3.5-dev}} and {{master}}, we
can now set up Dependabot for these two branches.
I want to start using Dependabot for Gremlin.NET but we can of course later on
also use it for other parts if we want to.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2573) Gremlin.NET: Retry on CreateNewConnectionAsync() failures and avoid disposing successful connections on a failure
[
https://issues.apache.org/jira/browse/TINKERPOP-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17356410#comment-17356410
]
Florian Hockmann commented on TINKERPOP-2573:
-
Thanks for reporting this and giving your thoughts on how we could improve
this, [~olivertowers]!
{quote}Gremlin server configurations can include a load-balancer in-front of
the server nodes (Azure Cosmos DB is one example).
{quote}
That is definitely something that we haven't accounted for enough. The driver
was originally built with the idea that a {{ConnectionPool}} holds connections
to a single server. TINKERPOP-1765 should add support for multiple servers and
then each server could have its own {{ConnectionPool}}. That's also how the
Java driver operates if I'm not mistaken. But that of course doesn't help if
multiple servers are behind a load balancer which is a setup that is getting
more and more common in cloud environments or with containers in general.
{quote}1. Modify {{FillPoolAsync}} to handle connection failures individually,
doing 'best-effort' replacement of missing connections.
2 If {{FillPoolAsync}} observes an exception, still throw but do not dispose
of connection tasks that were successful (and check that state of those
successful connections and dispose if they are in error?).
{quote}
Aren't these two points basically the same? We could solve this by iterating
over all connection tasks in the {{catch}} block, adding all connections from
successfully finished tasks (maybe after also checking their connection state)
to the pool and then throwing the exception.
This would of course leave the pool in a state where it doesn't have its
configured size, but the missing connections can still be added later, e.g.,
through the retry policy as you also already mentioned.
{quote}3. In ConnectionPool constructor, apply reconnect retry policy to
ReplaceDeadConnectionAsync() invocation
{quote}
I'm not sure about this one yet. If the server is already unavailable when the
user creates a {{GremlinClient}}, then I think that it's best to fail fast to
inform the user about the problem. I think it's more likely in this case that
the user supplied invalid connection parameters or that the server is
completely unreachable (e.g., due to a missing firewall exception) than a
transient error where a retry policy could help.
I also would like to avoid that calling a constructor can take a long time.
Creating the connections in the constructor of course also already takes some
time and is beyond of what a constructor should usually do. Maybe we could move
this logic in some {{ConnectAsync}} method in the future. That method could be
a static factory method and we could then make the constructor private, but
that would of course be a breaking change so it would have to wait for 3.6.0.
These are the two reasons I see against a retry policy in the constructor, but
I'm also not completely against this. Do you frequently see the situation where
calling the constructor throws due to a transient error or maybe an error with
just one of many servers behind a load balancer?
{quote}To allow the underlying errors to be observed by callers, a
callback/event handler could be added that is invoked in the
{{ReplaceClosedConnectionsAsync}} throws. This would allow for the any
exceptions to be observed and collected in some manner.
{quote}
That's true. My take so far was that we should add logging to the driver
(TINKERPOP-2471) to make things like these transparent to the user. Do you
think that callbacks / an event handler would be a better approach than
logging? I think logging would be a lot easier to use as users would only have
to provide a logger.
{quote}Further refinement of this: Have a way of populating
{{ServerUnavailableException}} inner exception with the last observed
replacement exception.
{quote}
Interesting idea. We currently don't do that as the connection replacement is
handled asynchronously in the background by a different task, but we could of
course save the last thrown exception and use that as the inner exception.
> Gremlin.NET: Retry on CreateNewConnectionAsync() failures and avoid disposing
> successful connections on a failure
> -
>
> Key: TINKERPOP-2573
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2573
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.4.11
>Reporter: Oliver Towers
>Priority: Minor
>
> [FillPoolAsync|https://github.com/apache/tinkerpop/blob/dc4a5d8795e836a35ce4b61247b9693fa0cea8cb/gremlin-dotnet/src/Gremlin.Net/Driver/ConnectionPool.cs#L119]
> attempts to create connections to fill the pool up to the target
> {
[jira] [Assigned] (TINKERPOP-2358) Potential connection leak on client disposing
[ https://issues.apache.org/jira/browse/TINKERPOP-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann reassigned TINKERPOP-2358: --- Assignee: Florian Hockmann > Potential connection leak on client disposing > - > > Key: TINKERPOP-2358 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2358 > Project: TinkerPop > Issue Type: Bug > Components: dotnet >Affects Versions: 3.4.6 >Reporter: Dzmitry L >Assignee: Florian Hockmann >Priority: Minor > > Potential issue may happen if you decide to call "Dispose" on a client while > "PopulatePoolAsync" is active. "Dispose" closes all connections from the > pool, but does not stop "PopulatePoolAsync". So after "PopulatePoolAsync" > finish you will have unclosed connections. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TINKERPOP-2570) Support custom type in GraphBinary for .NET
Florian Hockmann created TINKERPOP-2570:
---
Summary: Support custom type in GraphBinary for .NET
Key: TINKERPOP-2570
URL: https://issues.apache.org/jira/browse/TINKERPOP-2570
Project: TinkerPop
Issue Type: Improvement
Components: dotnet
Affects Versions: 3.5.0
Reporter: Florian Hockmann
3.5.0 added GraphBinary for Gremlin.NET but I forgot to add support for the
[{{Custom}} type|https://tinkerpop.apache.org/docs/3.5.0/dev/io/#_custom] which
allows users / providers to implement serializers for their own types.
We should add that type so users and providers can implement their own
serializers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2348) Enable nullable checks
[
https://issues.apache.org/jira/browse/TINKERPOP-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17347428#comment-17347428
]
Florian Hockmann commented on TINKERPOP-2348:
-
I have a branch ready that implements nullable checks for Gremlin.Net:
[https://github.com/apache/tinkerpop/tree/TINKERPOP-2348]
Introducing the nullable checks however comes with some small breaking changes.
I expect that these breaking changes should not affect 99% of the users but
they are still breaking changes.
On top of that, the change requires to additionally target .NET 5 to be able to
use nullable annotations for generics which we use a lot. This requires
contributors to also install .NET 5 on their machines. We currently try to
require the same .NET SDK across all branches so we would have to update all
branches to .NET 5 first. I'm not sure if that makes sense right now as .NET 5
is not a LTS release so we probably want to wait for the release of the next
LTS release, .NET 6, which is expected for November 2021.
So, it seems like the best option to me right now that we wait for .NET 6 here
and then let this contribution land on master so it can be released in
TinkerPop 3.6.0.
> Enable nullable checks
> --
>
> Key: TINKERPOP-2348
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2348
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Minor
>
> Gremlin.NET should enable [nullable
> checks|https://devblogs.microsoft.com/dotnet/embracing-nullable-reference-types/]
> to clearly communicate to users what can be {{null}} in Gremlin.NET and also
> to possibly find possible {{NullReferenceExceptions}} easier in our own code.
> The recommendation from Microsoft is to update libraries during the so-called
> _"nullable rollout phase"_ which ends in November with the expected release
> of .NET 5 which should have nullable checks enabled by default.
> We can add .NET Core 3.1 as an additional target framework to get the
> nullable checks and still also target .NET Standard to stay platform
> independent and to also still support .NET Framework and older .NET Core
> versions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2559) Stop sending the close message for .NET
[ https://issues.apache.org/jira/browse/TINKERPOP-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann closed TINKERPOP-2559. --- Fix Version/s: 3.6.0 3.5.1 Resolution: Fixed > Stop sending the close message for .NET > --- > > Key: TINKERPOP-2559 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2559 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.5.0 >Reporter: Stephen Mallette >Assignee: Florian Hockmann >Priority: Minor > Fix For: 3.5.1, 3.6.0 > > > The close message was deprecated a long time ago and should have been removed > in 3.5.0, but that was missed. There is no impact to sending it in 3.5.0 but > it's a bit of a waste of a message. We just need to close the webscoket > connection to close off the connection on the server. See TINKERPOP-2336 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2564) Gremlin.NET: Can only use Dictionary with SubmitAsync
[ https://issues.apache.org/jira/browse/TINKERPOP-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann closed TINKERPOP-2564. --- Resolution: Not A Bug > Gremlin.NET: Can only use Dictionary with SubmitAsync > - > > Key: TINKERPOP-2564 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2564 > Project: TinkerPop > Issue Type: Bug > Components: dotnet >Affects Versions: 3.5.0 >Reporter: Kirk Marple >Priority: Major > > After upgrading to 3.5.0 of .NET Core driver, I'm trying to get my call to > SubmitAsync working. > This seems to be the only generic type that works w/o a cast error. > await client.SubmitAsync>(query) > I'd thought I could use > await client.SubmitAsync(query) > But I get a cast error from the dictionary to anything else I try. > Any idea what I may be doing wrong? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2564) Gremlin.NET: Can only use Dictionary with SubmitAsync
[
https://issues.apache.org/jira/browse/TINKERPOP-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17344514#comment-17344514
]
Florian Hockmann commented on TINKERPOP-2564:
-
Returning unserialized JSON is no longer supported out of the box in version
3.5.0 as stated in the
[CHANGELOG|https://github.com/apache/tinkerpop/blob/3.5.0/CHANGELOG.asciidoc#release-3-5-0]:
{quote}Gremlin.Net driver no longer supports skipping deserialization by
default. Users can however create their own {{IMessageSerializer}} if they need
this functionality.
{quote}
Looks like we forgot to update [the upgrade
docs|https://tinkerpop.apache.org/docs/3.5.0/upgrade/#serialization-3_5_0]
there which still state that it's possible to return a {{JsonElement}}
unfortunately.
You can use the included
[{{GraphSONMessageSerializer}}|https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Structure/IO/GraphSON/GraphSONMessageSerializer.cs]
as a basis if you want to implement your own message serializer. You probably
only have to omit the last two lines of the {{DeserializeMessageAsync}} method:
{code}
var data = _graphSONReader.ToObject(responseMessage.Result.Data);
return Task.FromResult(CopyMessageWithNewData(responseMessage, data));
{code}
> Gremlin.NET: Can only use Dictionary with SubmitAsync
> -
>
> Key: TINKERPOP-2564
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2564
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.5.0
>Reporter: Kirk Marple
>Priority: Major
>
> After upgrading to 3.5.0 of .NET Core driver, I'm trying to get my call to
> SubmitAsync working.
> This seems to be the only generic type that works w/o a cast error.
> await client.SubmitAsync>(query)
> I'd thought I could use
> await client.SubmitAsync(query)
> But I get a cast error from the dictionary to anything else I try.
> Any idea what I may be doing wrong?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (TINKERPOP-2559) Stop sending the close message for .NET
[ https://issues.apache.org/jira/browse/TINKERPOP-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hockmann reassigned TINKERPOP-2559: --- Assignee: Florian Hockmann > Stop sending the close message for .NET > --- > > Key: TINKERPOP-2559 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2559 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.5.0 >Reporter: Stephen Mallette >Assignee: Florian Hockmann >Priority: Minor > > The close message was deprecated a long time ago and should have been removed > in 3.5.0, but that was missed. There is no impact to sending it in 3.5.0 but > it's a bit of a waste of a message. We just need to close the webscoket > connection to close off the connection on the server. See TINKERPOP-2336 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2336) Allow close of channel without having to wait for server
[
https://issues.apache.org/jira/browse/TINKERPOP-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17337396#comment-17337396
]
Florian Hockmann commented on TINKERPOP-2336:
-
Good to know. I'll submit a PR for .NET as the change is really trivial.
> Allow close of channel without having to wait for server
>
>
> Key: TINKERPOP-2336
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2336
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver
>Affects Versions: 3.3.10
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Major
> Labels: deprecation
> Fix For: 3.5.0, 3.3.11, 3.4.7
>
>
> The java driver hangs about waiting for results to return after a
> {{Client.close()}} is called. That creates problems if there is a desire to
> kill the client but there is a long run query on the server and that query is
> configured to an especially long timeout. I think there just needs to be a
> configuration for the amount of time the client will wait for results before
> just giving up and shutting down. A byproduct of this change is that by
> allowing the {{Client}} to close the channel while a query is executing
> creates a cancellation sort of functionality which should issue an interrupt
> to the traversal executing on the server.
> With this change in place it sort of creates a feature somewhat at odds with
> the session "close" message which tries to release a specific session. The
> problem with that message is that it really is only useful if there is not
> already a message ahead of it getting processed and stuck otherwise it is
> queued and won't be processed until the message ahead of it is handled.
> Obviously, if the goal is to kill the session because of a long run process
> then this feature becomes a bit unhelpful. If the close of the channel
> accomplishes the same thing as the close message then I think we would want
> to deprecate the close message and remove it for 3.5.0.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
