[jira] [Commented] (TINKERPOP-2027) Add a Typescript definitions file to the project
[ https://issues.apache.org/jira/browse/TINKERPOP-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16738064#comment-16738064 ] Jorge Bay commented on TINKERPOP-2027: -- As stated, we need the definitions file to be dynamically generated in the same way the traversal API is generated: * Script: [https://github.com/apache/tinkerpop/blob/3.4.0/gremlin-javascript/glv/generate.groovy] * Templates sample: [https://github.com/apache/tinkerpop/blob/3.4.0/gremlin-javascript/glv/GraphTraversalSource.template] That way the definitions file will be up to date with the API. You can checkout the documentation about contributing code changes: http://tinkerpop.apache.org/docs/3.4.0/dev/developer/#_contributing_code_changes > Add a Typescript definitions file to the project > > > Key: TINKERPOP-2027 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2027 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Affects Versions: 3.3.3, 3.2.9 >Reporter: Matthew Allen >Priority: Major > > For those using Typescript it would be great to provide a type definition > file for the glv. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2130) Cannot instantiate DriverRemoteConnection without passing an options object
[
https://issues.apache.org/jira/browse/TINKERPOP-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay updated TINKERPOP-2130:
-
Fix Version/s: 3.4.1
3.3.6
> Cannot instantiate DriverRemoteConnection without passing an options object
> ---
>
> Key: TINKERPOP-2130
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2130
> Project: TinkerPop
> Issue Type: Improvement
> Components: javascript
>Affects Versions: 3.4.0, 3.3.5
>Reporter: Niv Sherf
>Priority: Minor
> Fix For: 3.3.6, 3.4.1
>
>
> In gremlin-javascript, when instantiating a new DriverRemoteConnection
> without passing an options object, a TypeError is thrown. This is a breaking
> change introduced in v3.4.0.
> For example:
> {code:java}
> const dc = new DriverRemoteConnection(process.env.GRAPH_URL);{code}
> The above code results in an error being thrown:
> {noformat}
> TypeError: Cannot read property 'reader' of undefined{noformat}
> This works fine:
> {code:java}
> const dc = new DriverRemoteConnection(process.env.GRAPH_URL, {});{code}
> Both calls work correctly when using 3.3.4.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2130) Cannot instantiate DriverRemoteConnection without passing an options object
[
https://issues.apache.org/jira/browse/TINKERPOP-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay updated TINKERPOP-2130:
-
Affects Version/s: 3.3.5
> Cannot instantiate DriverRemoteConnection without passing an options object
> ---
>
> Key: TINKERPOP-2130
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2130
> Project: TinkerPop
> Issue Type: Improvement
> Components: javascript
>Affects Versions: 3.4.0, 3.3.5
>Reporter: Niv Sherf
>Priority: Minor
>
> In gremlin-javascript, when instantiating a new DriverRemoteConnection
> without passing an options object, a TypeError is thrown. This is a breaking
> change introduced in v3.4.0.
> For example:
> {code:java}
> const dc = new DriverRemoteConnection(process.env.GRAPH_URL);{code}
> The above code results in an error being thrown:
> {noformat}
> TypeError: Cannot read property 'reader' of undefined{noformat}
> This works fine:
> {code:java}
> const dc = new DriverRemoteConnection(process.env.GRAPH_URL, {});{code}
> Both calls work correctly when using 3.3.4.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2130) Cannot instantiate DriverRemoteConnection without passing an options object
[
https://issues.apache.org/jira/browse/TINKERPOP-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay closed TINKERPOP-2130.
Resolution: Fixed
> Cannot instantiate DriverRemoteConnection without passing an options object
> ---
>
> Key: TINKERPOP-2130
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2130
> Project: TinkerPop
> Issue Type: Improvement
> Components: javascript
>Affects Versions: 3.4.0, 3.3.5
>Reporter: Niv Sherf
>Priority: Minor
> Fix For: 3.3.6, 3.4.1
>
>
> In gremlin-javascript, when instantiating a new DriverRemoteConnection
> without passing an options object, a TypeError is thrown. This is a breaking
> change introduced in v3.4.0.
> For example:
> {code:java}
> const dc = new DriverRemoteConnection(process.env.GRAPH_URL);{code}
> The above code results in an error being thrown:
> {noformat}
> TypeError: Cannot read property 'reader' of undefined{noformat}
> This works fine:
> {code:java}
> const dc = new DriverRemoteConnection(process.env.GRAPH_URL, {});{code}
> Both calls work correctly when using 3.3.4.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2130) Cannot instantiate DriverRemoteConnection without passing an options object
[
https://issues.apache.org/jira/browse/TINKERPOP-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16744820#comment-16744820
]
Jorge Bay commented on TINKERPOP-2130:
--
Thanks for creating the ticket and for implementing the fix [~nivsherf]!
> Cannot instantiate DriverRemoteConnection without passing an options object
> ---
>
> Key: TINKERPOP-2130
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2130
> Project: TinkerPop
> Issue Type: Improvement
> Components: javascript
>Affects Versions: 3.4.0, 3.3.5
>Reporter: Niv Sherf
>Priority: Minor
> Fix For: 3.3.6, 3.4.1
>
>
> In gremlin-javascript, when instantiating a new DriverRemoteConnection
> without passing an options object, a TypeError is thrown. This is a breaking
> change introduced in v3.4.0.
> For example:
> {code:java}
> const dc = new DriverRemoteConnection(process.env.GRAPH_URL);{code}
> The above code results in an error being thrown:
> {noformat}
> TypeError: Cannot read property 'reader' of undefined{noformat}
> This works fine:
> {code:java}
> const dc = new DriverRemoteConnection(process.env.GRAPH_URL, {});{code}
> Both calls work correctly when using 3.3.4.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2143) JavaScript GLV: Support browsers
Jorge Bay created TINKERPOP-2143: Summary: JavaScript GLV: Support browsers Key: TINKERPOP-2143 URL: https://issues.apache.org/jira/browse/TINKERPOP-2143 Project: TinkerPop Issue Type: Improvement Components: javascript Reporter: Jorge Bay Currently the JavaScript GLV is designed to work on Node.js runtime. We could consider supporting browser runtimes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2143) JavaScript GLV: Support browsers
[ https://issues.apache.org/jira/browse/TINKERPOP-2143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752250#comment-16752250 ] Jorge Bay commented on TINKERPOP-2143: -- See [this comment|https://issues.apache.org/jira/browse/TINKERPOP-2137?focusedCommentId=16750957&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16750957] from [~fdominik] for more info. > JavaScript GLV: Support browsers > > > Key: TINKERPOP-2143 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2143 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Reporter: Jorge Bay >Priority: Major > > Currently the JavaScript GLV is designed to work on Node.js runtime. > We could consider supporting browser runtimes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2137) Gremlin Javascript can't be used in Angular applications
[
https://issues.apache.org/jira/browse/TINKERPOP-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay closed TINKERPOP-2137.
Resolution: Not A Problem
I'm closing this one as the driver doesn't support browser runtimes.
[~fdominik] [~jbmusso], we can continue the discussion on TINKERPOP-2143.
> Gremlin Javascript can't be used in Angular applications
>
>
> Key: TINKERPOP-2137
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2137
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.4.0
> Environment: "@angular/cdk": "^7.2.1",
>Reporter: Dominik Franek
>Priority: Major
>
> If you try to install gremlin using
> {code:java}
> ng add gremlin{code}
> it gets you:
> _The package that you are trying to add does not support schematics. You can
> try using a different version of the package or contact the package author to
> add ng-add support._
> If you try using
> {code:java}
> npm i gremlin{code}
> it is installed, however the gremlin package can't be used in Angular
> Application. Is there any way to fix it to work for ng-add? If not, maybe the
> documentation needs an update of what Javascript environments are supported,
> because our project intended to use Gremlin (we tried using Java, that
> Gremlin is perfect... now when developing we found out that it is not
> possible in Angular :) ).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2143) JavaScript GLV: Support browsers
[ https://issues.apache.org/jira/browse/TINKERPOP-2143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated TINKERPOP-2143: - Priority: Minor (was: Major) > JavaScript GLV: Support browsers > > > Key: TINKERPOP-2143 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2143 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Reporter: Jorge Bay >Priority: Minor > > Currently the JavaScript GLV is designed to work on Node.js runtime. > We could consider supporting browser runtimes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2143) JavaScript GLV: Support browsers
[ https://issues.apache.org/jira/browse/TINKERPOP-2143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752265#comment-16752265 ] Jorge Bay commented on TINKERPOP-2143: -- We should get some use cases to determine if it's worth the implementation and maintenance effort, before we try to implement it. > JavaScript GLV: Support browsers > > > Key: TINKERPOP-2143 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2143 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Reporter: Jorge Bay >Priority: Minor > > Currently the JavaScript GLV is designed to work on Node.js runtime. > We could consider supporting browser runtimes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2147) Add GraphBinary serializer for TraversalMetrics
[ https://issues.apache.org/jira/browse/TINKERPOP-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay closed TINKERPOP-2147. Resolution: Done Merged to master. > Add GraphBinary serializer for TraversalMetrics > --- > > Key: TINKERPOP-2147 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2147 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Affects Versions: 3.4.0 >Reporter: Eduard Tudenhoefner >Assignee: Eduard Tudenhoefner >Priority: Major > Fix For: 3.4.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-2149) GraphBinary: Make type serializer resolution pluggable
Jorge Bay created TINKERPOP-2149: Summary: GraphBinary: Make type serializer resolution pluggable Key: TINKERPOP-2149 URL: https://issues.apache.org/jira/browse/TINKERPOP-2149 Project: TinkerPop Issue Type: Improvement Affects Versions: 3.4.0 Reporter: Jorge Bay Assignee: Jorge Bay Fix For: 3.4.1 We should support providing your own logic to resolve type serializers, some sort of "catch all" logic for type serializer implementations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-2150) GraphBinary: Support configuring the TypeSerializerRegistry builder class in config
Jorge Bay created TINKERPOP-2150: Summary: GraphBinary: Support configuring the TypeSerializerRegistry builder class in config Key: TINKERPOP-2150 URL: https://issues.apache.org/jira/browse/TINKERPOP-2150 Project: TinkerPop Issue Type: Improvement Affects Versions: 3.4.0 Reporter: Jorge Bay Assignee: Jorge Bay Fix For: 3.4.1 We currently only support providing custom serializers via configuration. It would be nice to be able to provide the builder itself, that way providers can point to a class where all custom and default types are set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2150) GraphBinary: Support configuring the TypeSerializerRegistry builder class in config
[ https://issues.apache.org/jira/browse/TINKERPOP-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated TINKERPOP-2150: - Component/s: io > GraphBinary: Support configuring the TypeSerializerRegistry builder class in > config > --- > > Key: TINKERPOP-2150 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2150 > Project: TinkerPop > Issue Type: Improvement > Components: io >Affects Versions: 3.4.0 >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > Fix For: 3.4.1 > > > We currently only support providing custom serializers via configuration. > It would be nice to be able to provide the builder itself, that way providers > can point to a class where all custom and default types are set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2149) GraphBinary: Make type serializer resolution pluggable
[ https://issues.apache.org/jira/browse/TINKERPOP-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay closed TINKERPOP-2149. Resolution: Done > GraphBinary: Make type serializer resolution pluggable > -- > > Key: TINKERPOP-2149 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2149 > Project: TinkerPop > Issue Type: Improvement > Components: io >Affects Versions: 3.4.0 >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > Fix For: 3.4.1 > > > We should support providing your own logic to resolve type serializers, some > sort of "catch all" logic for type serializer implementations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-2152) Path toString fails in Gremlin JavaScript
Jorge Bay created TINKERPOP-2152: Summary: Path toString fails in Gremlin JavaScript Key: TINKERPOP-2152 URL: https://issues.apache.org/jira/browse/TINKERPOP-2152 Project: TinkerPop Issue Type: Bug Components: javascript Affects Versions: 3.3.5, 3.4.0 Reporter: Jorge Bay Fix For: 3.3.6, 3.4.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2150) GraphBinary: Support configuring the TypeSerializerRegistry builder class in config
[ https://issues.apache.org/jira/browse/TINKERPOP-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay closed TINKERPOP-2150. Resolution: Done > GraphBinary: Support configuring the TypeSerializerRegistry builder class in > config > --- > > Key: TINKERPOP-2150 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2150 > Project: TinkerPop > Issue Type: Improvement > Components: io >Affects Versions: 3.4.0 >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > Fix For: 3.4.1 > > > We currently only support providing custom serializers via configuration. > It would be nice to be able to provide the builder itself, that way providers > can point to a class where all custom and default types are set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-2153) Remove unused parameter from ResponseMessageSerializer
Jorge Bay created TINKERPOP-2153:
Summary: Remove unused parameter from ResponseMessageSerializer
Key: TINKERPOP-2153
URL: https://issues.apache.org/jira/browse/TINKERPOP-2153
Project: TinkerPop
Issue Type: Bug
Components: io
Affects Versions: 3.4.0
Reporter: Jorge Bay
When implementing GraphBinary as part of TINKERPOP-1942, the idea was to make
{{RequestMessageSerializer}} and {{ResponseMessageSerializer}} implement
{{TypeSerializer}} interface, but was later disregarded as those are top
level serializers (Request/Response can't be nested within another type).
As a result, the {{nullable}} parameter was removed from
{{RequestMessageSerializer}} but I've forgot to do it for
{{ResponseMessageSerializer}}. We should remove it as it's never used, the
question is whether we can do this change as part of a patch release, as it
involves API changes. Given that GraphBinary is still on its early stages and
{{ResponseMessageSerializer}} is not designed to be inherited from / all
called, I think we should change the method signature asap.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2154) GraphBinary: Serializers should release resources in case of failures
Jorge Bay created TINKERPOP-2154:
Summary: GraphBinary: Serializers should release resources in case
of failures
Key: TINKERPOP-2154
URL: https://issues.apache.org/jira/browse/TINKERPOP-2154
Project: TinkerPop
Issue Type: Bug
Components: io
Affects Versions: 3.4.0
Reporter: Jorge Bay
Assignee: Jorge Bay
Fix For: 3.4.1
{{TypeSerializer}} implementations should release the working {{ByteBuf}}
instances when writing fails. This is specially concerning for composite types
(List/Map/ByteCode/...) that can contain arbitrary nested types.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2123) Javascript driver connection.open() hangs
[
https://issues.apache.org/jira/browse/TINKERPOP-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16764775#comment-16764775
]
Jorge Bay commented on TINKERPOP-2123:
--
The url format for CosmosDB is:
{{wss://DATABASE_ACCOUNT_NAME.gremlin.cosmosdb.azure.com:443/gremlin}}
https://github.com/Azure-Samples/azure-cosmos-db-graph-nodejs-getting-started/blob/master/config.js#L3
Can you check your settings following the guide from MS:
https://docs.microsoft.com/en-us/azure/cosmos-db/create-graph-nodejs
> Javascript driver connection.open() hangs
> -
>
> Key: TINKERPOP-2123
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2123
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.3.4
>Reporter: Nicolas KP
>Priority: Major
>
> Hi,
> I think that 80% it's just me using the api wrong, but there's definitely a
> catch I don't get: when I try to connect through the js api, client.open()
> calls connection.open() which launches a promise which just waits without
> giving any error. It doesn't matter if I give a wrong url (it should have
> thrown an error in that case), or not, it just waits for the timeout (I've
> tried with 5s and 100s timeouts), execution never reaches .resolve() or
> .reject() of connection._openPromise.
> Here's a code to reproduce the issue:
> {code}
> const authenticator = new
> gremlin.driver.auth.PlainTextSaslAuthenticator(username, password);
> const client = new gremlin.driver.Client(
> "graphgoblin.gremlin.cosmosdb.azure.com:443",
> { "authenticator": authenticator });
> const clientSubmitTimeout = 5 * 1000;
> return await rejectOnTimeout(clientSubmitTimeout, async () => {
> try {
> await client.open(); //I know it's called in .submit, but I
> added it here to test more easily which part hangs. Execution never reaches
> the next statement
> const result = await client.submit(gremlinQuery);
> return result;
> }
> catch (err) {
> this.log("Error from gremlin server: ", err.message ||
> err.toString());
> throw err;
> }
> finally {
> await client.close(); //maybe unnecessary?
>}
> });
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2154) GraphBinary: Serializers should release resources in case of failures
[
https://issues.apache.org/jira/browse/TINKERPOP-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay closed TINKERPOP-2154.
Resolution: Done
> GraphBinary: Serializers should release resources in case of failures
> -
>
> Key: TINKERPOP-2154
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2154
> Project: TinkerPop
> Issue Type: Bug
> Components: io
>Affects Versions: 3.4.0
>Reporter: Jorge Bay
>Assignee: Jorge Bay
>Priority: Major
> Fix For: 3.4.1
>
>
> {{TypeSerializer}} implementations should release the working {{ByteBuf}}
> instances when writing fails. This is specially concerning for composite
> types (List/Map/ByteCode/...) that can contain arbitrary nested types.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2161) GraphBinary: Write serialization performance issue
[
https://issues.apache.org/jira/browse/TINKERPOP-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16769111#comment-16769111
]
Jorge Bay commented on TINKERPOP-2161:
--
I've pushed the benchmark code:
https://github.com/apache/tinkerpop/commit/555d726d1937e4e4213890e4e8c51f189475f724
> GraphBinary: Write serialization performance issue
> ---
>
> Key: TINKERPOP-2161
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2161
> Project: TinkerPop
> Issue Type: Bug
> Components: io
>Affects Versions: 3.4.0
>Reporter: Jorge Bay
>Priority: Major
>
> There seems to be a performance issue regarding the write path in GraphBinary:
> {code}
> Benchmark Mode Cnt Score
> Error Units
> SerializationBenchmark.testReadMessage1Binary thrpt 20 4800832.981 ±
> 430909.102 ops/s
> SerializationBenchmark.testReadMessage1GraphSON thrpt 20 34109.669 ±
> 5231.210 ops/s
> SerializationBenchmark.testReadMessage2Binary thrpt 20827266.707 ±
> 78214.379 ops/s
> SerializationBenchmark.testReadMessage2GraphSON thrpt 20 18462.919 ±
> 2640.093 ops/s
> SerializationBenchmark.testWriteBytecodeBinarythrpt 20130486.109 ±
> 5505.113 ops/s
> SerializationBenchmark.testWriteBytecodeGraphSON thrpt 20592658.686 ±
> 68063.966 ops/s
> SerializationBenchmark.testWriteResponseBinarythrpt 20290240.715 ±
> 25620.656 ops/s
> SerializationBenchmark.testWriteResponseGraphSON thrpt 20612832.036 ±
> 48173.673 ops/s
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2161) GraphBinary: Write serialization performance issue
Jorge Bay created TINKERPOP-2161:
Summary: GraphBinary: Write serialization performance issue
Key: TINKERPOP-2161
URL: https://issues.apache.org/jira/browse/TINKERPOP-2161
Project: TinkerPop
Issue Type: Bug
Components: io
Affects Versions: 3.4.0
Reporter: Jorge Bay
There seems to be a performance issue regarding the write path in GraphBinary:
{code}
Benchmark Mode Cnt Score
Error Units
SerializationBenchmark.testReadMessage1Binary thrpt 20 4800832.981 ±
430909.102 ops/s
SerializationBenchmark.testReadMessage1GraphSON thrpt 20 34109.669 ±
5231.210 ops/s
SerializationBenchmark.testReadMessage2Binary thrpt 20827266.707 ±
78214.379 ops/s
SerializationBenchmark.testReadMessage2GraphSON thrpt 20 18462.919 ±
2640.093 ops/s
SerializationBenchmark.testWriteBytecodeBinarythrpt 20130486.109 ±
5505.113 ops/s
SerializationBenchmark.testWriteBytecodeGraphSON thrpt 20592658.686 ±
68063.966 ops/s
SerializationBenchmark.testWriteResponseBinarythrpt 20290240.715 ±
25620.656 ops/s
SerializationBenchmark.testWriteResponseGraphSON thrpt 20612832.036 ±
48173.673 ops/s
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2161) GraphBinary: Write serialization performance issue
[
https://issues.apache.org/jira/browse/TINKERPOP-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16769317#comment-16769317
]
Jorge Bay commented on TINKERPOP-2161:
--
It looks like the excessive use of composite buffers is one of the culprits,
replacing {{allocator.compositeBuffer()}} with
{{Unpooled.unmodifiableBuffer()}} makes writing on par with GraphSON.
I'm looking at further improvements that can be done to hopefully streamline
the write path.
> GraphBinary: Write serialization performance issue
> ---
>
> Key: TINKERPOP-2161
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2161
> Project: TinkerPop
> Issue Type: Bug
> Components: io
>Affects Versions: 3.4.0
>Reporter: Jorge Bay
>Priority: Major
>
> There seems to be a performance issue regarding the write path in GraphBinary:
> {code}
> Benchmark Mode Cnt Score
> Error Units
> SerializationBenchmark.testReadMessage1Binary thrpt 20 4800832.981 ±
> 430909.102 ops/s
> SerializationBenchmark.testReadMessage1GraphSON thrpt 20 34109.669 ±
> 5231.210 ops/s
> SerializationBenchmark.testReadMessage2Binary thrpt 20827266.707 ±
> 78214.379 ops/s
> SerializationBenchmark.testReadMessage2GraphSON thrpt 20 18462.919 ±
> 2640.093 ops/s
> SerializationBenchmark.testWriteBytecodeBinarythrpt 20130486.109 ±
> 5505.113 ops/s
> SerializationBenchmark.testWriteBytecodeGraphSON thrpt 20592658.686 ±
> 68063.966 ops/s
> SerializationBenchmark.testWriteResponseBinarythrpt 20290240.715 ±
> 25620.656 ops/s
> SerializationBenchmark.testWriteResponseGraphSON thrpt 20612832.036 ±
> 48173.673 ops/s
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2161) GraphBinary: Write serialization performance issue
[
https://issues.apache.org/jira/browse/TINKERPOP-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16770999#comment-16770999
]
Jorge Bay commented on TINKERPOP-2161:
--
I've pushed a commit to optimize the write path by remove the use of composite
buffers: https://github.com/apache/tinkerpop/tree/write-TINKERPOP-2161-1
With the current approach, I've obtained the following serialization benchmark
results:
{code}
Benchmark Mode CntScore
Error Units
SerializationBenchmark.testReadMessage1Binary thrpt 20 4699805.045 ±
289657.843 ops/s
SerializationBenchmark.testReadMessage1GraphSON thrpt 2040095.029 ±
1921.030 ops/s
SerializationBenchmark.testReadMessage2Binary thrpt 20 970825.257 ±
32252.988 ops/s
SerializationBenchmark.testReadMessage2GraphSON thrpt 2028624.405 ±
1571.170 ops/s
SerializationBenchmark.testWriteBytecodeBinarythrpt 20 462364.186 ±
17254.689 ops/s
SerializationBenchmark.testWriteBytecodeGraphSON thrpt 20 636226.623 ±
52341.880 ops/s
SerializationBenchmark.testWriteResponseBinarythrpt 20 601825.324 ±
61370.149 ops/s
SerializationBenchmark.testWriteResponseGraphSON thrpt 20 642978.971 ±
29259.051 ops/s
{code}
It's an improvement but there is still some way to go.
I'll try another approach on a different branch that will involve changing the
binary serialization API a little bit but I think it will be worth it.
> GraphBinary: Write serialization performance issue
> ---
>
> Key: TINKERPOP-2161
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2161
> Project: TinkerPop
> Issue Type: Bug
> Components: io
>Affects Versions: 3.4.0
>Reporter: Jorge Bay
>Priority: Major
>
> There seems to be a performance issue regarding the write path in GraphBinary:
> {code}
> Benchmark Mode Cnt Score
> Error Units
> SerializationBenchmark.testReadMessage1Binary thrpt 20 4800832.981 ±
> 430909.102 ops/s
> SerializationBenchmark.testReadMessage1GraphSON thrpt 20 34109.669 ±
> 5231.210 ops/s
> SerializationBenchmark.testReadMessage2Binary thrpt 20827266.707 ±
> 78214.379 ops/s
> SerializationBenchmark.testReadMessage2GraphSON thrpt 20 18462.919 ±
> 2640.093 ops/s
> SerializationBenchmark.testWriteBytecodeBinarythrpt 20130486.109 ±
> 5505.113 ops/s
> SerializationBenchmark.testWriteBytecodeGraphSON thrpt 20592658.686 ±
> 68063.966 ops/s
> SerializationBenchmark.testWriteResponseBinarythrpt 20290240.715 ±
> 25620.656 ops/s
> SerializationBenchmark.testWriteResponseGraphSON thrpt 20612832.036 ±
> 48173.673 ops/s
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2161) GraphBinary: Write serialization performance issue
[
https://issues.apache.org/jira/browse/TINKERPOP-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771172#comment-16771172
]
Jorge Bay commented on TINKERPOP-2161:
--
I've pushed a pull requests that includes improvements to the write path:
[https://github.com/apache/tinkerpop/pull/1065]
With this new approach, the benchmark results are the following:
{code:java}
Benchmark Mode Cnt Score
Error Units
SerializationBenchmark.testReadMessage1Binary thrpt 20 4933443.595 ±
108335.893 ops/s
SerializationBenchmark.testReadMessage1GraphSON thrpt 20 34318.763 ±
7782.995 ops/s
SerializationBenchmark.testReadMessage2Binary thrpt 20974269.201 ±
27497.059 ops/s
SerializationBenchmark.testReadMessage2GraphSON thrpt 20 29928.189 ±
1187.881 ops/s
SerializationBenchmark.testWriteBytecodeBinarythrpt 20932400.254 ±
24727.644 ops/s
SerializationBenchmark.testWriteBytecodeGraphSON thrpt 20690590.285 ±
19508.398 ops/s
SerializationBenchmark.testWriteResponseBinarythrpt 20 2629038.176 ±
67510.162 ops/s
SerializationBenchmark.testWriteResponseGraphSON thrpt 20652272.129 ±
20014.138 ops/s
{code}
> GraphBinary: Write serialization performance issue
> ---
>
> Key: TINKERPOP-2161
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2161
> Project: TinkerPop
> Issue Type: Bug
> Components: io
>Affects Versions: 3.4.0
>Reporter: Jorge Bay
>Priority: Major
>
> There seems to be a performance issue regarding the write path in GraphBinary:
> {code}
> Benchmark Mode Cnt Score
> Error Units
> SerializationBenchmark.testReadMessage1Binary thrpt 20 4800832.981 ±
> 430909.102 ops/s
> SerializationBenchmark.testReadMessage1GraphSON thrpt 20 34109.669 ±
> 5231.210 ops/s
> SerializationBenchmark.testReadMessage2Binary thrpt 20827266.707 ±
> 78214.379 ops/s
> SerializationBenchmark.testReadMessage2GraphSON thrpt 20 18462.919 ±
> 2640.093 ops/s
> SerializationBenchmark.testWriteBytecodeBinarythrpt 20130486.109 ±
> 5505.113 ops/s
> SerializationBenchmark.testWriteBytecodeGraphSON thrpt 20592658.686 ±
> 68063.966 ops/s
> SerializationBenchmark.testWriteResponseBinarythrpt 20290240.715 ±
> 25620.656 ops/s
> SerializationBenchmark.testWriteResponseGraphSON thrpt 20612832.036 ±
> 48173.673 ops/s
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2166) P deserialization should be optimized
[ https://issues.apache.org/jira/browse/TINKERPOP-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated TINKERPOP-2166: - Component/s: io > P deserialization should be optimized > - > > Key: TINKERPOP-2166 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2166 > Project: TinkerPop > Issue Type: Improvement > Components: io >Reporter: Jorge Bay >Priority: Major > > P deserialization on GraphSON3 and GraphBinary can be optimized by using > caching / casting, avoiding expensive reflection calls when possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-2166) P deserialization should be optimized
Jorge Bay created TINKERPOP-2166: Summary: P deserialization should be optimized Key: TINKERPOP-2166 URL: https://issues.apache.org/jira/browse/TINKERPOP-2166 Project: TinkerPop Issue Type: Improvement Reporter: Jorge Bay P deserialization on GraphSON3 and GraphBinary can be optimized by using caching / casting, avoiding expensive reflection calls when possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2082) g:Set type is not be validated in some variant tests
[
https://issues.apache.org/jira/browse/TINKERPOP-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16775229#comment-16775229
]
Jorge Bay commented on TINKERPOP-2082:
--
[Gremlin-JavaScript maps TinkerPop's {{Set}} to
{{Array}}|https://github.com/apache/tinkerpop/blob/3.4.0/gremlin-javascript/src/main/javascript/gremlin-javascript/lib/structure/io/type-serializers.js#L430-L440],
do to the fact that hash can't be provided for custom types in JavaScript.
JavaScript {{Set}} type is only usable for built-in types {{String}},
{{Boolean}}, {{Number}} and {{BigInteger}}.
> g:Set type is not be validated in some variant tests
>
>
> Key: TINKERPOP-2082
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2082
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet, javascript
>Affects Versions: 3.3.4
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>
> {{g:Set}} as a type is not being validated by .NET or javascript as noticed
> here with this change:
> https://github.com/apache/tinkerpop/pull/964/files#diff-bc849673baf1f7ed925db681d0cc112c
> Javascript test harness for cucumber tests just coerces both {{s[]}} and
> {{l[]}} with {{toArray}} and .NET coerces both to a list and then if a
> {{s[]}} to a {{Set}} but doesn't bother to assert that the type is legit.
> If javascript can't support set/list semantics for some reason, [~jorgebg]
> please remove the "javascript" from the "component" field and we won't bother
> to worry about it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2082) g:Set type is not be validated in some variant tests
[
https://issues.apache.org/jira/browse/TINKERPOP-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16775230#comment-16775230
]
Jorge Bay commented on TINKERPOP-2082:
--
Is that what you were asking in the ticket?
> g:Set type is not be validated in some variant tests
>
>
> Key: TINKERPOP-2082
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2082
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet, javascript
>Affects Versions: 3.3.4
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>
> {{g:Set}} as a type is not being validated by .NET or javascript as noticed
> here with this change:
> https://github.com/apache/tinkerpop/pull/964/files#diff-bc849673baf1f7ed925db681d0cc112c
> Javascript test harness for cucumber tests just coerces both {{s[]}} and
> {{l[]}} with {{toArray}} and .NET coerces both to a list and then if a
> {{s[]}} to a {{Set}} but doesn't bother to assert that the type is legit.
> If javascript can't support set/list semantics for some reason, [~jorgebg]
> please remove the "javascript" from the "component" field and we won't bother
> to worry about it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2168) GraphSON: P deserialization should be optimized
Jorge Bay created TINKERPOP-2168: Summary: GraphSON: P deserialization should be optimized Key: TINKERPOP-2168 URL: https://issues.apache.org/jira/browse/TINKERPOP-2168 Project: TinkerPop Issue Type: Improvement Reporter: Jorge Bay P deserialization on GraphSON3 and GraphBinary can be optimized by using caching / casting, avoiding expensive reflection calls when possible. This ticket is dedicated for the GraphSON implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2168) GraphSON: P deserialization should be optimized
[ https://issues.apache.org/jira/browse/TINKERPOP-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated TINKERPOP-2168: - Component/s: io > GraphSON: P deserialization should be optimized > --- > > Key: TINKERPOP-2168 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2168 > Project: TinkerPop > Issue Type: Improvement > Components: io >Reporter: Jorge Bay >Priority: Major > > P deserialization on GraphSON3 and GraphBinary can be optimized by using > caching / casting, avoiding expensive reflection calls when possible. > This ticket is dedicated for the GraphSON implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2166) GraphBinary: P deserialization should be optimized
[ https://issues.apache.org/jira/browse/TINKERPOP-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated TINKERPOP-2166: - Description: P deserialization on GraphSON3 and GraphBinary can be optimized by using caching / casting, avoiding expensive reflection calls when possible. This ticket is to track the GraphBinary implementation. was:P deserialization on GraphSON3 and GraphBinary can be optimized by using caching / casting, avoiding expensive reflection calls when possible. > GraphBinary: P deserialization should be optimized > -- > > Key: TINKERPOP-2166 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2166 > Project: TinkerPop > Issue Type: Improvement > Components: io >Reporter: Jorge Bay >Priority: Major > > P deserialization on GraphSON3 and GraphBinary can be optimized by using > caching / casting, avoiding expensive reflection calls when possible. > This ticket is to track the GraphBinary implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (TINKERPOP-2166) GraphBinary: P deserialization should be optimized
[ https://issues.apache.org/jira/browse/TINKERPOP-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay reassigned TINKERPOP-2166: Assignee: Jorge Bay > GraphBinary: P deserialization should be optimized > -- > > Key: TINKERPOP-2166 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2166 > Project: TinkerPop > Issue Type: Improvement > Components: io >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > > P deserialization on GraphSON3 and GraphBinary can be optimized by using > caching / casting, avoiding expensive reflection calls when possible. > This ticket is to track the GraphBinary implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2166) GraphBinary: P deserialization should be optimized
[ https://issues.apache.org/jira/browse/TINKERPOP-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16776790#comment-16776790 ] Jorge Bay commented on TINKERPOP-2166: -- I've filed a separate ticket for the GraphSON implementation and repurposed this one to tackle GraphBinary. > GraphBinary: P deserialization should be optimized > -- > > Key: TINKERPOP-2166 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2166 > Project: TinkerPop > Issue Type: Improvement > Components: io >Reporter: Jorge Bay >Priority: Major > > P deserialization on GraphSON3 and GraphBinary can be optimized by using > caching / casting, avoiding expensive reflection calls when possible. > This ticket is to track the GraphBinary implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2166) GraphBinary: P deserialization should be optimized
[ https://issues.apache.org/jira/browse/TINKERPOP-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated TINKERPOP-2166: - Summary: GraphBinary: P deserialization should be optimized (was: P deserialization should be optimized) > GraphBinary: P deserialization should be optimized > -- > > Key: TINKERPOP-2166 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2166 > Project: TinkerPop > Issue Type: Improvement > Components: io >Reporter: Jorge Bay >Priority: Major > > P deserialization on GraphSON3 and GraphBinary can be optimized by using > caching / casting, avoiding expensive reflection calls when possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (TINKERPOP-2166) GraphBinary: P deserialization should be optimized
[ https://issues.apache.org/jira/browse/TINKERPOP-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TINKERPOP-2166 started by Jorge Bay. > GraphBinary: P deserialization should be optimized > -- > > Key: TINKERPOP-2166 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2166 > Project: TinkerPop > Issue Type: Improvement > Components: io >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > > P deserialization on GraphSON3 and GraphBinary can be optimized by using > caching / casting, avoiding expensive reflection calls when possible. > This ticket is to track the GraphBinary implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2161) GraphBinary: Write serialization performance issue
[
https://issues.apache.org/jira/browse/TINKERPOP-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay updated TINKERPOP-2161:
-
Fix Version/s: 3.4.1
> GraphBinary: Write serialization performance issue
> ---
>
> Key: TINKERPOP-2161
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2161
> Project: TinkerPop
> Issue Type: Bug
> Components: io
>Affects Versions: 3.4.0
>Reporter: Jorge Bay
>Priority: Major
> Fix For: 3.4.1
>
>
> There seems to be a performance issue regarding the write path in GraphBinary:
> {code}
> Benchmark Mode Cnt Score
> Error Units
> SerializationBenchmark.testReadMessage1Binary thrpt 20 4800832.981 ±
> 430909.102 ops/s
> SerializationBenchmark.testReadMessage1GraphSON thrpt 20 34109.669 ±
> 5231.210 ops/s
> SerializationBenchmark.testReadMessage2Binary thrpt 20827266.707 ±
> 78214.379 ops/s
> SerializationBenchmark.testReadMessage2GraphSON thrpt 20 18462.919 ±
> 2640.093 ops/s
> SerializationBenchmark.testWriteBytecodeBinarythrpt 20130486.109 ±
> 5505.113 ops/s
> SerializationBenchmark.testWriteBytecodeGraphSON thrpt 20592658.686 ±
> 68063.966 ops/s
> SerializationBenchmark.testWriteResponseBinarythrpt 20290240.715 ±
> 25620.656 ops/s
> SerializationBenchmark.testWriteResponseGraphSON thrpt 20612832.036 ±
> 48173.673 ops/s
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (TINKERPOP-2161) GraphBinary: Write serialization performance issue
[
https://issues.apache.org/jira/browse/TINKERPOP-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay resolved TINKERPOP-2161.
--
Resolution: Fixed
> GraphBinary: Write serialization performance issue
> ---
>
> Key: TINKERPOP-2161
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2161
> Project: TinkerPop
> Issue Type: Bug
> Components: io
>Affects Versions: 3.4.0
>Reporter: Jorge Bay
>Priority: Major
> Fix For: 3.4.1
>
>
> There seems to be a performance issue regarding the write path in GraphBinary:
> {code}
> Benchmark Mode Cnt Score
> Error Units
> SerializationBenchmark.testReadMessage1Binary thrpt 20 4800832.981 ±
> 430909.102 ops/s
> SerializationBenchmark.testReadMessage1GraphSON thrpt 20 34109.669 ±
> 5231.210 ops/s
> SerializationBenchmark.testReadMessage2Binary thrpt 20827266.707 ±
> 78214.379 ops/s
> SerializationBenchmark.testReadMessage2GraphSON thrpt 20 18462.919 ±
> 2640.093 ops/s
> SerializationBenchmark.testWriteBytecodeBinarythrpt 20130486.109 ±
> 5505.113 ops/s
> SerializationBenchmark.testWriteBytecodeGraphSON thrpt 20592658.686 ±
> 68063.966 ops/s
> SerializationBenchmark.testWriteResponseBinarythrpt 20290240.715 ±
> 25620.656 ops/s
> SerializationBenchmark.testWriteResponseGraphSON thrpt 20612832.036 ±
> 48173.673 ops/s
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2166) GraphBinary: P deserialization should be optimized
[ https://issues.apache.org/jira/browse/TINKERPOP-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay closed TINKERPOP-2166. Resolution: Done > GraphBinary: P deserialization should be optimized > -- > > Key: TINKERPOP-2166 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2166 > Project: TinkerPop > Issue Type: Improvement > Components: io >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > > P deserialization on GraphSON3 and GraphBinary can be optimized by using > caching / casting, avoiding expensive reflection calls when possible. > This ticket is to track the GraphBinary implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2166) GraphBinary: P deserialization should be optimized
[ https://issues.apache.org/jira/browse/TINKERPOP-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated TINKERPOP-2166: - Fix Version/s: 3.4.1 > GraphBinary: P deserialization should be optimized > -- > > Key: TINKERPOP-2166 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2166 > Project: TinkerPop > Issue Type: Improvement > Components: io >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > Fix For: 3.4.1 > > > P deserialization on GraphSON3 and GraphBinary can be optimized by using > caching / casting, avoiding expensive reflection calls when possible. > This ticket is to track the GraphBinary implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (TINKERPOP-2166) GraphBinary: P deserialization should be optimized
[ https://issues.apache.org/jira/browse/TINKERPOP-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay reopened TINKERPOP-2166: -- > GraphBinary: P deserialization should be optimized > -- > > Key: TINKERPOP-2166 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2166 > Project: TinkerPop > Issue Type: Improvement > Components: io >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > > P deserialization on GraphSON3 and GraphBinary can be optimized by using > caching / casting, avoiding expensive reflection calls when possible. > This ticket is to track the GraphBinary implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2166) GraphBinary: P deserialization should be optimized
[ https://issues.apache.org/jira/browse/TINKERPOP-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay closed TINKERPOP-2166. Resolution: Done > GraphBinary: P deserialization should be optimized > -- > > Key: TINKERPOP-2166 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2166 > Project: TinkerPop > Issue Type: Improvement > Components: io >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > Fix For: 3.4.1 > > > P deserialization on GraphSON3 and GraphBinary can be optimized by using > caching / casting, avoiding expensive reflection calls when possible. > This ticket is to track the GraphBinary implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2197) gremlin javascript - Error: read ECONNRESET at TLSWrap.onStreamRead - websocket error
[
https://issues.apache.org/jira/browse/TINKERPOP-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841282#comment-16841282
]
Jorge Bay commented on TINKERPOP-2197:
--
Hi [~comanchero], sorry I wasn't able to check this ticket before.
This looks like a bug in the driver when the connection is being actively
closed by the server and there's no activity.
bq. Why is the error thrown in the first place
>From the error {{ECONNRESET}} it looks like the connection is being actively
>closed by the server after that period of inactivity.
Can you verify that the {{ping}} is being sent every 60 secs with the pongs
being sent by the server? I think you can subscribe to the logs to obtain that.
> gremlin javascript - Error: read ECONNRESET at TLSWrap.onStreamRead -
> websocket error
> --
>
> Key: TINKERPOP-2197
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2197
> Project: TinkerPop
> Issue Type: Bug
> Components: driver, javascript
>Affects Versions: 3.4.0
> Environment: windows 10 ent, 10.016299
> nodejs 11.10.1
> gemlin javascript 3.4.0
> express 4.16.4
>Reporter: Thomas Mahringer
>Priority: Major
> Attachments: gremlin-ws-error.png
>
>
> *Environment*
>
> I'm running a nodejs express app and connect to MSFT azure gremlin through
> the js driver:
>
> {code:java}
> connect() {
> this.authenticator = new
> Gremlin.driver.auth.PlainTextSaslAuthenticator(
> `/dbs/${this.config.database}/colls/${this.config.collection}`,
>this.config.primaryKey)
>this.client = new Gremlin.driver.Client(
> this.config.endpoint,
> {
>authenticator: this.authenticator,
>traversalsource: "g",
>rejectUnauthorized: true,
>mimeType: "application/vnd.gremlin-v2.0+json"
> }
> }
> );
> {code}
>
>
> The app calls various gremlin commands through the string + "query parameter"
> syntax, e.g.
> {code:java}
> await this.client.submit("g.V().hasLabel(label)", {label: "Person"});{code}
>
> All the queries work fine but when the app is idling for about 5-10 minutes,
> the nodejs process exits with the above error. None of my error handlers are
> hit.
> So I debugged the gremlin js code and found out where the error is thrown:
> It's the error handler in gremlin/lib/driver/connection.js, which gets
> installed in "open"
> {code:java}
> open() {
> if (this.isOpen) {
> return Promise.resolve();
> }
> if (this._openPromise) {
> return this._openPromise;
> }
> this.emit('log', `ws open`);
> this._ws = new WebSocket(this.url, {
> headers: this.options.headers,
> ca: this.options.ca,
> cert: this.options.cert,
> pfx: this.options.pfx,
> rejectUnauthorized: this.options.rejectUnauthorized
> });
> this._ws.on('message', (data) => this._handleMessage(data));
> // *** Install error handler
> this._ws.on('error', (err) => this._handleError(err));
> ...
> }
> _handleError(err) {
> this.emit('log', `ws error ${err}`);
> console.error("* Added log to improve debug
> ")
> this._cleanupWebsocket();
> this.emit('error', err); // Error ist thrown here
> }{code}
>
> In the debugger I can see that the error is caused in
> *stream_base_commons.js:*
> {code:java}
> function onStreamRead(arrayBuffer) {
> const nread = streamBaseState[kReadBytesOrError];
> const handle = this;
> const stream = this[owner_symbol];
> stream[kUpdateTimer]();
> if (nread > 0 && !stream.destroyed) {
>const offset = streamBaseState[kArrayBufferOffset];
>const buf = new FastBuffer(arrayBuffer, offset, nread);
>if (!stream.push(buf)) {
> handle.reading = false;
> if (!stream.destroyed) {
>const err = handle.readStop();
>if (err)
> stream.destroy(errnoException(err, 'read'));
> }
>}
>return;
> }
> if (nread === 0) {
>return;
> }
> if (nread !== UV_EOF) {
>/*Happens here */ return stream.destroy(errnoException(nread,
> 'read'));
> }
> ...
> }
> {code}
>
> So my questions are:
> * Why is the error thrown in the first place. (After app idles for 5-10
> minutes)
> ** What happens in "this.emit('error', err);" in "Connection._handleError".
> * What is the right place to catch the error? I've of course wrapped the
> "submit" code above in try/catch (in case of async/await) or as
> "then(...).catch()..." (in case of using the promise directly). Since the
> error causes nodejs to exit, it's quite bad.:)
> ** As it all happens asynchronously, I would need something like an
> "onError" handler. But the web socket and its handler
> (this._ws.on('error')...) are within the "Connection" class.
> The attached image shows the stack trace in Visual Stud
[jira] [Commented] (TINKERPOP-2217) Race condition in Gremlin.net driver connection
[ https://issues.apache.org/jira/browse/TINKERPOP-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842144#comment-16842144 ] Jorge Bay commented on TINKERPOP-2217: -- For me, the path of least resistance would be to include a fix for the current issue in this release as proposed here (3 lines of code): https://github.com/apache/tinkerpop/pull/1114#issuecomment-492962272 and then, discuss alternative approaches like discussed in https://github.com/apache/tinkerpop/pull/1115 for the next iteration. > Race condition in Gremlin.net driver connection > --- > > Key: TINKERPOP-2217 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2217 > Project: TinkerPop > Issue Type: Bug > Components: dotnet >Affects Versions: 3.4.1 >Reporter: Daniel C. Weber >Priority: Critical > > In Connection.cs, _writeInProgress could be observed by BeginSendingMessages > to indicate that the loop in SendMessagesFromQueueAsync is still "in flight" > while in reality, it has already exited. While probably extremly rare, it's > still a race condition. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2197) gremlin javascript - Error: read ECONNRESET at TLSWrap.onStreamRead - websocket error
[
https://issues.apache.org/jira/browse/TINKERPOP-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16845662#comment-16845662
]
Jorge Bay commented on TINKERPOP-2197:
--
Maybe JIRA logged you out? (check top right corner)
> gremlin javascript - Error: read ECONNRESET at TLSWrap.onStreamRead -
> websocket error
> --
>
> Key: TINKERPOP-2197
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2197
> Project: TinkerPop
> Issue Type: Bug
> Components: driver, javascript
>Affects Versions: 3.4.0
> Environment: windows 10 ent, 10.016299
> nodejs 11.10.1
> gemlin javascript 3.4.0
> express 4.16.4
>Reporter: Thomas Mahringer
>Priority: Major
> Attachments: gremlin-ws-error.png
>
>
> *Environment*
>
> I'm running a nodejs express app and connect to MSFT azure gremlin through
> the js driver:
>
> {code:java}
> connect() {
> this.authenticator = new
> Gremlin.driver.auth.PlainTextSaslAuthenticator(
> `/dbs/${this.config.database}/colls/${this.config.collection}`,
>this.config.primaryKey)
>this.client = new Gremlin.driver.Client(
> this.config.endpoint,
> {
>authenticator: this.authenticator,
>traversalsource: "g",
>rejectUnauthorized: true,
>mimeType: "application/vnd.gremlin-v2.0+json"
> }
> }
> );
> {code}
>
>
> The app calls various gremlin commands through the string + "query parameter"
> syntax, e.g.
> {code:java}
> await this.client.submit("g.V().hasLabel(label)", {label: "Person"});{code}
>
> All the queries work fine but when the app is idling for about 5-10 minutes,
> the nodejs process exits with the above error. None of my error handlers are
> hit.
> So I debugged the gremlin js code and found out where the error is thrown:
> It's the error handler in gremlin/lib/driver/connection.js, which gets
> installed in "open"
> {code:java}
> open() {
> if (this.isOpen) {
> return Promise.resolve();
> }
> if (this._openPromise) {
> return this._openPromise;
> }
> this.emit('log', `ws open`);
> this._ws = new WebSocket(this.url, {
> headers: this.options.headers,
> ca: this.options.ca,
> cert: this.options.cert,
> pfx: this.options.pfx,
> rejectUnauthorized: this.options.rejectUnauthorized
> });
> this._ws.on('message', (data) => this._handleMessage(data));
> // *** Install error handler
> this._ws.on('error', (err) => this._handleError(err));
> ...
> }
> _handleError(err) {
> this.emit('log', `ws error ${err}`);
> console.error("* Added log to improve debug
> ")
> this._cleanupWebsocket();
> this.emit('error', err); // Error ist thrown here
> }{code}
>
> In the debugger I can see that the error is caused in
> *stream_base_commons.js:*
> {code:java}
> function onStreamRead(arrayBuffer) {
> const nread = streamBaseState[kReadBytesOrError];
> const handle = this;
> const stream = this[owner_symbol];
> stream[kUpdateTimer]();
> if (nread > 0 && !stream.destroyed) {
>const offset = streamBaseState[kArrayBufferOffset];
>const buf = new FastBuffer(arrayBuffer, offset, nread);
>if (!stream.push(buf)) {
> handle.reading = false;
> if (!stream.destroyed) {
>const err = handle.readStop();
>if (err)
> stream.destroy(errnoException(err, 'read'));
> }
>}
>return;
> }
> if (nread === 0) {
>return;
> }
> if (nread !== UV_EOF) {
>/*Happens here */ return stream.destroy(errnoException(nread,
> 'read'));
> }
> ...
> }
> {code}
>
> So my questions are:
> * Why is the error thrown in the first place. (After app idles for 5-10
> minutes)
> ** What happens in "this.emit('error', err);" in "Connection._handleError".
> * What is the right place to catch the error? I've of course wrapped the
> "submit" code above in try/catch (in case of async/await) or as
> "then(...).catch()..." (in case of using the promise directly). Since the
> error causes nodejs to exit, it's quite bad.:)
> ** As it all happens asynchronously, I would need something like an
> "onError" handler. But the web socket and its handler
> (this._ws.on('error')...) are within the "Connection" class.
> The attached image shows the stack trace in Visual Studio Code Debugger.
> Any help is appreciated!
> Thanks
> Thomas
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2229) JavaScript GLV: Add GraphBinary Support
Jorge Bay created TINKERPOP-2229: Summary: JavaScript GLV: Add GraphBinary Support Key: TINKERPOP-2229 URL: https://issues.apache.org/jira/browse/TINKERPOP-2229 Project: TinkerPop Issue Type: Improvement Components: io, javascript Affects Versions: 3.4.1 Reporter: Jorge Bay After GraphBinary was introduced in the server and Java driver TINKERPOP-1942, we should add support in each GLV, in this case the JavaScript GLV. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2285) Error object is unreachable
[
https://issues.apache.org/jira/browse/TINKERPOP-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1697#comment-1697
]
Jorge Bay commented on TINKERPOP-2285:
--
hm... You mean that the error message is the string:
{code}
'{"requestId":"e44b2c9a-9542-461b-9d1b-bc3db3f869f4","code":"ConstraintViolationException","detailedMessage":"Edge
with id already exists: TEST|77886.105.1:NO_SIZE:0->WVN"}'
{code}
That is unexpected, as you pointed out the error message is the [stringified
response status
message|https://github.com/apache/tinkerpop/blob/3.4.3/gremlin-javascript/src/main/javascript/gremlin-javascript/lib/driver/connection.js#L265],
which is a string:
https://github.com/apache/tinkerpop/blob/master/gremlin-driver/src/main/java/org/apache/tinkerpop/gremlin/driver/message/ResponseStatus.java#L47
Are you using gremlin server or another database?
> Error object is unreachable
> ---
>
> Key: TINKERPOP-2285
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2285
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.3.8
>Reporter: Teonna Zaragoza
>Priority: Major
>
> In our currently application(React, node.js, Express), we are creating an
> edge between two existing nodes.
> {code:java}
> async function somethingThatQueriesGremlin() {
> try {
> const result = await theActualQuery();
> // ...
> } catch (error) {
> console.log(error); // I expect error to be useful and not a stringified
> instance of Error wrapped in an Error.
> }
> } {code}
> If the edge already exists, the error that is logged on the server is
> {code:javascript}
> Error: Server error:
> {"requestId":"e44b2c9a-9542-461b-9d1b-bc3db3f869f4","code":"ConstraintViolationException","detailedMessage":"Edge
> with id already exists: TEST|77886.105.1:NO_SIZE:0->WVN"} (499)
> at Connection._handleMessage
> (.../node_modules/gremlin/lib/driver/connection.js:265:9)
> at WebSocket._ws.on
> (.../node_modules/gremlin/lib/driver/connection.js:128:43)
> at emitOne (events.js:116:13)
> at WebSocket.emit (events.js:211:7)
> at Receiver._receiver.onmessage
> (.../node_modules/ws/lib/WebSocket.js:141:47)
> at Receiver.dataMessage (.../node_modules/ws/lib/Receiver.js:380:14)
> at Receiver.getData (.../node_modules/ws/lib/Receiver.js:330:12)
> at Receiver.startLoop (.../node_modules/ws/lib/Receiver.js:165:16)
> at Receiver.add (.../node_modules/ws/lib/Receiver.js:139:10)
> at TLSSocket._ultron.on (.../node_modules/ws/lib/WebSocket.js:138:22)
> at emitOne (events.js:116:13)
> at TLSSocket.emit (events.js:211:7)
> at addChunk (_stream_readable.js:263:12)
> at readableAddChunk (_stream_readable.js:250:11)
> at TLSSocket.Readable.push (_stream_readable.js:208:10)
> at TLSWrap.onread (net.js:607:20)
> object
> {code}
> The problem is that the actual error object with reachable keys is a string
> within another error object. The stringified object is reachable via
> err.message.
> The error comes from the driver in connection.js line 265
> {code:java}
> newError(util.format('Server error: %s
> (%d)',response.status.message,response.status.code)));
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (TINKERPOP-2287) GraphBinary: Support TypeSerializer lookup by superclass
[ https://issues.apache.org/jira/browse/TINKERPOP-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16911133#comment-16911133 ] Jorge Bay commented on TINKERPOP-2287: -- I've created this ticket as a way to kick off the discussions for https://github.com/apache/tinkerpop/pull/1180 > GraphBinary: Support TypeSerializer lookup by superclass > > > Key: TINKERPOP-2287 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2287 > Project: TinkerPop > Issue Type: Improvement > Components: driver, io >Reporter: Jorge Bay >Priority: Major > > It might be a good idea to allow setting the TypeSerializer by super class. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (TINKERPOP-2287) GraphBinary: Support TypeSerializer lookup by superclass
Jorge Bay created TINKERPOP-2287: Summary: GraphBinary: Support TypeSerializer lookup by superclass Key: TINKERPOP-2287 URL: https://issues.apache.org/jira/browse/TINKERPOP-2287 Project: TinkerPop Issue Type: Improvement Components: driver, io Reporter: Jorge Bay It might be a good idea to allow setting the TypeSerializer by super class. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (TINKERPOP-2287) GraphBinary: Support TypeSerializer lookup by superclass
[
https://issues.apache.org/jira/browse/TINKERPOP-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16911140#comment-16911140
]
Jorge Bay commented on TINKERPOP-2287:
--
We've started discussing the possibility of adding lookup by superclass with
[~justinchu] privately, that resulted in the PR he submitted.
Now that I think of it, outside {{InetAddress}}, I don't see much use of it.
It's more and more common to program against interfaces and we have interface
based resolution / lookup.
[~spmallette] Do you think it's worth the effort and complexity?
> GraphBinary: Support TypeSerializer lookup by superclass
>
>
> Key: TINKERPOP-2287
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2287
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver, io
>Reporter: Jorge Bay
>Priority: Major
>
> It might be a good idea to allow setting the TypeSerializer by super class.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (TINKERPOP-2287) GraphBinary: Support TypeSerializer lookup by superclass
[
https://issues.apache.org/jira/browse/TINKERPOP-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16911361#comment-16911361
]
Jorge Bay commented on TINKERPOP-2287:
--
I'm inclined to document the lack of support for superclass lookup and the
special case with TinkerPop {{InetAddress}} type and leave the functionality as
it is.
> GraphBinary: Support TypeSerializer lookup by superclass
>
>
> Key: TINKERPOP-2287
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2287
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver, io
>Reporter: Jorge Bay
>Priority: Major
>
> It might be a good idea to allow setting the TypeSerializer by super class.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (TINKERPOP-2285) Error object is unreachable
[
https://issues.apache.org/jira/browse/TINKERPOP-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16911456#comment-16911456
]
Jorge Bay commented on TINKERPOP-2285:
--
My guess is that AWS Neptune is sending the message in that (incorrect) format.
We should check against TinkerPop's Gremlin Server.
> Error object is unreachable
> ---
>
> Key: TINKERPOP-2285
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2285
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.3.8
>Reporter: Teonna Zaragoza
>Priority: Major
>
> In our currently application(React, node.js, Express), we are creating an
> edge between two existing nodes.
> {code:java}
> async function somethingThatQueriesGremlin() {
> try {
> const result = await theActualQuery();
> // ...
> } catch (error) {
> console.log(error); // I expect error to be useful and not a stringified
> instance of Error wrapped in an Error.
> }
> } {code}
> If the edge already exists, the error that is logged on the server is
> {code:javascript}
> Error: Server error:
> {"requestId":"e44b2c9a-9542-461b-9d1b-bc3db3f869f4","code":"ConstraintViolationException","detailedMessage":"Edge
> with id already exists: TEST|77886.105.1:NO_SIZE:0->WVN"} (499)
> at Connection._handleMessage
> (.../node_modules/gremlin/lib/driver/connection.js:265:9)
> at WebSocket._ws.on
> (.../node_modules/gremlin/lib/driver/connection.js:128:43)
> at emitOne (events.js:116:13)
> at WebSocket.emit (events.js:211:7)
> at Receiver._receiver.onmessage
> (.../node_modules/ws/lib/WebSocket.js:141:47)
> at Receiver.dataMessage (.../node_modules/ws/lib/Receiver.js:380:14)
> at Receiver.getData (.../node_modules/ws/lib/Receiver.js:330:12)
> at Receiver.startLoop (.../node_modules/ws/lib/Receiver.js:165:16)
> at Receiver.add (.../node_modules/ws/lib/Receiver.js:139:10)
> at TLSSocket._ultron.on (.../node_modules/ws/lib/WebSocket.js:138:22)
> at emitOne (events.js:116:13)
> at TLSSocket.emit (events.js:211:7)
> at addChunk (_stream_readable.js:263:12)
> at readableAddChunk (_stream_readable.js:250:11)
> at TLSSocket.Readable.push (_stream_readable.js:208:10)
> at TLSWrap.onread (net.js:607:20)
> object
> {code}
> The problem is that the actual error object with reachable keys is a string
> within another error object. The stringified object is reachable via
> err.message.
> The error comes from the driver in connection.js line 265
> {code:java}
> newError(util.format('Server error: %s
> (%d)',response.status.message,response.status.code)));
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (TINKERPOP-2285) Error object is unreachable
[
https://issues.apache.org/jira/browse/TINKERPOP-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914061#comment-16914061
]
Jorge Bay commented on TINKERPOP-2285:
--
When AWS Neptune exposes a gremlin interface based on TinkerPop, they have to
adhere to TinkerPop interfaces.
In this case, the status is composed by 2 fields: code (int) and message
(string).
For the message, AWS decided to pack more information in the status message in
json format. It's an AWS decision to do that and we can't modify the format
(like parsing the json string) without breaking other third party providers.
> Error object is unreachable
> ---
>
> Key: TINKERPOP-2285
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2285
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.3.8
>Reporter: Teonna Zaragoza
>Priority: Major
>
> In our currently application(React, node.js, Express), we are creating an
> edge between two existing nodes.
> {code:java}
> async function somethingThatQueriesGremlin() {
> try {
> const result = await theActualQuery();
> // ...
> } catch (error) {
> console.log(error); // I expect error to be useful and not a stringified
> instance of Error wrapped in an Error.
> }
> } {code}
> If the edge already exists, the error that is logged on the server is
> {code:javascript}
> Error: Server error:
> {"requestId":"e44b2c9a-9542-461b-9d1b-bc3db3f869f4","code":"ConstraintViolationException","detailedMessage":"Edge
> with id already exists: TEST|77886.105.1:NO_SIZE:0->WVN"} (499)
> at Connection._handleMessage
> (.../node_modules/gremlin/lib/driver/connection.js:265:9)
> at WebSocket._ws.on
> (.../node_modules/gremlin/lib/driver/connection.js:128:43)
> at emitOne (events.js:116:13)
> at WebSocket.emit (events.js:211:7)
> at Receiver._receiver.onmessage
> (.../node_modules/ws/lib/WebSocket.js:141:47)
> at Receiver.dataMessage (.../node_modules/ws/lib/Receiver.js:380:14)
> at Receiver.getData (.../node_modules/ws/lib/Receiver.js:330:12)
> at Receiver.startLoop (.../node_modules/ws/lib/Receiver.js:165:16)
> at Receiver.add (.../node_modules/ws/lib/Receiver.js:139:10)
> at TLSSocket._ultron.on (.../node_modules/ws/lib/WebSocket.js:138:22)
> at emitOne (events.js:116:13)
> at TLSSocket.emit (events.js:211:7)
> at addChunk (_stream_readable.js:263:12)
> at readableAddChunk (_stream_readable.js:250:11)
> at TLSSocket.Readable.push (_stream_readable.js:208:10)
> at TLSWrap.onread (net.js:607:20)
> object
> {code}
> The problem is that the actual error object with reachable keys is a string
> within another error object. The stringified object is reachable via
> err.message.
> The error comes from the driver in connection.js line 265
> {code:java}
> newError(util.format('Server error: %s
> (%d)',response.status.message,response.status.code)));
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (TINKERPOP-2290) Javascript GLV connection refused error handling
[
https://issues.apache.org/jira/browse/TINKERPOP-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay updated TINKERPOP-2290:
-
Attachment: testing.js
> Javascript GLV connection refused error handling
>
>
> Key: TINKERPOP-2290
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2290
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.4.1
>Reporter: Ted Wilmes
>Priority: Major
> Attachments: testing.js
>
>
> I believe the Javascript driver is emitting connection refused errors in a
> manner that makes it difficult for users to add in retry and other error
> handling logic. My Javascript knowledge is minimal so apologies if the below
> examples are non-idiomatic Javascript.
> Here's an example of the error:
> {code:java}
> UNCAUGHT: { Error: connect ECONNREFUSED 127.0.0.1:8182
> at Object._errnoException (util.js:1022:11)
> at _exceptionWithHostPort (util.js:1044:20)
> at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1198:14)
> code: 'ECONNREFUSED',
> errno: 'ECONNREFUSED',
> syscall: 'connect',
> address: '127.0.0.1',
> port: 8182 }
> UNCAUGHT: TypeError: Cannot read property 'aborted' of null
> at ClientRequest._req.on
> (/home/twilmes/repos/nodetest/node_modules/ws/lib/WebSocket.js:644:19)
> at emitOne (events.js:116:13)
> at ClientRequest.emit (events.js:211:7)
> at Socket.socketCloseListener (_http_client.js:363:9)
> at emitOne (events.js:121:20)
> at Socket.emit (events.js:211:7)
> at TCP._handle.close [as _onclose] (net.js:567:12) {code}
> I did some looking at that UNCAUGHT TypeError is a separate issue and appears
> to be fixed in a newer version of the WS package that is being used.
> To reproduce this problem, you can either start an application up and point
> it at a non-existant TP enabled DB (JanusGraph in my case) or turn the graph
> off while the application is running. After this is done, an error is logged
> but the only way I'm able to catch it is to do something like this:
> {code:java}
> process.on('uncaughtException', function (err) {
>console.log("UNCAUGHT: ", err);
> });{code}
> Wrapping my queries and connection code in try/catch blocks does not catch
> anything.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (TINKERPOP-2290) Javascript GLV connection refused error handling
[
https://issues.apache.org/jira/browse/TINKERPOP-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16917642#comment-16917642
]
Jorge Bay commented on TINKERPOP-2290:
--
I was able to reproduce it using [^testing.js] script.
The {{Connection}} should not [emit a "error" event in
{{_handleError}}|https://github.com/apache/tinkerpop/blob/3.4.3/gremlin-javascript/src/main/javascript/gremlin-javascript/lib/driver/connection.js#L216]
as "error" is an special event in Node.js:
https://nodejs.org/api/events.html#events_error_events
> Javascript GLV connection refused error handling
>
>
> Key: TINKERPOP-2290
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2290
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.4.1
>Reporter: Ted Wilmes
>Priority: Major
> Attachments: testing.js
>
>
> I believe the Javascript driver is emitting connection refused errors in a
> manner that makes it difficult for users to add in retry and other error
> handling logic. My Javascript knowledge is minimal so apologies if the below
> examples are non-idiomatic Javascript.
> Here's an example of the error:
> {code:java}
> UNCAUGHT: { Error: connect ECONNREFUSED 127.0.0.1:8182
> at Object._errnoException (util.js:1022:11)
> at _exceptionWithHostPort (util.js:1044:20)
> at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1198:14)
> code: 'ECONNREFUSED',
> errno: 'ECONNREFUSED',
> syscall: 'connect',
> address: '127.0.0.1',
> port: 8182 }
> UNCAUGHT: TypeError: Cannot read property 'aborted' of null
> at ClientRequest._req.on
> (/home/twilmes/repos/nodetest/node_modules/ws/lib/WebSocket.js:644:19)
> at emitOne (events.js:116:13)
> at ClientRequest.emit (events.js:211:7)
> at Socket.socketCloseListener (_http_client.js:363:9)
> at emitOne (events.js:121:20)
> at Socket.emit (events.js:211:7)
> at TCP._handle.close [as _onclose] (net.js:567:12) {code}
> I did some looking at that UNCAUGHT TypeError is a separate issue and appears
> to be fixed in a newer version of the WS package that is being used.
> To reproduce this problem, you can either start an application up and point
> it at a non-existant TP enabled DB (JanusGraph in my case) or turn the graph
> off while the application is running. After this is done, an error is logged
> but the only way I'm able to catch it is to do something like this:
> {code:java}
> process.on('uncaughtException', function (err) {
>console.log("UNCAUGHT: ", err);
> });{code}
> Wrapping my queries and connection code in try/catch blocks does not catch
> anything.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (TINKERPOP-2301) gremlin-javascript: 'within' predicate does not support more than two parameters?
[
https://issues.apache.org/jira/browse/TINKERPOP-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938455#comment-16938455
]
Jorge Bay commented on TINKERPOP-2301:
--
{{within()}} supports multiple arguments:
https://github.com/apache/tinkerpop/blob/master/gremlin-javascript/src/main/javascript/gremlin-javascript/lib/process/traversal.js#L262
Can you provide more info? can you provide a code sample to reproduce it?
> gremlin-javascript: 'within' predicate does not support more than two
> parameters?
> -
>
> Key: TINKERPOP-2301
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2301
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Reporter: Igor Ostapenko
>Priority: Major
>
> Hi,
> In my case gremlin npm module talks to usual gremlin-server with TinkerGraph
> in memory. And it looks like 'within' predicate uses only the first two
> parameters. For example, something like g.V().has('name', within('a', 'b',
> 'c', 'd')) selects only 'a' and 'b' names. If I understand official Gremlin
> docs correctly it should support multiple arguments.
> Is it a bug or a misunderstanding?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2301) gremlin-javascript: 'within' predicate does not support more than two parameters?
[
https://issues.apache.org/jira/browse/TINKERPOP-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay closed TINKERPOP-2301.
Resolution: Not A Bug
> gremlin-javascript: 'within' predicate does not support more than two
> parameters?
> -
>
> Key: TINKERPOP-2301
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2301
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.4.1
>Reporter: Igor Ostapenko
>Priority: Major
> Fix For: 3.4.3
>
>
> Hi,
> In my case gremlin npm module talks to usual gremlin-server with TinkerGraph
> in memory. And it looks like 'within' predicate uses only the first two
> parameters. For example, something like g.V().has('name', within('a', 'b',
> 'c', 'd')) selects only 'a' and 'b' names. If I understand official Gremlin
> docs correctly it should support multiple arguments.
> Is it a bug or a misunderstanding?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2301) gremlin-javascript: 'within' predicate does not support more than two parameters?
[
https://issues.apache.org/jira/browse/TINKERPOP-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938709#comment-16938709
]
Jorge Bay commented on TINKERPOP-2301:
--
Glad to hear, thank you!
> gremlin-javascript: 'within' predicate does not support more than two
> parameters?
> -
>
> Key: TINKERPOP-2301
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2301
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.4.1
>Reporter: Igor Ostapenko
>Priority: Major
> Fix For: 3.4.3
>
>
> Hi,
> In my case gremlin npm module talks to usual gremlin-server with TinkerGraph
> in memory. And it looks like 'within' predicate uses only the first two
> parameters. For example, something like g.V().has('name', within('a', 'b',
> 'c', 'd')) selects only 'a' and 'b' names. If I understand official Gremlin
> docs correctly it should support multiple arguments.
> Is it a bug or a misunderstanding?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (TINKERPOP-2305) GraphBinary: Wrap Buffer API
Jorge Bay created TINKERPOP-2305:
Summary: GraphBinary: Wrap Buffer API
Key: TINKERPOP-2305
URL: https://issues.apache.org/jira/browse/TINKERPOP-2305
Project: TinkerPop
Issue Type: Improvement
Components: io
Affects Versions: 3.4.3
Reporter: Jorge Bay
Assignee: Jorge Bay
As discussed on the mailing list, we should wrap Netty's {{ByteBuf}} and expose
our own {{Buffer}} interface in the GraphBinary public API, exposing the same
{{readX()}} and {{writeX()}} methods of {{ByteBuf}}.
This change allows us to move GraphBinary serialization to gremlin-core,
simplifying dependency management for integrators.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work started] (TINKERPOP-2305) GraphBinary: Wrap Buffer API
[
https://issues.apache.org/jira/browse/TINKERPOP-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on TINKERPOP-2305 started by Jorge Bay.
> GraphBinary: Wrap Buffer API
>
>
> Key: TINKERPOP-2305
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2305
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.4.3
>Reporter: Jorge Bay
>Assignee: Jorge Bay
>Priority: Major
> Labels: graphbinary
>
> As discussed on the mailing list, we should wrap Netty's {{ByteBuf}} and
> expose our own {{Buffer}} interface in the GraphBinary public API, exposing
> the same {{readX()}} and {{writeX()}} methods of {{ByteBuf}}.
> This change allows us to move GraphBinary serialization to gremlin-core,
> simplifying dependency management for integrators.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (TINKERPOP-2305) GraphBinary: Wrap Buffer API
[
https://issues.apache.org/jira/browse/TINKERPOP-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay reopened TINKERPOP-2305:
--
reopening to set the fix version :/
> GraphBinary: Wrap Buffer API
>
>
> Key: TINKERPOP-2305
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2305
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.4.3
>Reporter: Jorge Bay
>Assignee: Jorge Bay
>Priority: Major
> Labels: graphbinary
>
> As discussed on the mailing list, we should wrap Netty's {{ByteBuf}} and
> expose our own {{Buffer}} interface in the GraphBinary public API, exposing
> the same {{readX()}} and {{writeX()}} methods of {{ByteBuf}}.
> This change allows us to move GraphBinary serialization to gremlin-core,
> simplifying dependency management for integrators.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2305) GraphBinary: Wrap Buffer API
[
https://issues.apache.org/jira/browse/TINKERPOP-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay closed TINKERPOP-2305.
Resolution: Done
Merged to {{tp34}} and {{tp34}} into {{master}}.
> GraphBinary: Wrap Buffer API
>
>
> Key: TINKERPOP-2305
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2305
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.4.3
>Reporter: Jorge Bay
>Assignee: Jorge Bay
>Priority: Major
> Labels: graphbinary
>
> As discussed on the mailing list, we should wrap Netty's {{ByteBuf}} and
> expose our own {{Buffer}} interface in the GraphBinary public API, exposing
> the same {{readX()}} and {{writeX()}} methods of {{ByteBuf}}.
> This change allows us to move GraphBinary serialization to gremlin-core,
> simplifying dependency management for integrators.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (TINKERPOP-2305) GraphBinary: Wrap Buffer API
[
https://issues.apache.org/jira/browse/TINKERPOP-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay updated TINKERPOP-2305:
-
Fix Version/s: 3.4.5
> GraphBinary: Wrap Buffer API
>
>
> Key: TINKERPOP-2305
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2305
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.4.3
>Reporter: Jorge Bay
>Assignee: Jorge Bay
>Priority: Major
> Labels: graphbinary
> Fix For: 3.4.5
>
>
> As discussed on the mailing list, we should wrap Netty's {{ByteBuf}} and
> expose our own {{Buffer}} interface in the GraphBinary public API, exposing
> the same {{readX()}} and {{writeX()}} methods of {{ByteBuf}}.
> This change allows us to move GraphBinary serialization to gremlin-core,
> simplifying dependency management for integrators.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2305) GraphBinary: Wrap Buffer API
[
https://issues.apache.org/jira/browse/TINKERPOP-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay closed TINKERPOP-2305.
Resolution: Done
> GraphBinary: Wrap Buffer API
>
>
> Key: TINKERPOP-2305
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2305
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.4.3
>Reporter: Jorge Bay
>Assignee: Jorge Bay
>Priority: Major
> Labels: graphbinary
> Fix For: 3.4.5
>
>
> As discussed on the mailing list, we should wrap Netty's {{ByteBuf}} and
> expose our own {{Buffer}} interface in the GraphBinary public API, exposing
> the same {{readX()}} and {{writeX()}} methods of {{ByteBuf}}.
> This change allows us to move GraphBinary serialization to gremlin-core,
> simplifying dependency management for integrators.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (TINKERPOP-2329) JavaScript GLV: Update websocket library dependency
Jorge Bay created TINKERPOP-2329: Summary: JavaScript GLV: Update websocket library dependency Key: TINKERPOP-2329 URL: https://issues.apache.org/jira/browse/TINKERPOP-2329 Project: TinkerPop Issue Type: Improvement Components: javascript Affects Versions: 3.4.4, 3.3.9 Reporter: Jorge Bay Assignee: Jorge Bay We are using [ws|https://github.com/websockets/ws] version 3.x which is more than 2 years old. We should try to update the dependency to a newer version, as long as it doesn't have an impact on the supported runtimes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2329) JavaScript GLV: Update websocket library dependency
[ https://issues.apache.org/jira/browse/TINKERPOP-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay closed TINKERPOP-2329. Fix Version/s: 3.3.10 3.4.5 Resolution: Done > JavaScript GLV: Update websocket library dependency > --- > > Key: TINKERPOP-2329 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2329 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Affects Versions: 3.3.9, 3.4.4 >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > Fix For: 3.4.5, 3.3.10 > > > We are using [ws|https://github.com/websockets/ws] version 3.x which is more > than 2 years old. > We should try to update the dependency to a newer version, as long as it > doesn't have an impact on the supported runtimes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2330) JavaScript GLV should expose GraphSON2Writer and GraphSONReader
[ https://issues.apache.org/jira/browse/TINKERPOP-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17021994#comment-17021994 ] Jorge Bay commented on TINKERPOP-2330: -- I would like to include it before 3.3.10 / 3.4.5 code freeze. > JavaScript GLV should expose GraphSON2Writer and GraphSONReader > --- > > Key: TINKERPOP-2330 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2330 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Affects Versions: 3.3.9, 3.4.4 >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > Fix For: 3.4.5, 3.3.10 > > > When adding support for GraphSON3 on the JavaScript GLV, I missed to leave a > GraphSON2 serializers for compatibility w/ older versions: > https://github.com/apache/tinkerpop/pull/858 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (TINKERPOP-2330) JavaScript GLV should expose GraphSON2Writer and GraphSONReader
[ https://issues.apache.org/jira/browse/TINKERPOP-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TINKERPOP-2330 started by Jorge Bay. > JavaScript GLV should expose GraphSON2Writer and GraphSONReader > --- > > Key: TINKERPOP-2330 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2330 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Affects Versions: 3.3.9, 3.4.4 >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > Fix For: 3.4.5, 3.3.10 > > > When adding support for GraphSON3 on the JavaScript GLV, I missed to leave a > GraphSON2 serializers for compatibility w/ older versions: > https://github.com/apache/tinkerpop/pull/858 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TINKERPOP-2330) JavaScript GLV should expose GraphSON2Writer and GraphSONReader
Jorge Bay created TINKERPOP-2330: Summary: JavaScript GLV should expose GraphSON2Writer and GraphSONReader Key: TINKERPOP-2330 URL: https://issues.apache.org/jira/browse/TINKERPOP-2330 Project: TinkerPop Issue Type: Improvement Components: javascript Affects Versions: 3.4.4, 3.3.9 Reporter: Jorge Bay Assignee: Jorge Bay Fix For: 3.4.5, 3.3.10 When adding support for GraphSON3 on the JavaScript GLV, I missed to leave a GraphSON2 serializers for compatibility w/ older versions: https://github.com/apache/tinkerpop/pull/858 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2330) JavaScript GLV should expose GraphSON2Writer and GraphSONReader
[ https://issues.apache.org/jira/browse/TINKERPOP-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17021996#comment-17021996 ] Jorge Bay commented on TINKERPOP-2330: -- I hope I'll have a patch for this today... > JavaScript GLV should expose GraphSON2Writer and GraphSONReader > --- > > Key: TINKERPOP-2330 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2330 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Affects Versions: 3.3.9, 3.4.4 >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > Fix For: 3.4.5, 3.3.10 > > > When adding support for GraphSON3 on the JavaScript GLV, I missed to leave a > GraphSON2 serializers for compatibility w/ older versions: > https://github.com/apache/tinkerpop/pull/858 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TINKERPOP-2332) JavaScript GLV: structure element toString() should internally call toString()
[
https://issues.apache.org/jira/browse/TINKERPOP-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay updated TINKERPOP-2332:
-
Component/s: javascript
> JavaScript GLV: structure element toString() should internally call toString()
> --
>
> Key: TINKERPOP-2332
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2332
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.3.9, 3.4.4
>Reporter: Jorge Bay
>Assignee: Jorge Bay
>Priority: Major
> Fix For: 3.4.5, 3.3.10
>
>
> Structure classes use String instance methods on properties that might not be
> strings.
> For example, current implementation:
> {code:javascript}
> class Property {
> // ...
> toString() {
> return 'p[' + this.key + '->' + this.value.substr(0, 20) + ']';
> }
> }
> {code}
> Should be:
> {code:javascript}
> class Property {
> // ...
> toString() {
> return 'p[' + this.key + '->' + this.value.toString().substr(0, 20) + ']';
> }
> }
> {code}
> Plus checking on null/undefined value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (TINKERPOP-2332) JavaScript GLV: structure element toString() should internally call toString()
Jorge Bay created TINKERPOP-2332:
Summary: JavaScript GLV: structure element toString() should
internally call toString()
Key: TINKERPOP-2332
URL: https://issues.apache.org/jira/browse/TINKERPOP-2332
Project: TinkerPop
Issue Type: Bug
Affects Versions: 3.4.4, 3.3.9
Reporter: Jorge Bay
Assignee: Jorge Bay
Fix For: 3.4.5, 3.3.10
Structure classes use String instance methods on properties that might not be
strings.
For example, current implementation:
{code:javascript}
class Property {
// ...
toString() {
return 'p[' + this.key + '->' + this.value.substr(0, 20) + ']';
}
}
{code}
Should be:
{code:javascript}
class Property {
// ...
toString() {
return 'p[' + this.key + '->' + this.value.toString().substr(0, 20) + ']';
}
}
{code}
Plus checking on null/undefined value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2332) JavaScript GLV: structure element toString() should internally call toString()
[
https://issues.apache.org/jira/browse/TINKERPOP-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023005#comment-17023005
]
Jorge Bay commented on TINKERPOP-2332:
--
I hope I'll have a patch for this by Monday morning.
> JavaScript GLV: structure element toString() should internally call toString()
> --
>
> Key: TINKERPOP-2332
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2332
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.3.9, 3.4.4
>Reporter: Jorge Bay
>Assignee: Jorge Bay
>Priority: Major
> Fix For: 3.4.5, 3.3.10
>
>
> Structure classes use String instance methods on properties that might not be
> strings.
> For example, current implementation:
> {code:javascript}
> class Property {
> // ...
> toString() {
> return 'p[' + this.key + '->' + this.value.substr(0, 20) + ']';
> }
> }
> {code}
> Should be:
> {code:javascript}
> class Property {
> // ...
> toString() {
> return 'p[' + this.key + '->' + this.value.toString().substr(0, 20) + ']';
> }
> }
> {code}
> Plus checking on null/undefined value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (TINKERPOP-2333) JavaScript GLV: GraphSON2/3 Edge deserialization is invalid
Jorge Bay created TINKERPOP-2333:
Summary: JavaScript GLV: GraphSON2/3 Edge deserialization is
invalid
Key: TINKERPOP-2333
URL: https://issues.apache.org/jira/browse/TINKERPOP-2333
Project: TinkerPop
Issue Type: Bug
Components: javascript
Reporter: Jorge Bay
Assignee: Jorge Bay
Edge is currently deserialized as:
{code:javascript}
new g.Edge(
this.reader.read(value['id']),
this.reader.read(value['outV']),
value['label'],
this.reader.read(value['inV']),
this.reader.read(value['properties'])
);
{code}
Expecting outV and inV as a nested element.
When the actual format is:
{code:javascript}
new Edge(
this.reader.read(value['id']),
new Vertex(this.reader.read(value['outV']),
this.reader.read(value['outVLabel'])),
value['label'],
new Vertex(this.reader.read(value['inV']),
this.reader.read(value['inVLabel'])),
this.reader.read(value['properties'])
);
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (TINKERPOP-2333) JavaScript GLV: GraphSON2/3 Edge deserialization is invalid
[
https://issues.apache.org/jira/browse/TINKERPOP-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay updated TINKERPOP-2333:
-
Affects Version/s: 3.3.9
3.4.4
> JavaScript GLV: GraphSON2/3 Edge deserialization is invalid
> ---
>
> Key: TINKERPOP-2333
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2333
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.3.9, 3.4.4
>Reporter: Jorge Bay
>Assignee: Jorge Bay
>Priority: Major
> Fix For: 3.4.5, 3.3.10
>
>
> Edge is currently deserialized as:
> {code:javascript}
> new g.Edge(
> this.reader.read(value['id']),
> this.reader.read(value['outV']),
> value['label'],
> this.reader.read(value['inV']),
> this.reader.read(value['properties'])
> );
> {code}
> Expecting outV and inV as a nested element.
> When the actual format is:
> {code:javascript}
> new Edge(
> this.reader.read(value['id']),
> new Vertex(this.reader.read(value['outV']),
> this.reader.read(value['outVLabel'])),
> value['label'],
> new Vertex(this.reader.read(value['inV']),
> this.reader.read(value['inVLabel'])),
> this.reader.read(value['properties'])
> );
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (TINKERPOP-2333) JavaScript GLV: GraphSON2/3 Edge deserialization is invalid
[
https://issues.apache.org/jira/browse/TINKERPOP-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay updated TINKERPOP-2333:
-
Fix Version/s: 3.3.10
3.4.5
> JavaScript GLV: GraphSON2/3 Edge deserialization is invalid
> ---
>
> Key: TINKERPOP-2333
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2333
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Reporter: Jorge Bay
>Assignee: Jorge Bay
>Priority: Major
> Fix For: 3.4.5, 3.3.10
>
>
> Edge is currently deserialized as:
> {code:javascript}
> new g.Edge(
> this.reader.read(value['id']),
> this.reader.read(value['outV']),
> value['label'],
> this.reader.read(value['inV']),
> this.reader.read(value['properties'])
> );
> {code}
> Expecting outV and inV as a nested element.
> When the actual format is:
> {code:javascript}
> new Edge(
> this.reader.read(value['id']),
> new Vertex(this.reader.read(value['outV']),
> this.reader.read(value['outVLabel'])),
> value['label'],
> new Vertex(this.reader.read(value['inV']),
> this.reader.read(value['inVLabel'])),
> this.reader.read(value['properties'])
> );
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2333) JavaScript GLV: GraphSON2/3 Edge deserialization is invalid
[
https://issues.apache.org/jira/browse/TINKERPOP-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17024238#comment-17024238
]
Jorge Bay commented on TINKERPOP-2333:
--
I'll submit a patch as part of TINKERPOP-2332, to minimize the noise in the
project for a simple fix.
> JavaScript GLV: GraphSON2/3 Edge deserialization is invalid
> ---
>
> Key: TINKERPOP-2333
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2333
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Reporter: Jorge Bay
>Assignee: Jorge Bay
>Priority: Major
>
> Edge is currently deserialized as:
> {code:javascript}
> new g.Edge(
> this.reader.read(value['id']),
> this.reader.read(value['outV']),
> value['label'],
> this.reader.read(value['inV']),
> this.reader.read(value['properties'])
> );
> {code}
> Expecting outV and inV as a nested element.
> When the actual format is:
> {code:javascript}
> new Edge(
> this.reader.read(value['id']),
> new Vertex(this.reader.read(value['outV']),
> this.reader.read(value['outVLabel'])),
> value['label'],
> new Vertex(this.reader.read(value['inV']),
> this.reader.read(value['inVLabel'])),
> this.reader.read(value['properties'])
> );
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2330) JavaScript GLV should expose GraphSON2Writer and GraphSONReader
[ https://issues.apache.org/jira/browse/TINKERPOP-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay closed TINKERPOP-2330. Resolution: Fixed > JavaScript GLV should expose GraphSON2Writer and GraphSONReader > --- > > Key: TINKERPOP-2330 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2330 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Affects Versions: 3.3.9, 3.4.4 >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > Fix For: 3.4.5, 3.3.10 > > > When adding support for GraphSON3 on the JavaScript GLV, I missed to leave a > GraphSON2 serializers for compatibility w/ older versions: > https://github.com/apache/tinkerpop/pull/858 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (TINKERPOP-2333) JavaScript GLV: GraphSON2/3 Edge deserialization is invalid
[
https://issues.apache.org/jira/browse/TINKERPOP-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on TINKERPOP-2333 started by Jorge Bay.
> JavaScript GLV: GraphSON2/3 Edge deserialization is invalid
> ---
>
> Key: TINKERPOP-2333
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2333
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.3.9, 3.4.4
>Reporter: Jorge Bay
>Assignee: Jorge Bay
>Priority: Major
> Fix For: 3.4.5, 3.3.10
>
>
> Edge is currently deserialized as:
> {code:javascript}
> new g.Edge(
> this.reader.read(value['id']),
> this.reader.read(value['outV']),
> value['label'],
> this.reader.read(value['inV']),
> this.reader.read(value['properties'])
> );
> {code}
> Expecting outV and inV as a nested element.
> When the actual format is:
> {code:javascript}
> new Edge(
> this.reader.read(value['id']),
> new Vertex(this.reader.read(value['outV']),
> this.reader.read(value['outVLabel'])),
> value['label'],
> new Vertex(this.reader.read(value['inV']),
> this.reader.read(value['inVLabel'])),
> this.reader.read(value['properties'])
> );
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2333) JavaScript GLV: GraphSON2/3 Edge deserialization is invalid
[
https://issues.apache.org/jira/browse/TINKERPOP-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17025040#comment-17025040
]
Jorge Bay commented on TINKERPOP-2333:
--
https://github.com/apache/tinkerpop/pull/1242
> JavaScript GLV: GraphSON2/3 Edge deserialization is invalid
> ---
>
> Key: TINKERPOP-2333
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2333
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.3.9, 3.4.4
>Reporter: Jorge Bay
>Assignee: Jorge Bay
>Priority: Major
> Fix For: 3.4.5, 3.3.10
>
>
> Edge is currently deserialized as:
> {code:javascript}
> new g.Edge(
> this.reader.read(value['id']),
> this.reader.read(value['outV']),
> value['label'],
> this.reader.read(value['inV']),
> this.reader.read(value['properties'])
> );
> {code}
> Expecting outV and inV as a nested element.
> When the actual format is:
> {code:javascript}
> new Edge(
> this.reader.read(value['id']),
> new Vertex(this.reader.read(value['outV']),
> this.reader.read(value['outVLabel'])),
> value['label'],
> new Vertex(this.reader.read(value['inV']),
> this.reader.read(value['inVLabel'])),
> this.reader.read(value['properties'])
> );
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2333) JavaScript GLV: GraphSON2/3 Edge deserialization is invalid
[
https://issues.apache.org/jira/browse/TINKERPOP-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay closed TINKERPOP-2333.
Resolution: Fixed
> JavaScript GLV: GraphSON2/3 Edge deserialization is invalid
> ---
>
> Key: TINKERPOP-2333
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2333
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.3.9, 3.4.4
>Reporter: Jorge Bay
>Assignee: Jorge Bay
>Priority: Major
> Fix For: 3.4.5, 3.3.10
>
>
> Edge is currently deserialized as:
> {code:javascript}
> new g.Edge(
> this.reader.read(value['id']),
> this.reader.read(value['outV']),
> value['label'],
> this.reader.read(value['inV']),
> this.reader.read(value['properties'])
> );
> {code}
> Expecting outV and inV as a nested element.
> When the actual format is:
> {code:javascript}
> new Edge(
> this.reader.read(value['id']),
> new Vertex(this.reader.read(value['outV']),
> this.reader.read(value['outVLabel'])),
> value['label'],
> new Vertex(this.reader.read(value['inV']),
> this.reader.read(value['inVLabel'])),
> this.reader.read(value['properties'])
> );
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2332) JavaScript GLV: structure element toString() should internally call toString()
[
https://issues.apache.org/jira/browse/TINKERPOP-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay closed TINKERPOP-2332.
Resolution: Fixed
> JavaScript GLV: structure element toString() should internally call toString()
> --
>
> Key: TINKERPOP-2332
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2332
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.3.9, 3.4.4
>Reporter: Jorge Bay
>Assignee: Jorge Bay
>Priority: Major
> Fix For: 3.4.5, 3.3.10
>
>
> Structure classes use String instance methods on properties that might not be
> strings.
> For example, current implementation:
> {code:javascript}
> class Property {
> // ...
> toString() {
> return 'p[' + this.key + '->' + this.value.substr(0, 20) + ']';
> }
> }
> {code}
> Should be:
> {code:javascript}
> class Property {
> // ...
> toString() {
> return 'p[' + this.key + '->' + this.value.toString().substr(0, 20) + ']';
> }
> }
> {code}
> Plus checking on null/undefined value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (TINKERPOP-2335) Drop support for older GLV runtimes
Jorge Bay created TINKERPOP-2335: Summary: Drop support for older GLV runtimes Key: TINKERPOP-2335 URL: https://issues.apache.org/jira/browse/TINKERPOP-2335 Project: TinkerPop Issue Type: Improvement Components: dotnet, javascript, python Reporter: Jorge Bay Fix For: 3.5.0 As [discussed on the mailing list|https://lists.apache.org/thread.html/r25901cdb66b913b32b025970a6cd435eae87609e5c5af3c8a4ce630a%40%3Cdev.tinkerpop.apache.org%3E], we should take the opportunity of the new revision to drop support for EOL'd runtimes for javascript, python and .NET. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TINKERPOP-2339) Gremlin.Net: Update System.Net.WebSockets.Client dependency
Jorge Bay created TINKERPOP-2339: Summary: Gremlin.Net: Update System.Net.WebSockets.Client dependency Key: TINKERPOP-2339 URL: https://issues.apache.org/jira/browse/TINKERPOP-2339 Project: TinkerPop Issue Type: Improvement Components: dotnet Affects Versions: 3.3.10, 3.4.5 Reporter: Jorge Bay Assignee: Jorge Bay Fix For: 3.3.11, 3.4.6 System.Net.WebSockets.Client 4.3.0 has some known vulnerabilities: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0248 We should update the dependency to 4.3.2+ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TINKERPOP-2339) Gremlin.Net: Update System.Net.WebSockets.Client dependency
[ https://issues.apache.org/jira/browse/TINKERPOP-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated TINKERPOP-2339: - Fix Version/s: (was: 3.4.6) (was: 3.3.11) > Gremlin.Net: Update System.Net.WebSocketsnClient dependency > --- > > Key: TINKERPOP-2339 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2339 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.4.5, 3.3.10 >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > > System.Net.WebSockets.Client 4.3.0 has some known vulnerabilities: > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CV-2017-0248 > We should update the dependency to 4.3.2+ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TINKERPOP-2339) Gremlin.Net: Update System.Net.WebSockets.Client dependency
[ https://issues.apache.org/jira/browse/TINKERPOP-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated TINKERPOP-2339: - Fix Version/s: 3.4.7 3.3.11 > Gremlin.Net: Update System.Net.WebSockets.Client dependency > --- > > Key: TINKERPOP-2339 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2339 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.4.5, 3.3.10 >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > Fix For: 3.3.11, 3.4.7 > > > System.Net.WebSockets.Client 4.3.0 has some known vulnerabilities: > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0248 > We should update the dependency to 4.3.2+ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2339) Gremlin.Net: Update System.Net.WebSockets.Client dependency
[ https://issues.apache.org/jira/browse/TINKERPOP-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay closed TINKERPOP-2339. Resolution: Fixed > Gremlin.Net: Update System.Net.WebSockets.Client dependency > --- > > Key: TINKERPOP-2339 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2339 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.4.5, 3.3.10 >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > Fix For: 3.3.11, 3.4.7 > > > System.Net.WebSockets.Client 4.3.0 has some known vulnerabilities: > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0248 > We should update the dependency to 4.3.2+ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TINKERPOP-2381) JavaScript GLV: Connection should not try to open in the background
Jorge Bay created TINKERPOP-2381:
Summary: JavaScript GLV: Connection should not try to open in the
background
Key: TINKERPOP-2381
URL: https://issues.apache.org/jira/browse/TINKERPOP-2381
Project: TinkerPop
Issue Type: Bug
Components: javascript
Affects Versions: 3.4.7
Reporter: Jorge Bay
There are several issues related to websocket connection opening that are
surfaced when the there isn't a webserver listening in the provided address.
To list the issues:
- Open is made in the background, that could cause {{unhandledRejection}}.
- Race condition between error handling and opening, causing the promise to
resolve and/or the process to exit (depending on the case).
We should refactor how {{Connection#open()}} is invoked by the {{Client}} to
always check that open was previously called and fix the race condition.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (TINKERPOP-2381) JavaScript GLV: Connection should not try to open in the background
[
https://issues.apache.org/jira/browse/TINKERPOP-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay updated TINKERPOP-2381:
-
Description:
There are several issues related to websocket connection opening that are
surfaced when the there isn't a server listening in the provided address.
To list the issues:
- Open is made in the background, that could cause {{unhandledRejection}}.
- Race condition between error handling and opening, causing the promise to
resolve and/or the process to exit (depending on the case).
We should refactor how {{Connection#open()}} is invoked by the {{Client}} to
always check that open was previously called and fix the race condition.
was:
There are several issues related to websocket connection opening that are
surfaced when the there isn't a webserver listening in the provided address.
To list the issues:
- Open is made in the background, that could cause {{unhandledRejection}}.
- Race condition between error handling and opening, causing the promise to
resolve and/or the process to exit (depending on the case).
We should refactor how {{Connection#open()}} is invoked by the {{Client}} to
always check that open was previously called and fix the race condition.
> JavaScript GLV: Connection should not try to open in the background
> ---
>
> Key: TINKERPOP-2381
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2381
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.4.7
>Reporter: Jorge Bay
>Priority: Major
>
> There are several issues related to websocket connection opening that are
> surfaced when the there isn't a server listening in the provided address.
> To list the issues:
> - Open is made in the background, that could cause {{unhandledRejection}}.
> - Race condition between error handling and opening, causing the promise to
> resolve and/or the process to exit (depending on the case).
> We should refactor how {{Connection#open()}} is invoked by the {{Client}} to
> always check that open was previously called and fix the race condition.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (TINKERPOP-2377) Investigate intermittent .NET GLV test failures
[
https://issues.apache.org/jira/browse/TINKERPOP-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay updated TINKERPOP-2377:
-
Fix Version/s: 3.5.0
> Investigate intermittent .NET GLV test failures
>
>
> Key: TINKERPOP-2377
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2377
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.4.6
>Reporter: Stephen Mallette
>Priority: Minor
> Fix For: 3.5.0
>
>
> Travis builds of .NET seem instable. Some of that instability is out of our
> control and bound to the travis environment but I've noticed at least one odd
> pattern of failure around these tests:
> {code}
> Failures and skipped scenarios:
> 1) g_V_constantXnullX: Failed
> System.Reflection.TargetInvocationException: Exception has been thrown by the
> target of an invocation.
> ---> System.ArgumentNullException: Value cannot be null. (Parameter 'key')
>at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)
>at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue&
> value)
>at Gremlin.Net.Process.Traversal.Bindings.GetBoundVariable[TV](TV value)
> in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bindings.cs:line
> 66
>at Gremlin.Net.Process.Traversal.Bytecode.ConvertArgument(Object argument,
> Boolean searchBindings) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs:line
> 113
>at Gremlin.Net.Process.Traversal.Bytecode.FlattenArguments(Object[]
> arguments) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs:line
> 105
>at Gremlin.Net.Process.Traversal.Bytecode.AddStep(String stepName,
> Object[] args) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs:line
> 88
>at Gremlin.Net.Process.Traversal.GraphTraversal`2.Constant[E2](E2 e) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/GraphTraversal.cs:line
> 428
>--- End of inner exception stack trace ---
>at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[]
> arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
>at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
> invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
>at
> Gremlin.Net.IntegrationTest.Gherkin.TraversalEvaluation.TraversalParser.GetTraversalFromTokens(IList`1
> tokens, GraphTraversalSource g, IDictionary`2 contextParameterValues, String
> traversalText) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Gherkin/TraversalEvaluation/TraversalParser.cs:line
> 78
>at
> Gremlin.Net.IntegrationTest.Gherkin.TraversalEvaluation.TraversalParser.GetTraversal(String
> traversalText, GraphTraversalSource g, IDictionary`2 contextParameterValues)
> in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Gherkin/TraversalEvaluation/TraversalParser.cs:line
> 69
>at
> Gremlin.Net.IntegrationTest.Gherkin.CommonSteps.TranslateTraversal(String
> traversalText) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Gherkin/CommonSteps.cs:line
> 108
> 2) g_V_outE_propertyXweight_nullX: Failed
> System.Reflection.TargetInvocationException: Exception has been thrown by the
> target of an invocation.
> ---> System.ArgumentNullException: Value cannot be null. (Parameter 'key')
>at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)
>at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue&
> value)
>at Gremlin.Net.Process.Traversal.Bindings.GetBoundVariable[TV](TV value)
> in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bindings.cs:line
> 66
>at Gremlin.Net.Process.Traversal.Bytecode.ConvertArgument(Object argument,
> Boolean searchBindings) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs:line
> 113
>at Gremlin.Net.Process.Traversal.Bytecode.FlattenArguments(Object[]
> arguments) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs:line
> 105
>at Gremlin.Net.Process.Traversal.Bytecode.AddStep(String stepName,
> Object[] args) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs:line
> 88
>at Gremlin.Net.Process.Traversal.GraphTraversal`2.Property(Object key,
> Object value, Object[] keyValues) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/GraphTravers
[jira] [Updated] (TINKERPOP-2377) Investigate intermittent .NET GLV test failures
[
https://issues.apache.org/jira/browse/TINKERPOP-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay updated TINKERPOP-2377:
-
Affects Version/s: (was: 3.4.6)
3.5.0
> Investigate intermittent .NET GLV test failures
>
>
> Key: TINKERPOP-2377
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2377
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.5.0
>Reporter: Stephen Mallette
>Priority: Minor
> Fix For: 3.5.0
>
>
> Travis builds of .NET seem instable. Some of that instability is out of our
> control and bound to the travis environment but I've noticed at least one odd
> pattern of failure around these tests:
> {code}
> Failures and skipped scenarios:
> 1) g_V_constantXnullX: Failed
> System.Reflection.TargetInvocationException: Exception has been thrown by the
> target of an invocation.
> ---> System.ArgumentNullException: Value cannot be null. (Parameter 'key')
>at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)
>at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue&
> value)
>at Gremlin.Net.Process.Traversal.Bindings.GetBoundVariable[TV](TV value)
> in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bindings.cs:line
> 66
>at Gremlin.Net.Process.Traversal.Bytecode.ConvertArgument(Object argument,
> Boolean searchBindings) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs:line
> 113
>at Gremlin.Net.Process.Traversal.Bytecode.FlattenArguments(Object[]
> arguments) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs:line
> 105
>at Gremlin.Net.Process.Traversal.Bytecode.AddStep(String stepName,
> Object[] args) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs:line
> 88
>at Gremlin.Net.Process.Traversal.GraphTraversal`2.Constant[E2](E2 e) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/GraphTraversal.cs:line
> 428
>--- End of inner exception stack trace ---
>at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[]
> arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
>at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
> invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
>at
> Gremlin.Net.IntegrationTest.Gherkin.TraversalEvaluation.TraversalParser.GetTraversalFromTokens(IList`1
> tokens, GraphTraversalSource g, IDictionary`2 contextParameterValues, String
> traversalText) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Gherkin/TraversalEvaluation/TraversalParser.cs:line
> 78
>at
> Gremlin.Net.IntegrationTest.Gherkin.TraversalEvaluation.TraversalParser.GetTraversal(String
> traversalText, GraphTraversalSource g, IDictionary`2 contextParameterValues)
> in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Gherkin/TraversalEvaluation/TraversalParser.cs:line
> 69
>at
> Gremlin.Net.IntegrationTest.Gherkin.CommonSteps.TranslateTraversal(String
> traversalText) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Gherkin/CommonSteps.cs:line
> 108
> 2) g_V_outE_propertyXweight_nullX: Failed
> System.Reflection.TargetInvocationException: Exception has been thrown by the
> target of an invocation.
> ---> System.ArgumentNullException: Value cannot be null. (Parameter 'key')
>at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)
>at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue&
> value)
>at Gremlin.Net.Process.Traversal.Bindings.GetBoundVariable[TV](TV value)
> in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bindings.cs:line
> 66
>at Gremlin.Net.Process.Traversal.Bytecode.ConvertArgument(Object argument,
> Boolean searchBindings) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs:line
> 113
>at Gremlin.Net.Process.Traversal.Bytecode.FlattenArguments(Object[]
> arguments) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs:line
> 105
>at Gremlin.Net.Process.Traversal.Bytecode.AddStep(String stepName,
> Object[] args) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs:line
> 88
>at Gremlin.Net.Process.Traversal.GraphTraversal`2.Property(Object key,
> Object value, Object[] keyValues) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/sr
[jira] [Closed] (TINKERPOP-2377) Investigate intermittent .NET GLV test failures
[
https://issues.apache.org/jira/browse/TINKERPOP-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay closed TINKERPOP-2377.
Resolution: Fixed
> Investigate intermittent .NET GLV test failures
>
>
> Key: TINKERPOP-2377
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2377
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.5.0
>Reporter: Stephen Mallette
>Priority: Minor
> Fix For: 3.5.0
>
>
> Travis builds of .NET seem instable. Some of that instability is out of our
> control and bound to the travis environment but I've noticed at least one odd
> pattern of failure around these tests:
> {code}
> Failures and skipped scenarios:
> 1) g_V_constantXnullX: Failed
> System.Reflection.TargetInvocationException: Exception has been thrown by the
> target of an invocation.
> ---> System.ArgumentNullException: Value cannot be null. (Parameter 'key')
>at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)
>at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue&
> value)
>at Gremlin.Net.Process.Traversal.Bindings.GetBoundVariable[TV](TV value)
> in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bindings.cs:line
> 66
>at Gremlin.Net.Process.Traversal.Bytecode.ConvertArgument(Object argument,
> Boolean searchBindings) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs:line
> 113
>at Gremlin.Net.Process.Traversal.Bytecode.FlattenArguments(Object[]
> arguments) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs:line
> 105
>at Gremlin.Net.Process.Traversal.Bytecode.AddStep(String stepName,
> Object[] args) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs:line
> 88
>at Gremlin.Net.Process.Traversal.GraphTraversal`2.Constant[E2](E2 e) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/GraphTraversal.cs:line
> 428
>--- End of inner exception stack trace ---
>at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[]
> arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
>at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
> invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
>at
> Gremlin.Net.IntegrationTest.Gherkin.TraversalEvaluation.TraversalParser.GetTraversalFromTokens(IList`1
> tokens, GraphTraversalSource g, IDictionary`2 contextParameterValues, String
> traversalText) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Gherkin/TraversalEvaluation/TraversalParser.cs:line
> 78
>at
> Gremlin.Net.IntegrationTest.Gherkin.TraversalEvaluation.TraversalParser.GetTraversal(String
> traversalText, GraphTraversalSource g, IDictionary`2 contextParameterValues)
> in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Gherkin/TraversalEvaluation/TraversalParser.cs:line
> 69
>at
> Gremlin.Net.IntegrationTest.Gherkin.CommonSteps.TranslateTraversal(String
> traversalText) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Gherkin/CommonSteps.cs:line
> 108
> 2) g_V_outE_propertyXweight_nullX: Failed
> System.Reflection.TargetInvocationException: Exception has been thrown by the
> target of an invocation.
> ---> System.ArgumentNullException: Value cannot be null. (Parameter 'key')
>at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)
>at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue&
> value)
>at Gremlin.Net.Process.Traversal.Bindings.GetBoundVariable[TV](TV value)
> in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bindings.cs:line
> 66
>at Gremlin.Net.Process.Traversal.Bytecode.ConvertArgument(Object argument,
> Boolean searchBindings) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs:line
> 113
>at Gremlin.Net.Process.Traversal.Bytecode.FlattenArguments(Object[]
> arguments) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs:line
> 105
>at Gremlin.Net.Process.Traversal.Bytecode.AddStep(String stepName,
> Object[] args) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs:line
> 88
>at Gremlin.Net.Process.Traversal.GraphTraversal`2.Property(Object key,
> Object value, Object[] keyValues) in
> /home/travis/build/apache/tinkerpop/gremlin-dotnet/src/Gremlin.Net/Process/Traversal/GraphTraversal.cs
[jira] [Updated] (TINKERPOP-2716) Enable eslint for gremlin-javascript project
[ https://issues.apache.org/jira/browse/TINKERPOP-2716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated TINKERPOP-2716: - Issue Type: Improvement (was: Bug) > Enable eslint for gremlin-javascript project > > > Key: TINKERPOP-2716 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2716 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Affects Versions: 3.5.2 >Reporter: Tom Kolanko >Priority: Minor > > The gremlin-javascript project has no linter set so it's easy for code to be > formatted differently depending on the editor used to save the changes > From https://github.com/apache/tinkerpop/pull/1539#discussion_r818682368 we > can implement eslint + airbnb's config to have a standard which editors would > be able to pick up -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (TINKERPOP-2229) JavaScript GLV: Add GraphBinary Support
[ https://issues.apache.org/jira/browse/TINKERPOP-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay reassigned TINKERPOP-2229: Assignee: Jorge Bay > JavaScript GLV: Add GraphBinary Support > --- > > Key: TINKERPOP-2229 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2229 > Project: TinkerPop > Issue Type: Improvement > Components: io, javascript >Affects Versions: 3.4.1 >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > > After GraphBinary was introduced in the server and Java driver > TINKERPOP-1942, we should add support in each GLV, in this case the > JavaScript GLV. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (TINKERPOP-2229) JavaScript GLV: Add GraphBinary Support
[ https://issues.apache.org/jira/browse/TINKERPOP-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545334#comment-17545334 ] Jorge Bay commented on TINKERPOP-2229: -- https://github.com/apache/tinkerpop/pull/1547 > JavaScript GLV: Add GraphBinary Support > --- > > Key: TINKERPOP-2229 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2229 > Project: TinkerPop > Issue Type: Improvement > Components: io, javascript >Affects Versions: 3.4.1 >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > > After GraphBinary was introduced in the server and Java driver > TINKERPOP-1942, we should add support in each GLV, in this case the > JavaScript GLV. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (TINKERPOP-2229) JavaScript GLV: Add GraphBinary Support
[ https://issues.apache.org/jira/browse/TINKERPOP-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated TINKERPOP-2229: - Fix Version/s: 3.5.4 > JavaScript GLV: Add GraphBinary Support > --- > > Key: TINKERPOP-2229 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2229 > Project: TinkerPop > Issue Type: Improvement > Components: io, javascript >Affects Versions: 3.4.1 >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > Fix For: 3.5.4 > > > After GraphBinary was introduced in the server and Java driver > TINKERPOP-1942, we should add support in each GLV, in this case the > JavaScript GLV. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (TINKERPOP-2229) JavaScript GLV: Add GraphBinary Support
[ https://issues.apache.org/jira/browse/TINKERPOP-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay closed TINKERPOP-2229. Resolution: Done Completed by ihoro! > JavaScript GLV: Add GraphBinary Support > --- > > Key: TINKERPOP-2229 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2229 > Project: TinkerPop > Issue Type: Improvement > Components: io, javascript >Affects Versions: 3.4.1 >Reporter: Jorge Bay >Assignee: Jorge Bay >Priority: Major > Fix For: 3.5.4 > > > After GraphBinary was introduced in the server and Java driver > TINKERPOP-1942, we should add support in each GLV, in this case the > JavaScript GLV. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (TINKERPOP-1816) Consider improvements to the .NET documentation
[
https://issues.apache.org/jira/browse/TINKERPOP-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16220435#comment-16220435
]
Jorge Bay commented on TINKERPOP-1816:
--
Can you specify which areas are not covered in the docs:
http://tinkerpop.apache.org/docs/current/reference/#gremlin-DotNet
There are several C# code samples in the documentation. Apart from that, it's
just gremlin with C# code conventions.
> Consider improvements to the .NET documentation
> ---
>
> Key: TINKERPOP-1816
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1816
> Project: TinkerPop
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 3.2.6
>Reporter: Bill Woo
>Priority: Minor
>
> Without at least one complete code sample, you are wasting potential users;
> time.
> How do you run a query/traversal ?
> By "stumbling around in the dark" I was able to get this far:
> private Graph graph = new Graph();
> private GraphTraversalSource g;
> // in method body
> g = graph.Traversal().WithRemote(new DriverRemoteConnection(new
> GremlinClient(new GremlinServer("localhost", 8182;
>
> Vertex v1 = new Vertex("Bill");
> g.AddV(v1);
> Vertex v2 = new Vertex("Julie");
> g.AddV(v2);
> Edge e1 = new Edge("e1", v1, "Knows", v2);
> g.AddE(e1);
> VertexProperty p1 = new VertexProperty("p1","BillProp",
> "TestProp", v1);
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1816) Consider improvements to the .NET documentation
[
https://issues.apache.org/jira/browse/TINKERPOP-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16221858#comment-16221858
]
Jorge Bay commented on TINKERPOP-1816:
--
Looking at the initial title from the OP, "the .NET port has no useful
documentation", maybe it shows that there is a confusion of what the .NET GLV
is.
The GLV is not a gremlin machine written in another language (not a port), is
just a way to talk to a gremlin server using a different native language than
groovy/java.
The intro on the docs [On Gremlin Language
Variants|http://tinkerpop.apache.org/docs/current/reference/#_on_gremlin_language_variants]
provides further info:
bq. Gremlin is written in Java 8. There are various language variants of
Gremlin such as Gremlin-Groovy (packaged with TinkerPop3), Gremlin-Python
(packaged with TinkerPop3), Gremlin-Scala, Gremlin-JavaScript, Gremlin-Clojure
(known as Ogre), etc. It is best to think of Gremlin as a style of graph
traversing that is not bound to a particular programming language per se.
But it's separate (and several headers above) from the [Gremlin Variants
doc|http://tinkerpop.apache.org/docs/current/reference/#gremlin-variants],
which could give an incomplete picture.
I think we could join both doc topics, clarifying that the Gremlin server
implementation is written in java and you can communicate with it with any of
the language variants using a driver.
> Consider improvements to the .NET documentation
> ---
>
> Key: TINKERPOP-1816
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1816
> Project: TinkerPop
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 3.2.6
>Reporter: Bill Woo
>Priority: Minor
>
> Without at least one complete code sample, you are wasting potential users;
> time.
> How do you run a query/traversal ?
> By "stumbling around in the dark" I was able to get this far:
> private Graph graph = new Graph();
> private GraphTraversalSource g;
> // in method body
> g = graph.Traversal().WithRemote(new DriverRemoteConnection(new
> GremlinClient(new GremlinServer("localhost", 8182;
>
> Vertex v1 = new Vertex("Bill");
> g.AddV(v1);
> Vertex v2 = new Vertex("Julie");
> g.AddV(v2);
> Edge e1 = new Edge("e1", v1, "Knows", v2);
> g.AddE(e1);
> VertexProperty p1 = new VertexProperty("p1","BillProp",
> "TestProp", v1);
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
