[jira] [Created] (TINKERPOP-2754) Javascript client hangs if the server restarts
Yang Xia created TINKERPOP-2754:
---
Summary: Javascript client hangs if the server restarts
Key: TINKERPOP-2754
URL: https://issues.apache.org/jira/browse/TINKERPOP-2754
Project: TinkerPop
Issue Type: Bug
Components: javascript
Affects Versions: 3.5.2
Reporter: Yang Xia
Reported by [~avner.levy] under
https://issues.apache.org/jira/browse/TINKERPOP-2708:
I have a problem with the javascript client where if the server restarts the
client hangs forever (originally happens with AWS Neptune, but easy to
reproduce with Tinkerpop as well).
I've written this small program to demonstrate the issue:
import gremlin from 'gremlin';
const holdMainloop = setInterval(()=>console.log('holding mainloop'), 6);
const main = async () => {
try {
console.log('hello gremlin');
const traversal = gremlin.process.AnonymousTraversalSource.traversal;
const DriverRemoteConnection = gremlin.driver.DriverRemoteConnection;
const ID = gremlin.process.t.id;
const _ = gremlin.process.statics;
const __ = gremlin.process.P;
const driver = new DriverRemoteConnection('ws://localhost:8182/gremlin', {});
const log = (header)=>\{return (...args)=>console.log(new Date(),
header,JSON.stringify(args))};
const LABEL = 'Test';
driver.addListener('log', log('log:'));
driver.addListener('close', log('close:'));
driver.addListener('socketError', log('sockerError:'));
const g = traversal().withRemote(driver);
await g.V().hasLabel(LABEL).drop().next();
await g.addV(LABEL).property(ID,'1').next();
await g.addV(LABEL).property(ID,'2').next();
await g.addE(LABEL).from_({_}.V('1')).to({_}.V('2')).property(ID,'e1').next();
await g.addE(LABEL).from_({_}.V('2')).to({_}.V('1')).property(ID,'e2').next();
while (true) {
try {
const start = Date.now();
console.log(new Date(), 'before query');
await g.with_('evaluationTimeout',
1000).V('1').repeat(_.out()).times(1500).next();
console.log(new Date(), `after query, took ${Date.now() - start} ms`);
} catch (e)
{ console.log('Failed query: ', e); }
}
await driver.close();
} catch (e)
{ console.log('uncaught exception (exit):', e); }
};
try
{ await main(); }
catch (e)
{ console.log('exception in main: ', e); clearInterval(holdMainloop); }
I run the tinkerpop server in a container and kill it after the above program
is running for a few seconds.
2022-06-17T15:10:25.602Z before query
2022-06-17T15:10:26.247Z after query, took 645 ms
2022-06-17T15:10:26.247Z before query
2022-06-17T15:10:26.804Z after query, took 557 ms
2022-06-17T15:10:26.804Z before query
2022-06-17T15:10:27.458Z log: ["ws close code=1006 message="]
2022-06-17T15:10:27.459Z close: [1006,""]
2022-06-17T15:11:23.411Z holding mainloop
2022-06-17T15:12:23.414Z holding mainloop
...
I'm using 3.5.2.
Package,json:
{
"name": "playground",
"version": "1.0.0",
"description": "",
"main": "index.js",
"type": "module",
"keywords": [],
"author": "",
"license": "ISC",
"dependencies":
{ "gremlin": "^3.5.2" }
}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (TINKERPOP-2708) unhandledRejection upon connection failure
[
https://issues.apache.org/jira/browse/TINKERPOP-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17555719#comment-17555719
]
Yang Xia commented on TINKERPOP-2708:
-
Hi [~avner.levy], thank you for reporting the error. As this issue may have a
different root cause, I've opened another ticket to address it
https://issues.apache.org/jira/browse/TINKERPOP-2754. Feel free to follow-up
with comments there.
> unhandledRejection upon connection failure
> --
>
> Key: TINKERPOP-2708
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2708
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
>Affects Versions: 3.5.2
>Reporter: Jon Brede Skaug
>Priority: Major
>
> In the Javascript driver is unable to connect to the graph database for
> whatever reason an unhandledRejection warning occurs.
> I have tested this with `new DriverRemoteConnection`
> This is a silent error and it won't be able to catch the error due to the way
> it is handled.
> I've tracked it down to this line:
> [https://github.com/apache/tinkerpop/blob/c22c0141bb7a00f366f929d0e5d3c6379d1004e0/gremlin-javascript/src/main/javascript/gremlin-javascript/lib/driver/connection.js#L156]
> h2. *Solution suggestion*
> A fairly quick solution (but possibly breaking change) to this is by not
> opening the database in the constructor [(line reference
> L105)|https://github.com/apache/tinkerpop/blob/c22c0141bb7a00f366f929d0e5d3c6379d1004e0/gremlin-javascript/src/main/javascript/gremlin-javascript/lib/driver/connection.js#L105]
> but instead forcing the user to run the `DriverRemoteConnection.open()`
> after the constructor has been initialized. `DriverRemoteConnection.open()`
> returns a promise which makes more sense and is a bit more intuitive. The
> current error message gives an error about DNS which is increadibly confusing
> without deepdiving into the Gremlin driver code and navigating through 3
> classes to find the culprit. It's also an error which seems a bit more
> harmless than it actually is.
> It'salso possible to set option.connectOnStartup to "false" by default, this
> however will require the user to be aware of the possible failure upon
> setting it to true. I believe forcing the user to run .open() after
> initializing the class may be more robust.
> By doing it this way the user can instead handle the error raised by
> DriverRemoteConnection.open() by using promise.catch() or an async function
> using await. Promise.catch() is as provided:
> {code:java}
> this.drc.open().catch(err => {
> console.log("Unable to open connection to database", err);
> });{code}
> h2. *{{Temporary work around example}}*
>
> {code:java}
> // Using promises
> const drc = new DriverRemoteConnection(url, {connectOnStartup: false});
> drc.open().catch(err => {
>// Handle error upon open, i.e using retry and backoff logic, notify an
> alarm system or setting a global variable to reject requests.
> });{code}
>
> h2. *The issue with not handling the error properly:*
> Not handling the error properly means that if you pass in an invalid URL or
> the gremlin compatible database is down, it won't be able to handle the
> connection error before a transaction is attempted.
> In the future Node.js unhandledRejection will terminate the Node.js process.
> This can cause critical failure of processes upon boot and may even cause
> DDoS situations where processes may flood the gremlin compatible database
> with connection attempts due to processes failing and being reinstated over
> and over by a process monitor.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (TINKERPOP-2734) NullPointerException when calling Client chooseConnection()
[
https://issues.apache.org/jira/browse/TINKERPOP-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17555751#comment-17555751
]
Yang Xia commented on TINKERPOP-2734:
-
A PR with potential fix is up
[https://github.com/apache/tinkerpop/pull/1697|https://github.com/apache/tinkerpop/pull/1697.]:
"Could not reproduce the issue without given reproduction steps, and also seems
that it would require specific server circumstance.
However, investigation of the log traces the reporter included in the ticket
gives clues of where to look, and a potential but unlikely NPE was logically
deduced. Unsure if this will fix this specific user's problem but worth fixing
regardless.
As a side effect, also reduces an unneeded coupling due to inheritance on the
Client type."
> NullPointerException when calling Client chooseConnection()
> ---
>
> Key: TINKERPOP-2734
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2734
> Project: TinkerPop
> Issue Type: Bug
> Components: driver
>Affects Versions: 3.5.2
>Reporter: Mark Bennett
>Priority: Major
>
> This is similar to TINKERPOP-2597 and reported fixed in gremlin driver 3.5.2.
> However, we are still getting intermittent null pointer exceptions, and our
> stack trace it a bit different:
> {code:java}
> java.lang.NullPointerException: null
> at
> org.apache.tinkerpop.gremlin.driver.Client$SessionedClient.chooseConnection(Client.java:813)
> at org.apache.tinkerpop.gremlin.driver.Client.submitAsync(Client.java:390)
> at org.apache.tinkerpop.gremlin.driver.Client.submitAsync(Client.java:373)
> at org.apache.tinkerpop.gremlin.driver.Client.submitAsync(Client.java:298)
> at org.apache.tinkerpop.gremlin.driver.Client.submit(Client.java:250)
> {code}
> In addition we see this in our logs:
> class=org.apache.tinkerpop.gremlin.driver.ConnectionPool
> Signalled closing of connection pool on Host\{..}
> class=org.apache.tinkerpop.gremlin.driver.Client
> Could not initialize client for Optional[..]
> Seeing a lot of this too:
> Timed-out (16000 MILLISECONDS) waiting for connection on Host{}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (TINKERPOP-2734) NullPointerException when calling Client chooseConnection()
[
https://issues.apache.org/jira/browse/TINKERPOP-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17555751#comment-17555751
]
Yang Xia edited comment on TINKERPOP-2734 at 6/17/22 8:12 PM:
--
A PR with potential fix is up [https://github.com/apache/tinkerpop/pull/1697] :
"Could not reproduce the issue without given reproduction steps, and also seems
that it would require specific server circumstance.
However, investigation of the log traces the reporter included in the ticket
gives clues of where to look, and a potential but unlikely NPE was logically
deduced. Unsure if this will fix this specific user's problem but worth fixing
regardless.
As a side effect, also reduces an unneeded coupling due to inheritance on the
Client type."
was (Author: xiazcy):
A PR with potential fix is up
[https://github.com/apache/tinkerpop/pull/1697|https://github.com/apache/tinkerpop/pull/1697.]:
"Could not reproduce the issue without given reproduction steps, and also seems
that it would require specific server circumstance.
However, investigation of the log traces the reporter included in the ticket
gives clues of where to look, and a potential but unlikely NPE was logically
deduced. Unsure if this will fix this specific user's problem but worth fixing
regardless.
As a side effect, also reduces an unneeded coupling due to inheritance on the
Client type."
> NullPointerException when calling Client chooseConnection()
> ---
>
> Key: TINKERPOP-2734
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2734
> Project: TinkerPop
> Issue Type: Bug
> Components: driver
>Affects Versions: 3.5.2
>Reporter: Mark Bennett
>Priority: Major
>
> This is similar to TINKERPOP-2597 and reported fixed in gremlin driver 3.5.2.
> However, we are still getting intermittent null pointer exceptions, and our
> stack trace it a bit different:
> {code:java}
> java.lang.NullPointerException: null
> at
> org.apache.tinkerpop.gremlin.driver.Client$SessionedClient.chooseConnection(Client.java:813)
> at org.apache.tinkerpop.gremlin.driver.Client.submitAsync(Client.java:390)
> at org.apache.tinkerpop.gremlin.driver.Client.submitAsync(Client.java:373)
> at org.apache.tinkerpop.gremlin.driver.Client.submitAsync(Client.java:298)
> at org.apache.tinkerpop.gremlin.driver.Client.submit(Client.java:250)
> {code}
> In addition we see this in our logs:
> class=org.apache.tinkerpop.gremlin.driver.ConnectionPool
> Signalled closing of connection pool on Host\{..}
> class=org.apache.tinkerpop.gremlin.driver.Client
> Could not initialize client for Optional[..]
> Seeing a lot of this too:
> Timed-out (16000 MILLISECONDS) waiting for connection on Host{}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (TINKERPOP-2765) Race condition during script creation when using UnifiedChannelizer
Yang Xia created TINKERPOP-2765:
---
Summary: Race condition during script creation when using
UnifiedChannelizer
Key: TINKERPOP-2765
URL: https://issues.apache.org/jira/browse/TINKERPOP-2765
Project: TinkerPop
Issue Type: Bug
Affects Versions: 3.5.3, 3.6.0, 3.6.1, 3.5.4
Reporter: Yang Xia
Running the following traversals in parallel in Gremlin Go with the
UnifiedChannelizer in 3.5.x and 3.6.x Gremlin servers leads to a floating
error, likely due to race condition during script generation:
{code:java}
g.With("evaluationTimeout",
10).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Iterate()
g.With("evaluationTimeout",
1).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Iterate()
g.With("evaluationTimeout", 1).With("evaluationTimeout",
10).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Iterate()
g.WithStrategies(OptionsStrategy(map[string]interface{}{"evaluationTimeout":
10})).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Itearte()
g.WithStrategies(OptionsStrategy(map[string]interface{}{"evaluationTimeout":
1})).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Iterate() {code}
Error traces:
Here we see a hybrid traversal generated that leads to compilation error.
{code:java}
gremlin-test-server | [ERROR]
GremlinGroovyScriptEngine$GroovyCacheLoader - Script compilation FAILED
gremlinscriptengine__ggremlinscriptengine__g.with.with("evaluationTimeout","evaluationTimeout",1L10L))..injectinject((1L1L)).sideEffect(.sideEffect({Thread.sleep(5000)}).none(){Thread.sleep(5000)}).none()
took 3ms {}
gremlin-test-server |
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
gremlin-test-server | Script4.groovy: 1: expecting ')', found '10L'
@ line 1, column 102.
gremlin-test-server |ut","evaluationTimeout",1L10L))..inj
gremlin-test-server | ^
gremlin-test-server |
gremlin-test-server | 1 error
gremlin-test-server |
gremlin-test-server | at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:311)
gremlin-test-server | at
org.codehaus.groovy.control.ErrorCollector.addFatalError(ErrorCollector.java:151)
gremlin-test-server | at
org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:121)
gremlin-test-server | at
org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:133)
{code}
{code:java}
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script4.groovy: 1: unexpected token: . @ line 1, column 53.
.inject((int) 1).sideE.inject(.inject((i
^1 error at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:311)
at
org.codehaus.groovy.control.ErrorCollector.addFatalError(ErrorCollector.java:151)
at
org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:121)
at
org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:133)
at org.codehaus.groovy.control.SourceUnit.addError(SourceUnit.java:325)
at
org.codehaus.groovy.antlr.AntlrParserPlugin.transformCSTIntoAST(AntlrParserPlugin.java:224)
at
org.codehaus.groovy.antlr.AntlrParserPlugin.parseCST(AntlrParserPlugin.java:192)
at org.codehaus.groovy.control.SourceUnit.parse(SourceUnit.java:226)
at
org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:201)
at
org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:965)
at
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:642)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:618)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:595)
at
groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:401)
at groovy.lang.GroovyClassLoader.access$300(GroovyClassLoader.java:89)
at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:341)
at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:338)
at
org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache.getAndPut(ConcurrentCommonCache.java:147)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:336)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:320)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:262)
at
org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine$GroovyCacheLoader.lambda$
[jira] [Updated] (TINKERPOP-2765) Race condition during script creation when using UnifiedChannelizer
[
https://issues.apache.org/jira/browse/TINKERPOP-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2765:
Description:
Running the following traversals in parallel in Gremlin Go with the
UnifiedChannelizer in 3.5.x and 3.6.x Gremlin servers leads to a floating
error, likely due to race condition during script generation:
{code:java}
g.With("evaluationTimeout",
10).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Iterate()
g.With("evaluationTimeout",
1).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Iterate()
g.With("evaluationTimeout", 1).With("evaluationTimeout",
10).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Iterate()
g.WithStrategies(OptionsStrategy(map[string]interface{}{"evaluationTimeout":
10})).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Itearte()
g.WithStrategies(OptionsStrategy(map[string]interface{}{"evaluationTimeout":
1})).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Iterate() {code}
Error traces:
Here we see a hybrid traversal generated that leads to compilation error.
{code:java}
gremlin-test-server | [ERROR]
GremlinGroovyScriptEngine$GroovyCacheLoader - Script compilation FAILED
gremlinscriptengine__ggremlinscriptengine__g.with.with("evaluationTimeout","evaluationTimeout",1L10L))..injectinject((1L1L)).sideEffect(.sideEffect({Thread.sleep(5000)}).none(){Thread.sleep(5000)}).none()
took 3ms {}
gremlin-test-server |
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
gremlin-test-server | Script4.groovy: 1: expecting ')', found '10L'
@ line 1, column 102.
gremlin-test-server |ut","evaluationTimeout",1L10L))..inj
gremlin-test-server | ^
gremlin-test-server |
gremlin-test-server | 1 error
gremlin-test-server |
gremlin-test-server | at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:311)
gremlin-test-server | at
org.codehaus.groovy.control.ErrorCollector.addFatalError(ErrorCollector.java:151)
gremlin-test-server | at
org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:121)
gremlin-test-server | at
org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:133)
{code}
{code:java}
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script4.groovy: 1: unexpected token: . @ line 1, column 53.
.inject((int) 1).sideE.inject(.inject((i
^1 error at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:311)
at
org.codehaus.groovy.control.ErrorCollector.addFatalError(ErrorCollector.java:151)
at
org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:121)
at
org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:133)
at org.codehaus.groovy.control.SourceUnit.addError(SourceUnit.java:325)
at
org.codehaus.groovy.antlr.AntlrParserPlugin.transformCSTIntoAST(AntlrParserPlugin.java:224)
at
org.codehaus.groovy.antlr.AntlrParserPlugin.parseCST(AntlrParserPlugin.java:192)
at org.codehaus.groovy.control.SourceUnit.parse(SourceUnit.java:226)
at
org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:201)
at
org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:965)
at
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:642)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:618)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:595)
at
groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:401)
at groovy.lang.GroovyClassLoader.access$300(GroovyClassLoader.java:89)
at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:341)
at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:338)
at
org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache.getAndPut(ConcurrentCommonCache.java:147)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:336)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:320)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:262)
at
org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine$GroovyCacheLoader.lambda$load$0(GremlinGroovyScriptEngine.java:821)
at
java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
at
java.base/java.util.concurrent.CompletableFuture.a
[jira] [Updated] (TINKERPOP-2765) Race condition during script creation when using UnifiedChannelizer
[
https://issues.apache.org/jira/browse/TINKERPOP-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2765:
Description:
Running the following traversals in parallel in Gremlin Go with the
UnifiedChannelizer in 3.5.x and 3.6.x Gremlin servers leads to a floating
error, likely due to race condition during script generation:
{code:java}
g.With("evaluationTimeout",
10).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Iterate()
g.With("evaluationTimeout",
1).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Iterate()
g.With("evaluationTimeout", 1).With("evaluationTimeout",
10).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Iterate()
g.WithStrategies(OptionsStrategy(map[string]interface{}{"evaluationTimeout":
10})).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Itearte()
g.WithStrategies(OptionsStrategy(map[string]interface{}{"evaluationTimeout":
1})).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Iterate() {code}
Error traces:
Here we see a hybrid traversal generated that leads to compilation error.
{code:java}
gremlin-test-server | [ERROR]
GremlinGroovyScriptEngine$GroovyCacheLoader - Script compilation FAILED
gremlinscriptengine__ggremlinscriptengine__g.with.with("evaluationTimeout","evaluationTimeout",1L10L))..injectinject((1L1L)).sideEffect(.sideEffect({Thread.sleep(5000)}).none(){Thread.sleep(5000)}).none()
took 3ms {}
gremlin-test-server |
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
gremlin-test-server | Script4.groovy: 1: expecting ')', found '10L'
@ line 1, column 102.
gremlin-test-server |ut","evaluationTimeout",1L10L))..inj
gremlin-test-server | ^
gremlin-test-server |
gremlin-test-server | 1 error
gremlin-test-server |
gremlin-test-server | at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:311)
gremlin-test-server | at
org.codehaus.groovy.control.ErrorCollector.addFatalError(ErrorCollector.java:151)
gremlin-test-server | at
org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:121)
gremlin-test-server | at
org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:133)
{code}
{code:java}
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script4.groovy: 1: unexpected token: . @ line 1, column 53.
.inject((int) 1).sideE.inject(.inject((i
^1 error at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:311)
at
org.codehaus.groovy.control.ErrorCollector.addFatalError(ErrorCollector.java:151)
at
org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:121)
at
org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:133)
at org.codehaus.groovy.control.SourceUnit.addError(SourceUnit.java:325)
at
org.codehaus.groovy.antlr.AntlrParserPlugin.transformCSTIntoAST(AntlrParserPlugin.java:224)
at
org.codehaus.groovy.antlr.AntlrParserPlugin.parseCST(AntlrParserPlugin.java:192)
at org.codehaus.groovy.control.SourceUnit.parse(SourceUnit.java:226)
at
org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:201)
at
org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:965)
at
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:642)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:618)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:595)
at
groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:401)
at groovy.lang.GroovyClassLoader.access$300(GroovyClassLoader.java:89)
at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:341)
at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:338)
at
org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache.getAndPut(ConcurrentCommonCache.java:147)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:336)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:320)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:262)
at
org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine$GroovyCacheLoader.lambda$load$0(GremlinGroovyScriptEngine.java:821)
at
java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
at
java.base/java.util.concurrent.CompletableFuture.a
[jira] [Updated] (TINKERPOP-2765) Race condition during script creation when using UnifiedChannelizer
[
https://issues.apache.org/jira/browse/TINKERPOP-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2765:
Description:
Running the following traversals in parallel in Gremlin Go with the
UnifiedChannelizer in 3.5.x and 3.6.x Gremlin servers leads to a floating
error, likely a race condition during script generation:
{code:java}
g.With("evaluationTimeout",
10).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Iterate()
g.With("evaluationTimeout",
1).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Iterate()
g.With("evaluationTimeout", 1).With("evaluationTimeout",
10).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Iterate()
g.WithStrategies(OptionsStrategy(map[string]interface{}{"evaluationTimeout":
10})).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Itearte()
g.WithStrategies(OptionsStrategy(map[string]interface{}{"evaluationTimeout":
1})).Inject(1).SideEffect(&Lambda{"Thread.sleep(5000)",
"gremlin-groovy"}).Iterate() {code}
Error traces:
Here we see a hybrid traversal generated that leads to compilation error.
{code:java}
gremlin-test-server | [ERROR]
GremlinGroovyScriptEngine$GroovyCacheLoader - Script compilation FAILED
gremlinscriptengine__ggremlinscriptengine__g.with.with("evaluationTimeout","evaluationTimeout",1L10L))..injectinject((1L1L)).sideEffect(.sideEffect({Thread.sleep(5000)}).none(){Thread.sleep(5000)}).none()
took 3ms {}
gremlin-test-server |
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
gremlin-test-server | Script4.groovy: 1: expecting ')', found '10L'
@ line 1, column 102.
gremlin-test-server |ut","evaluationTimeout",1L10L))..inj
gremlin-test-server | ^
gremlin-test-server |
gremlin-test-server | 1 error
gremlin-test-server |
gremlin-test-server | at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:311)
gremlin-test-server | at
org.codehaus.groovy.control.ErrorCollector.addFatalError(ErrorCollector.java:151)
gremlin-test-server | at
org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:121)
gremlin-test-server | at
org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:133)
{code}
{code:java}
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script4.groovy: 1: unexpected token: . @ line 1, column 53.
.inject((int) 1).sideE.inject(.inject((i
^1 error at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:311)
at
org.codehaus.groovy.control.ErrorCollector.addFatalError(ErrorCollector.java:151)
at
org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:121)
at
org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:133)
at org.codehaus.groovy.control.SourceUnit.addError(SourceUnit.java:325)
at
org.codehaus.groovy.antlr.AntlrParserPlugin.transformCSTIntoAST(AntlrParserPlugin.java:224)
at
org.codehaus.groovy.antlr.AntlrParserPlugin.parseCST(AntlrParserPlugin.java:192)
at org.codehaus.groovy.control.SourceUnit.parse(SourceUnit.java:226)
at
org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:201)
at
org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:965)
at
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:642)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:618)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:595)
at
groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:401)
at groovy.lang.GroovyClassLoader.access$300(GroovyClassLoader.java:89)
at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:341)
at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:338)
at
org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache.getAndPut(ConcurrentCommonCache.java:147)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:336)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:320)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:262)
at
org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine$GroovyCacheLoader.lambda$load$0(GremlinGroovyScriptEngine.java:821)
at
java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
at
java.base/java.util.concurrent.CompletableFuture.asyncS
[jira] [Created] (TINKERPOP-2780) Floating Javascript Integration Test Promise Error for GitHub Actions on windows
Yang Xia created TINKERPOP-2780:
---
Summary: Floating Javascript Integration Test Promise Error for
GitHub Actions on windows
Key: TINKERPOP-2780
URL: https://issues.apache.org/jira/browse/TINKERPOP-2780
Project: TinkerPop
Issue Type: Improvement
Components: javascript
Affects Versions: 3.5.4
Reporter: Yang Xia
We see occasional GHA failures on Windows involving to timeout errors with
Promises, such as one below:
{code:java}
[INFO] 1 failing
[INFO]
[INFO] 1) Client
[INFO] #submit()
[INFO] should send bytecode:
[INFO] Error: Timeout of 5000ms exceeded. For async tests and hooks,
ensure "done()" is called; if returning a Promise, ensure it resolves.
(D:\a\tinkerpop\tinkerpop\gremlin-javascript\src\main\javascript\gremlin-javascript\test\integration\client-tests.js){code}
May be related with errors in ConnectedComponents
https://issues.apache.org/jira/browse/TINKERPOP-2779
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2780) Floating Javascript Integration Test Promise Error for GitHub Actions on windows
[
https://issues.apache.org/jira/browse/TINKERPOP-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2780:
Description:
We see occasional GHA failures on Windows involving to timeout errors with
Promises, such as one below:
{code:java}
[INFO] 1 failing
[INFO]
[INFO] 1) Client
[INFO] #submit()
[INFO] should send bytecode:
[INFO] Error: Timeout of 5000ms exceeded. For async tests and hooks,
ensure "done()" is called; if returning a Promise, ensure it resolves.
(D:\a\tinkerpop\tinkerpop\gremlin-javascript\src\main\javascript\gremlin-javascript\test\integration\client-tests.js){code}
May be related with errors in ConnectedComponents
https://issues.apache.org/jira/browse/TINKERPOP-2779
was:
We see occasional GHA failures on Windows involving to timeout errors with
Promises, such as one below:
{code:java}
[INFO] 1 failing
[INFO]
[INFO] 1) Client
[INFO] #submit()
[INFO] should send bytecode:
[INFO] Error: Timeout of 5000ms exceeded. For async tests and hooks,
ensure "done()" is called; if returning a Promise, ensure it resolves.
(D:\a\tinkerpop\tinkerpop\gremlin-javascript\src\main\javascript\gremlin-javascript\test\integration\client-tests.js){code}
May be related with errors in ConnectedComponents
https://issues.apache.org/jira/browse/TINKERPOP-2779
> Floating Javascript Integration Test Promise Error for GitHub Actions on
> windows
>
>
> Key: TINKERPOP-2780
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2780
> Project: TinkerPop
> Issue Type: Improvement
> Components: javascript
>Affects Versions: 3.5.4
>Reporter: Yang Xia
>Priority: Minor
>
> We see occasional GHA failures on Windows involving to timeout errors with
> Promises, such as one below:
> {code:java}
> [INFO] 1 failing
> [INFO]
> [INFO] 1) Client
> [INFO] #submit()
> [INFO] should send bytecode:
> [INFO] Error: Timeout of 5000ms exceeded. For async tests and hooks,
> ensure "done()" is called; if returning a Promise, ensure it resolves.
> (D:\a\tinkerpop\tinkerpop\gremlin-javascript\src\main\javascript\gremlin-javascript\test\integration\client-tests.js){code}
> May be related with errors in ConnectedComponents
> https://issues.apache.org/jira/browse/TINKERPOP-2779
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-2791) Gremlin Javascript deserialize Long into Number but then serializes Number into Integer
Yang Xia created TINKERPOP-2791:
---
Summary: Gremlin Javascript deserialize Long into Number but then
serializes Number into Integer
Key: TINKERPOP-2791
URL: https://issues.apache.org/jira/browse/TINKERPOP-2791
Project: TinkerPop
Issue Type: Bug
Components: javascript
Affects Versions: 3.5.5
Reporter: Yang Xia
Currently, javascript cucumber test suite need the server to have
vertexIdManager set to INTEGER or ANY, or else there will be failing tests.
This appears to be due to javascript deserializing LONG type vertex ID into its
native Number type, and storing the vertex ID as a Number:
{code:java}
getting vertex object from server
{
'@type': 'g:Vertex',
'@value': { id: { '@type': 'g:Int64', '@value': 1 }, label: 'person' }
}
deserialized vertex id is of type
number{code}
So when the cucumber test queries the graph by the vertex, javascript
serializes the Number vertex ID as an INTEGER, and since TinkerGraph requires
the exact type of vertex IDs to match(i.e. a LONG), we get empty result and
failed tests:
{code:java}
serialize vertex id is of type
number
serializing this
1
serializing this
{ '@type': 'g:Vertex', '@value': { id: 1, label: 'person' } }
serializing this
{ '@type': 'g:Bytecode', '@value': { step: [ [Array], [Array] ] } }
listing result for
g.V(v1).bothE()
[]
F-{code}
So this forces javascript tests to use a server configuration of
gremlin.tinkergraph.vertexIdManager=INTEGER or
gremlin.tinkergraph.vertexIdManager=ANY in order to pass the cucumber tests.
The same failure will occur with GraphBinary as the logic runs the same.
This looks specific to javascript due to the Number typing. I’ve tested this
with the go driver to confirm, which passes cucumber tests with either LONG or
INTEGER vertexIdManager, as it deserializes the vertex IDs into matching types.
I've confirm in a separate query that with the LONG vertexId Manager, if we
create a vertex with toLong(vertexID), the query will be successful, e.g.
{code:java}
g.V(new Vertex(toLong(1))).bothE() {code}
{code:java}
serialize vertex id is of type
object
serializing this
{ '@type': 'g:Int64', '@value': '1' }
serializing this
{
'@type': 'g:Vertex',
'@value': { id: { '@type': 'g:Int64', '@value': '1' }, label: undefined }
}{code}
I assume the fix would involve either using the toLong() function
appropriately, or if it is possible, to create a custom Long type that can be
used when serializing/deserializing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2797) graph_traversal V() throws on IDs larger than 2^31
[
https://issues.apache.org/jira/browse/TINKERPOP-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602040#comment-17602040
]
Yang Xia commented on TINKERPOP-2797:
-
Hi [~pkemkes] , thank you for raising the issue. This new error is due to the
change in the default serialization format for python in 3.6.1 from GraphSON to
GraphBinary, which is more strict in the number typing.
To bypass the error you could either change the serializer back to GraphSON
when you create the drc:
g = traversal().withRemote(connection,
message_serializer=gremlin_python.driver.serializer.GraphSONMessageSerializer())
(additional details see
[https://tinkerpop.apache.org/docs/3.6.1/reference/#gremlin-python-configuration)]
Or you could use the `long()` helper converter from `statics.py`, to convert
large numerical requests:
print(f"2147483647: \{g.V(gremlin_python.statics.long(2147483647)).hasNext()}")
> graph_traversal V() throws on IDs larger than 2^31
> --
>
> Key: TINKERPOP-2797
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2797
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.6.1
> Environment: Windows 10, Python 3.10.6
>Reporter: Phillip Kemkes
>Priority: Major
>
> Hi,
> we've noticed that graph_traversal.py's V() does not take IDs larger or equal
> to 2^31 from version 3.6.1 on. It still worked on version 3.6.0.
> The following code replicates the issue:
> {code:java}
> g = traversal().withRemote(connection)
> print(f"2147483647: {g.V(2147483647).hasNext()}")
> print(f"2147483648: {g.V(2147483648).hasNext()}") {code}
> On version 3.6.0 it produces the following output:
> {code:java}
> 2147483647: False
> 2147483648: True{code}
> Note: The first ID does not exist in our graph, the latter does.
> On version 3.6.1, it crashes and the following output is created:
> {code:java}
> 2147483647: False
> Traceback (most recent call last):
> File "C:\tmp\struct-error-test.py", line 35, in
> print(f"2147483648: {g.V(2147483648).hasNext()}")
> File "C:\tmp\venv\lib\site-packages\gremlin_python\process\traversal.py",
> line 105, in hasNext
> return self.has_next()
> File "C:\tmp\venv\lib\site-packages\gremlin_python\process\traversal.py",
> line 109, in has_next
> self.traversal_strategies.apply_strategies(self)
> File "C:\tmp\venv\lib\site-packages\gremlin_python\process\traversal.py",
> line 682, in apply_strategies
> traversal_strategy.apply(traversal)
> File
> "C:\tmp\venv\lib\site-packages\gremlin_python\driver\remote_connection.py",
> line 78, in apply
> remote_traversal = self.remote_connection.submit(traversal.bytecode)
> File
> "C:\tmp\venv\lib\site-packages\gremlin_python\driver\driver_remote_connection.py",
> line 102, in submit
> result_set = self._client.submit(bytecode,
> request_options=self._extract_request_options(bytecode))
> File "C:\tmp\venv\lib\site-packages\gremlin_python\driver\client.py", line
> 149, in submit
> return self.submit_async(message, bindings=bindings,
> request_options=request_options).result()
> File "C:\Program Files\Python310\lib\concurrent\futures\_base.py", line
> 458, in result
> return self.__get_result()
> File "C:\Program Files\Python310\lib\concurrent\futures\_base.py", line
> 403, in __get_result
> raise self._exception
> File "C:\tmp\venv\lib\site-packages\gremlin_python\driver\connection.py",
> line 66, in cb
> f.result()
> File "C:\Program Files\Python310\lib\concurrent\futures\_base.py", line
> 451, in result
> return self.__get_result()
> File "C:\Program Files\Python310\lib\concurrent\futures\_base.py", line
> 403, in __get_result
> raise self._exception
> File "C:\Program Files\Python310\lib\concurrent\futures\thread.py", line
> 58, in run
> result = self.fn(*self.args, **self.kwargs)
> File "C:\tmp\venv\lib\site-packages\gremlin_python\driver\protocol.py",
> line 86, in write
> message = self._message_serializer.serialize_message(request_id,
> request_message)
> File "C:\tmp\venv\lib\site-packages\gremlin_python\driver\serializer.py",
> line 225, in serialize_message
> args = processor_obj.get_op_args(op, args)
> File "C:\tmp\venv\lib\site-packages\gremlin_python\driver\serializer.py",
> line 48, in get_op_args
> return op_method(args)
> File "C:\tmp\venv\lib\site-packages\gremlin_python\driver\serializer.py",
> line 88, in bytecode
> args['gremlin'] = self._writer.to_dict(gremlin)
> File
> "C:\tmp\venv\lib\site-packages\gremlin_python\structure\io\graphbinaryV1.py",
> line 168, in to_dict
> return self.serializers[t].dictify(obj, self, to_extend)
> File
> "C:\tmp\venv\lib\site-packages\gremlin_python\structure\io\graphbinaryV1.py",
> line 811, in dictify
> write
[jira] [Closed] (TINKERPOP-2797) graph_traversal V() throws on IDs larger than 2^31
[
https://issues.apache.org/jira/browse/TINKERPOP-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2797.
---
Resolution: Not A Bug
Error thrown due to new default GraphBinary serialization requires specifying
long number type through long(). Closing as error is expected and not a bug.
Could consider refining the error message or documentations around this in
future iteration.
> graph_traversal V() throws on IDs larger than 2^31
> --
>
> Key: TINKERPOP-2797
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2797
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.6.1
> Environment: Windows 10, Python 3.10.6
>Reporter: Phillip Kemkes
>Priority: Major
>
> Hi,
> we've noticed that graph_traversal.py's V() does not take IDs larger or equal
> to 2^31 from version 3.6.1 on. It still worked on version 3.6.0.
> The following code replicates the issue:
> {code:java}
> g = traversal().withRemote(connection)
> print(f"2147483647: {g.V(2147483647).hasNext()}")
> print(f"2147483648: {g.V(2147483648).hasNext()}") {code}
> On version 3.6.0 it produces the following output:
> {code:java}
> 2147483647: False
> 2147483648: True{code}
> Note: The first ID does not exist in our graph, the latter does.
> On version 3.6.1, it crashes and the following output is created:
> {code:java}
> 2147483647: False
> Traceback (most recent call last):
> File "C:\tmp\struct-error-test.py", line 35, in
> print(f"2147483648: {g.V(2147483648).hasNext()}")
> File "C:\tmp\venv\lib\site-packages\gremlin_python\process\traversal.py",
> line 105, in hasNext
> return self.has_next()
> File "C:\tmp\venv\lib\site-packages\gremlin_python\process\traversal.py",
> line 109, in has_next
> self.traversal_strategies.apply_strategies(self)
> File "C:\tmp\venv\lib\site-packages\gremlin_python\process\traversal.py",
> line 682, in apply_strategies
> traversal_strategy.apply(traversal)
> File
> "C:\tmp\venv\lib\site-packages\gremlin_python\driver\remote_connection.py",
> line 78, in apply
> remote_traversal = self.remote_connection.submit(traversal.bytecode)
> File
> "C:\tmp\venv\lib\site-packages\gremlin_python\driver\driver_remote_connection.py",
> line 102, in submit
> result_set = self._client.submit(bytecode,
> request_options=self._extract_request_options(bytecode))
> File "C:\tmp\venv\lib\site-packages\gremlin_python\driver\client.py", line
> 149, in submit
> return self.submit_async(message, bindings=bindings,
> request_options=request_options).result()
> File "C:\Program Files\Python310\lib\concurrent\futures\_base.py", line
> 458, in result
> return self.__get_result()
> File "C:\Program Files\Python310\lib\concurrent\futures\_base.py", line
> 403, in __get_result
> raise self._exception
> File "C:\tmp\venv\lib\site-packages\gremlin_python\driver\connection.py",
> line 66, in cb
> f.result()
> File "C:\Program Files\Python310\lib\concurrent\futures\_base.py", line
> 451, in result
> return self.__get_result()
> File "C:\Program Files\Python310\lib\concurrent\futures\_base.py", line
> 403, in __get_result
> raise self._exception
> File "C:\Program Files\Python310\lib\concurrent\futures\thread.py", line
> 58, in run
> result = self.fn(*self.args, **self.kwargs)
> File "C:\tmp\venv\lib\site-packages\gremlin_python\driver\protocol.py",
> line 86, in write
> message = self._message_serializer.serialize_message(request_id,
> request_message)
> File "C:\tmp\venv\lib\site-packages\gremlin_python\driver\serializer.py",
> line 225, in serialize_message
> args = processor_obj.get_op_args(op, args)
> File "C:\tmp\venv\lib\site-packages\gremlin_python\driver\serializer.py",
> line 48, in get_op_args
> return op_method(args)
> File "C:\tmp\venv\lib\site-packages\gremlin_python\driver\serializer.py",
> line 88, in bytecode
> args['gremlin'] = self._writer.to_dict(gremlin)
> File
> "C:\tmp\venv\lib\site-packages\gremlin_python\structure\io\graphbinaryV1.py",
> line 168, in to_dict
> return self.serializers[t].dictify(obj, self, to_extend)
> File
> "C:\tmp\venv\lib\site-packages\gremlin_python\structure\io\graphbinaryV1.py",
> line 811, in dictify
> writer.to_dict(arg, to_extend)
> File
> "C:\tmp\venv\lib\site-packages\gremlin_python\structure\io\graphbinaryV1.py",
> line 168, in to_dict
> return self.serializers[t].dictify(obj, self, to_extend)
> File
> "C:\tmp\venv\lib\site-packages\gremlin_python\structure\io\graphbinaryV1.py",
> line 253, in dictify
> to_extend.extend(cls.byte_format_pack(obj))
> struct.error: argument out of rangeProcess finished with exit code 1 {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-2802) Support Adding Custom Serializer for Gremlin Go
Yang Xia created TINKERPOP-2802: --- Summary: Support Adding Custom Serializer for Gremlin Go Key: TINKERPOP-2802 URL: https://issues.apache.org/jira/browse/TINKERPOP-2802 Project: TinkerPop Issue Type: Improvement Components: go Affects Versions: 3.6.2 Reporter: Yang Xia To enable mechanisms to add custom serializers in the Go driver, for compatibility with database specific types outside of TinkerPop, such as the JanusGraph RelationIdentifier. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2820) gremlin-python _close_session race condition/FD leak
[
https://issues.apache.org/jira/browse/TINKERPOP-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17629209#comment-17629209
]
Yang Xia commented on TINKERPOP-2820:
-
Thank you for raising this issue! We will take a look soon.
Please also feel free to open a PR with your proposed solution (targeting
3.5-dev).
> gremlin-python _close_session race condition/FD leak
>
>
> Key: TINKERPOP-2820
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2820
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.6.1
>Reporter: Alex Hamilton
>Priority: Minor
>
> There is a race condition in gremlin-python when closing session-based
> connections that results in leaking file descriptors for event loops -
> eventually leading to an `OSError [Errno 24] too many open files` error after
> enough transactions occur.
> The problem stems from a race condition when closing session based
> connections that causes the event loop opened for the session's connection to
> be left open.
> The problem is completely contained in these two methods from
> `gremlin_python.driver.client.py`
> ```py
> def close(self):
> # prevent the Client from being closed more than once. it raises errors
> if new jobby jobs
> # get submitted to the executor when it is shutdown
> if self._closed:
> return
> if self._session_enabled:
> self._close_session() # 1. (see below)
> log.info("Closing Client with url '%s'", self._url)
> while not self._pool.empty(): # 3. (see below)
> conn = self._pool.get(True)
> conn.close()
> self._executor.shutdown()
> self._closed = True
> def _close_session(self):
> message = request.RequestMessage(
> processor='session', op='close',
> args=\{'session': str(self._session)})
> conn = self._pool.get(True)
> return conn.write(message).result() # 2. (see below)
> ```
> 1. `_close_session()` called
> 2. `.result()` waits for the _write_ to finish, but does *not* wait for the
> _read_ to finish. `conn` does not get put back into `self._pool` until AFTER
> the read finishes (`gremlin_python.driver.connection.Connection._receive()`).
> However, this method returns early and goes to 3.
> 3. this while loop is not entered to close out the connections. This leaves
> the conn's event loop running, never to be closed.
> I was able to solve this by modifying `_close_session` as follows:
> ```py
> def _close_session(self):
> message = request.RequestMessage(
> processor='session', op='close',
> args=\{'session': str(self._session)})
> conn = self._pool.get(True)
> try:
> write_result_set = conn.write(message).result()
> return write_result_set.all().result() # wait for _receive() to finish
> except protocol.GremlinServerError:
> pass
> ```
> I'm not sure if this is the correct solution, but wanted to point out the bug.
> In the meantime however, I wrote a context manager to handle this cleanup for
> me
> ```py
> @contextlib.contextmanager
> def transaction():
> tx = g.tx()
> gtx = tx.begin()
> try:
> yield tx, gtx
> tx.commit()
> except Exception as e:
> tx.rollback()
> finally:
> while not tx._session_based_connection._client._pool.empty():
> conn = tx._session_based_connection._client._pool.get(True)
> conn.close()
> logger.info("Closed abandoned session connection")
> with transaction() as (tx, gtx):
> foo = gtx.some_traversal().to_list()
> # do something with foo
> gtx.some_other_traversal().iterate()
> ```
> Cheers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2809) High severity security vulnerability found in jackson databind
[ https://issues.apache.org/jira/browse/TINKERPOP-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17630018#comment-17630018 ] Yang Xia commented on TINKERPOP-2809: - It looks like 2.14.0 just came out on Nov 5 (https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind/2.14.0), should we bump to that version instead? > High severity security vulnerability found in jackson databind > -- > > Key: TINKERPOP-2809 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2809 > Project: TinkerPop > Issue Type: Bug > Components: server >Affects Versions: 3.6.1 >Reporter: Aaron Coady >Priority: Major > > Two High security vulnerabilities in jackson databind. Here are the two > links. > [https://nvd.nist.gov/vuln/detail/CVE-2022-42003] > [https://nvd.nist.gov/vuln/detail/CVE-2022-42004] > Fixes are in 2.14.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2828) Golang driver cannot deserialize edge id
[
https://issues.apache.org/jira/browse/TINKERPOP-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17637906#comment-17637906
]
Yang Xia commented on TINKERPOP-2828:
-
Please also note that we currently don't have a mechanism for plugging in
custom serializers in Gremlin-Go, but we are tracking for future
implementations here: https://issues.apache.org/jira/browse/TINKERPOP-2802 (as
`RelationIdentifier` is JanusGraph-specific, we would not be adding it into our
default serializer).
Thanks! Closing.
> Golang driver cannot deserialize edge id
>
>
> Key: TINKERPOP-2828
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2828
> Project: TinkerPop
> Issue Type: Bug
> Components: go
>Affects Versions: 3.6.1, 3.5.4
>Reporter: Navgeet
>Priority: Major
> Labels: golang
> Attachments: main.go
>
>
> The issue occurs when we call {{ElementMap}} for edges. On further debugging,
> I found {{label}} can be deserialized but not {{{}id{}}}.
>
> {noformat}
> Error occurred during operation gremlinServerWSProtocol.readLoop(): 'E0408:
> unknown data type to deserialize 0x0'
> Read loop error 'E0408: unknown data type to deserialize 0x0', closing read
> loop.
> Connection error callback invoked, closing protocol.
> E0408: unknown data type to deserialize 0x0
> {noformat}
> Please see attached code for reproducing the issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2828) Golang driver cannot deserialize edge id
[
https://issues.apache.org/jira/browse/TINKERPOP-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2828.
---
Resolution: Not A Bug
> Golang driver cannot deserialize edge id
>
>
> Key: TINKERPOP-2828
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2828
> Project: TinkerPop
> Issue Type: Bug
> Components: go
>Affects Versions: 3.6.1, 3.5.4
>Reporter: Navgeet
>Priority: Major
> Labels: golang
> Attachments: main.go
>
>
> The issue occurs when we call {{ElementMap}} for edges. On further debugging,
> I found {{label}} can be deserialized but not {{{}id{}}}.
>
> {noformat}
> Error occurred during operation gremlinServerWSProtocol.readLoop(): 'E0408:
> unknown data type to deserialize 0x0'
> Read loop error 'E0408: unknown data type to deserialize 0x0', closing read
> loop.
> Connection error callback invoked, closing protocol.
> E0408: unknown data type to deserialize 0x0
> {noformat}
> Please see attached code for reproducing the issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2480) User agent for Gremlin drivers
[ https://issues.apache.org/jira/browse/TINKERPOP-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17644588#comment-17644588 ] Yang Xia commented on TINKERPOP-2480: - User-Agent support has now been added to all branches. We will close this ticket after opening a separate one to track adding integration tests with Simple Socket Server for 3.7.x. > User agent for Gremlin drivers > -- > > Key: TINKERPOP-2480 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2480 > Project: TinkerPop > Issue Type: Improvement > Components: driver, server >Affects Versions: 3.4.8 >Reporter: Divij Vaidya >Priority: Minor > > Currently, a server does not distinguish amongst the different types of > clients connecting to it. This issue is to add a new feature to add user > agent field in the HTTP and WebSocket request header which could be used to > identify the specific client from which the request was made. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TINKERPOP-2480) User agent for Gremlin drivers
[ https://issues.apache.org/jira/browse/TINKERPOP-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia resolved TINKERPOP-2480. - Resolution: Implemented > User agent for Gremlin drivers > -- > > Key: TINKERPOP-2480 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2480 > Project: TinkerPop > Issue Type: Improvement > Components: driver, server >Affects Versions: 3.4.8 >Reporter: Divij Vaidya >Priority: Minor > > Currently, a server does not distinguish amongst the different types of > clients connecting to it. This issue is to add a new feature to add user > agent field in the HTTP and WebSocket request header which could be used to > identify the specific client from which the request was made. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TINKERPOP-2737) Dockerized Build and Test Environments
[ https://issues.apache.org/jira/browse/TINKERPOP-2737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia resolved TINKERPOP-2737. - Resolution: Implemented > Dockerized Build and Test Environments > -- > > Key: TINKERPOP-2737 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2737 > Project: TinkerPop > Issue Type: Improvement > Components: build-release, test-suite >Reporter: Lyndon Bauto >Priority: Major > > We have previously discussed having a dockerized build and test environment > in TinkerPop. This holds some advantages, such as making our build and test > system platform agnostic, allowing more modularity and plugability in our > build system, among other things. > The existing build and test environment works, but does require a fairly > extensive build and test environment. > There is currently some duplication of server config and scripts in the > gremlin-go codebase, this should also be removed when handling this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2831) Throw NoSuchElementException frequently which slowers the performance
[
https://issues.apache.org/jira/browse/TINKERPOP-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2831.
---
Resolution: Won't Do
As there is alternative solution, we will keep current stack trace
implementation.
> Throw NoSuchElementException frequently which slowers the performance
> -
>
> Key: TINKERPOP-2831
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2831
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.5.4
>Reporter: Redriver
>Priority: Major
> Attachments: Screen Shot 2022-11-24 at 11.35.40.png
>
>
> When I run g.V().label().groupCount() on a huge graph: 600m vertices + 6
> billion edges, the JVM async profiler exposed that the NoSuchElementException
> is a hotspot. In fact, that exception is used to inform the caller that the
> iteration end reached, so the stack trace information is not used. In
> addition, creating a new exception everytime is also not necessary.
> {code:java}
> java.lang.Throwable.fillInStackTrace(Native Method)
> java.lang.Throwable.fillInStackTrace(Throwable.java:783) => holding
> Monitor(java.util.NoSuchElementException@1860956919})
> java.lang.Throwable.(Throwable.java:250)
> java.lang.Exception.(Exception.java:54)
> java.lang.RuntimeException.(RuntimeException.java:51)
> java.util.NoSuchElementException.(NoSuchElementException.java:46)
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerGraphIterator.next(TinkerGraphIterator.java:63)
> org.janusgraph.hadoop.formats.util.JanusGraphVertexDeserializer.getOrCreateVertex(JanusGraphVertexDeserializer.java:192)
> org.janusgraph.hadoop.formats.util.JanusGraphVertexDeserializer.readHadoopVertex(JanusGraphVertexDeserializer.java:153)
> org.janusgraph.hadoop.formats.util.HadoopRecordReader.nextKeyValue(HadoopRecordReader.java:69)
> org.apache.spark.rdd.NewHadoopRDD$$anon$1.hasNext(NewHadoopRDD.scala:230)
> org.apache.spark.InterruptibleIterator.hasNext(InterruptibleIterator.scala:37)
> scala.collection.Iterator$$anon$11.hasNext(Iterator.scala:408)
> org.apache.spark.storage.memory.MemoryStore.putIterator(MemoryStore.scala:220)
> org.apache.spark.storage.memory.MemoryStore.putIteratorAsBytes(MemoryStore.scala:348)
> org.apache.spark.storage.BlockManager$$anonfun$doPutIterator$1.apply(BlockManager.scala:1182)
> org.apache.spark.storage.BlockManager$$anonfun$doPutIterator$1.apply(BlockManager.scala:1156)
> org.apache.spark.storage.BlockManager.doPut(BlockManager.scala:1091)
> org.apache.spark.storage.BlockManager.doPutIterator(BlockManager.scala:1156)
> org.apache.spark.storage.BlockManager.getOrElseUpdate(BlockManager.scala:882)
> org.apache.spark.rdd.RDD.getOrCompute(RDD.scala:335)
> org.apache.spark.rdd.RDD.iterator(RDD.scala:286)
> org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:52)
> org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:324)
> org.apache.spark.rdd.RDD.iterator(RDD.scala:288)
> org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:52)
> org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:324)
> org.apache.spark.rdd.RDD.iterator(RDD.scala:288)
> org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:52)
> org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:324)
> org.apache.spark.rdd.RDD.iterator(RDD.scala:288)
> org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:52)
> org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:324)
> org.apache.spark.rdd.RDD.iterator(RDD.scala:288)
> org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:99)
> org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:55)
> org.apache.spark.scheduler.Task.run(Task.scala:121)
> org.apache.spark.executor.Executor$TaskRunner$$anonfun$10.apply(Executor.scala:416)
> org.apache.spark.util.Utils$.tryWithSafeFinally(Utils.scala:1360)
> org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:422)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (TINKERPOP-2814) Add a SSL handshake timeout configuration to the driver
[ https://issues.apache.org/jira/browse/TINKERPOP-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia resolved TINKERPOP-2814. - Resolution: Implemented > Add a SSL handshake timeout configuration to the driver > --- > > Key: TINKERPOP-2814 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2814 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Affects Versions: 3.5.4 >Reporter: Stephen Mallette >Priority: Blocker > > The java driver currently relies on the default 10 second SSL handshake > timeout defined by Netty. Add a configuration to the driver to allow users to > change that setting. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2819) Refactor SimpleSocketServer to be accessible to all GLV's
[ https://issues.apache.org/jira/browse/TINKERPOP-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17646877#comment-17646877 ] Yang Xia commented on TINKERPOP-2819: - Currently pending integration tests from GLVs, will close this after those are done. > Refactor SimpleSocketServer to be accessible to all GLV's > - > > Key: TINKERPOP-2819 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2819 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Reporter: Cole Greer >Priority: Major > > Currently there is a large gap in the testing capabilities of the java driver > compared to the other GLV's. Part of this gap is the java driver has > SimpleSocketServer which provides a useful platform to write tests which > require specific response behaviour from the server. Having such a tool for > all of the GLV's would allow for testing of many more potential failure cases > as well as taking a step towards standardizing the testing approach for all > GLV's. > This work can be divided into 2 main parts. > Part One: Decoupling SimpleSocketServer from the java driver. This is the > most disruptive part of the proposed changes. This has already been discussed > [here|https://lists.apache.org/thread/vd7w43xjzvc5rr0135gql9mxhdlcltr9] on > the dev list but I will summarize. To avoid having all the GLV's depending on > the java driver, SimpleSocketServer and it's related classes should be > extracted to a new module gremlin-tools/gremlin-socket-server. Unfortunately > the socket server still relies on the following classes in gremlin driver: > tinkerpop.gremlin.driver.message.* > tinkerpop.gremlin.driver.ser.* > tinkerpop.gremlin.driver.MessageSerializer > tinkerpop.gremlin.driver.Tokens > To avoid a cyclic dependency between gremlin-driver and > gremlin-socket-server. these classes should be moved to another new module > gremlin-util which will house any classes which are to be shared between the > driver and server. Moving these classes to a new module and package will > break import lines and will need to be left until 3.7. > The full list of classes moved into gremlin-util is as follows: > > ||Old Name/Location||New Name/Location|| > |org.apache.tinkerpop.gremlin.driver.MessageSerializer|org.apache.tinkerpop.gremlin.util.MessageSerializer| > |org.apache.tinkerpop.gremlin.driver.Tokens|org.apache.tinkerpop.gremlin.util.Tokens| > |org.apache.tinkerpop.gremlin.driver.message.RequestMessage|org.apache.tinkerpop.gremlin.util.message.RequestMessage| > |org.apache.tinkerpop.gremlin.driver.message.ResponseMessage|org.apache.tinkerpop.gremlin.util.message.ResponseMessage| > |org.apache.tinkerpop.gremlin.driver.message.ResponseResult|org.apache.tinkerpop.gremlin.util.message.ResponseResult| > |org.apache.tinkerpop.gremlin.driver.message.ResponseStatus|org.apache.tinkerpop.gremlin.util.message.ResponseStatus| > |org.apache.tinkerpop.gremlin.driver.message.ResponseStatusCode|org.apache.tinkerpop.gremlin.util.message.ResponseStatusCode| > |org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV1d0|org.apache.tinkerpop.gremlin.util.ser.AbstractGraphSONMessageSerializerV1d0| > |org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV2d0|org.apache.tinkerpop.gremlin.util.ser.AbstractGraphSONMessageSerializerV2d0| > |org.apache.tinkerpop.gremlin.driver.ser.AbstractMessageSerializer|org.apache.tinkerpop.gremlin.util.ser.AbstractMessageSerializer| > |org.apache.tinkerpop.gremlin.driver.ser.GraphBinaryMessageSerializerV1|org.apache.tinkerpop.gremlin.util.ser.GraphBinaryMessageSerializerV1| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV1d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerGremlinV1d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV2d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerGremlinV2d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV1d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV1d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV2d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV2d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV3d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV3d0| > |org.apache.tinkerpop.gremlin.driver.ser.MessageTextSerializer|org.apache.tinkerpop.gremlin.util.ser.MessageTextSerializer| > |org.apache.tinkerpop.gremlin.driver.ser.NettyBuffer|org.apache.tinkerpop.gremlin.util.ser.NettyBuffer| > |org.apache.tinkerpop.gremlin.driver.ser.NettyBufferFactory|org.apache.tinkerpop.gremlin.util.ser.NettyBufferFactory| > |org.apache.tinkerpop.gremlin.driver.ser.RequestMessageGryoSerializer|org.apac
[jira] [Resolved] (TINKERPOP-2836) Github actions do not run java driver integration tests/
[ https://issues.apache.org/jira/browse/TINKERPOP-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia resolved TINKERPOP-2836. - Resolution: Fixed > Github actions do not run java driver integration tests/ > > > Key: TINKERPOP-2836 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2836 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.5.4 >Reporter: Cole Greer >Priority: Minor > > Currently the java driver integration tests are never run by the github > actions. Actions should be updated to run these tests. > > This [PR|https://github.com/apache/tinkerpop/pull/1890] demonstrates that the > integration tests are not being run currently. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TINKERPOP-2848) Deserialization of integer based datatypes lose the type definition
Yang Xia created TINKERPOP-2848: --- Summary: Deserialization of integer based datatypes lose the type definition Key: TINKERPOP-2848 URL: https://issues.apache.org/jira/browse/TINKERPOP-2848 Project: TinkerPop Issue Type: Improvement Reporter: Yang Xia As proposed by this PR [https://github.com/apache/tinkerpop/pull/1848,] currently in python, deserializing of integer based datatypes don't preserve the type definition from server. Some discussion may be needed around the impact of updating this deserialization. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2849) Incorrect implementation for GraphTraversalSource.With in gremlin-go
[ https://issues.apache.org/jira/browse/TINKERPOP-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia closed TINKERPOP-2849. --- Resolution: Fixed > Incorrect implementation for GraphTraversalSource.With in gremlin-go > > > Key: TINKERPOP-2849 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2849 > Project: TinkerPop > Issue Type: Bug > Components: go >Affects Versions: 3.6.1, 3.5.4 >Reporter: Valentyn Kahamlyk >Priority: Major > Labels: go-client > > Traversal configuration parameters passed to bytecode but not with > OptionsStrategy > https://github.com/apache/tinkerpop/blob/master/gremlin-go/driver/graphTraversalSource.go#L123 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TINKERPOP-2852) Update Maven plugin for docker-images building for M1 compatibility
Yang Xia created TINKERPOP-2852: --- Summary: Update Maven plugin for docker-images building for M1 compatibility Key: TINKERPOP-2852 URL: https://issues.apache.org/jira/browse/TINKERPOP-2852 Project: TinkerPop Issue Type: Improvement Reporter: Yang Xia The current Maven plug in we use for the `docker-image` building profile is no longer maintained ([https://github.com/spotify/dockerfile-maven)|https://github.com/spotify/dockerfile-maven).], and it is also not compatible with M1 Macs. We should consider swapping the plug in for an actively maintained one that is M1 compatible, for example [https://github.com/fabric8io/docker-maven-plugin/issues/1257.|https://github.com/fabric8io/docker-maven-plugin/issues/1257] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TINKERPOP-2849) Incorrect implementation for GraphTraversalSource.With in gremlin-go
[ https://issues.apache.org/jira/browse/TINKERPOP-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia resolved TINKERPOP-2849. - Fix Version/s: 3.7.0 3.6.2 3.5.5 Resolution: Fixed > Incorrect implementation for GraphTraversalSource.With in gremlin-go > > > Key: TINKERPOP-2849 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2849 > Project: TinkerPop > Issue Type: Bug > Components: go >Affects Versions: 3.6.1, 3.5.4 >Reporter: Valentyn Kahamlyk >Priority: Major > Fix For: 3.7.0, 3.6.2, 3.5.5 > > > Traversal configuration parameters passed to bytecode but not with > OptionsStrategy > https://github.com/apache/tinkerpop/blob/master/gremlin-go/driver/graphTraversalSource.go#L123 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2854) Generated Traversal differs from v3.4.13 to v3.6.1
[
https://issues.apache.org/jira/browse/TINKERPOP-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17675722#comment-17675722
]
Yang Xia commented on TINKERPOP-2854:
-
Hi Andrea, as there had been many semantic optimizations and updates from 3.4.x
to 3.6.x (see
[changelog|https://github.com/apache/tinkerpop/blob/3.6-dev/CHANGELOG.asciidoc]),
it is likely that the query transpiler needs updates, which we cannot help
given we don't maintain it.
Which cypher/gremlin transpiler are you using? It is perhaps useful to raise an
issue with them asking for TinkerPop 3.6.x support.
> Generated Traversal differs from v3.4.13 to v3.6.1
> --
>
> Key: TINKERPOP-2854
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2854
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Andrea Santurbano
>Priority: Major
>
> Hi everybody,
> I'm playing with Gremlin and OpenCypher query transpiler by using the
> following bytecode query:
> {code:java}
> [[], [inject( cypher.start), map([[], [project( GENERATED1, GENERATED2,
> GENERATED3), by([[], [constant(1)]]), by([[], [constant(2)]]), by([[],
> [constant(3)]]), select(values)]]), project(r), by([[], [project(
> GENERATED5, GENERATED6, GENERATED7), by([[], [identity()]]), by([[],
> [choose([[], [constant(binding[from=3])]], [[], [constant(binding[from=3])]],
> [[], [constant( cypher.null)]])]]), by([[], [choose([[],
> [constant(binding[to=1])]], [[], [constant(binding[to=1])]], [[], [constant(
> cypher.null)]])]]), select(values),
> map(lambda[cypherListSlice().apply(it)])]])]]{code}
> Using Gremlin 3.4.13 produces the following traversal:
>
>
> {code:java}
> [InjectStep([ cypher.start]), TraversalMapStep([ProjectStep([ GENERATED1,
> GENERATED2, GENERATED3],[[ConstantStep(1)], [ConstantStep(2)],
> [ConstantStep(3)]]), TraversalMapStep(values)]),
> ProjectStep([r],[[ProjectStep([ GENERATED5, GENERATED6,
> GENERATED7],[[IdentityStep], [ChooseStep([ConstantStep(3),
> HasNextStep],[[(eq(true)), [ConstantStep(3), EndStep]], [(eq(false)),
> [ConstantStep( cypher.null), EndStep]]])], [ChooseStep([ConstantStep(1),
> HasNextStep],[[(eq(true)), [ConstantStep(1), EndStep]], [(eq(false)),
> [ConstantStep( cypher.null), EndStep]]])]]), TraversalMapStep(values),
> LambdaMapStep(lambda)]])]{code}
> while 3.6.1 creates this one (we only upgraded the library and changed some
> package name references):
>
>
> {code:java}
> [InjectStep([ cypher.start]), TraversalMapStep([ProjectStep([ GENERATED1,
> GENERATED2, GENERATED3],[[ConstantStep(1)], [ConstantStep(2)],
> [ConstantStep(3)]]), TraversalMapStep(values)]),
> ProjectStep([r],[[ProjectStep([ GENERATED5, GENERATED6,
> GENERATED7],[[IdentityStep], [ChooseStep([ConstantStep(OUT),
> HasNextStep],[[(eq(true)), [ConstantStep(OUT), EndStep]], [(eq(false)),
> [ConstantStep( cypher.null), EndStep]]])], [ChooseStep([ConstantStep(IN),
> HasNextStep],[[(eq(true)), [ConstantStep(IN), EndStep]], [(eq(false)),
> [ConstantStep( cypher.null), EndStep]]])]]), TraversalMapStep(values),
> LambdaMapStep(lambda)]])]{code}
> Indeed the one in 3.6.1 is the wrong one because it adds some extra steps
> like {*}ConstantStep(IN){*}.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2849) Incorrect implementation for GraphTraversalSource.With in gremlin-go
[ https://issues.apache.org/jira/browse/TINKERPOP-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia closed TINKERPOP-2849. --- > Incorrect implementation for GraphTraversalSource.With in gremlin-go > > > Key: TINKERPOP-2849 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2849 > Project: TinkerPop > Issue Type: Bug > Components: go >Affects Versions: 3.6.1, 3.5.4 >Reporter: Valentyn Kahamlyk >Priority: Major > Fix For: 3.7.0, 3.6.2, 3.5.5 > > > Traversal configuration parameters passed to bytecode but not with > OptionsStrategy > https://github.com/apache/tinkerpop/blob/master/gremlin-go/driver/graphTraversalSource.go#L123 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2838) Add UserAgent GLV Tests
[ https://issues.apache.org/jira/browse/TINKERPOP-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia closed TINKERPOP-2838. --- > Add UserAgent GLV Tests > --- > > Key: TINKERPOP-2838 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2838 > Project: TinkerPop > Issue Type: Improvement > Components: driver, server >Affects Versions: 3.5.4 >Reporter: Cole Greer >Priority: Minor > Fix For: 3.7.0 > > > User agents were added to all GLV connection requests with > [TINKERPOP-2480|https://issues.apache.org/jira/browse/TINKERPOP-2480]. The > Java driver has tests added which utilize SimpleSocketServer to capture and > echo back the user agent. > [TINKERPOP-2819|https://issues.apache.org/jira/browse/TINKERPOP-2819] will > bring SimpleSocketServer to all GLV's. Once this is complete additional tests > mirroring the Java driver tests should be added to all GLV's to ensure the > user agent is being sent and received correctly, and that the > enableUserAgentOnConnect configuration is working correctly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2814) Add a SSL handshake timeout configuration to the driver
[ https://issues.apache.org/jira/browse/TINKERPOP-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2814: Fix Version/s: 3.7.0 3.6.2 3.5.5 > Add a SSL handshake timeout configuration to the driver > --- > > Key: TINKERPOP-2814 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2814 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Affects Versions: 3.5.4 >Reporter: Stephen Mallette >Priority: Blocker > Fix For: 3.7.0, 3.6.2, 3.5.5 > > > The java driver currently relies on the default 10 second SSL handshake > timeout defined by Netty. Add a configuration to the driver to allow users to > change that setting. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2814) Add a SSL handshake timeout configuration to the driver
[ https://issues.apache.org/jira/browse/TINKERPOP-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia closed TINKERPOP-2814. --- > Add a SSL handshake timeout configuration to the driver > --- > > Key: TINKERPOP-2814 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2814 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Affects Versions: 3.5.4 >Reporter: Stephen Mallette >Priority: Blocker > Fix For: 3.7.0, 3.6.2, 3.5.5 > > > The java driver currently relies on the default 10 second SSL handshake > timeout defined by Netty. Add a configuration to the driver to allow users to > change that setting. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2480) User agent for Gremlin drivers
[ https://issues.apache.org/jira/browse/TINKERPOP-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2480: Fix Version/s: 3.7.0 3.6.2 3.5.5 > User agent for Gremlin drivers > -- > > Key: TINKERPOP-2480 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2480 > Project: TinkerPop > Issue Type: Improvement > Components: driver, server >Affects Versions: 3.4.8 >Reporter: Divij Vaidya >Priority: Minor > Fix For: 3.7.0, 3.6.2, 3.5.5 > > > Currently, a server does not distinguish amongst the different types of > clients connecting to it. This issue is to add a new feature to add user > agent field in the HTTP and WebSocket request header which could be used to > identify the specific client from which the request was made. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2480) User agent for Gremlin drivers
[ https://issues.apache.org/jira/browse/TINKERPOP-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia closed TINKERPOP-2480. --- > User agent for Gremlin drivers > -- > > Key: TINKERPOP-2480 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2480 > Project: TinkerPop > Issue Type: Improvement > Components: driver, server >Affects Versions: 3.4.8 >Reporter: Divij Vaidya >Priority: Minor > Fix For: 3.7.0, 3.6.2, 3.5.5 > > > Currently, a server does not distinguish amongst the different types of > clients connecting to it. This issue is to add a new feature to add user > agent field in the HTTP and WebSocket request header which could be used to > identify the specific client from which the request was made. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2737) Dockerized Build and Test Environments
[ https://issues.apache.org/jira/browse/TINKERPOP-2737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2737: Fix Version/s: 3.7.0 3.6.2 3.5.5 > Dockerized Build and Test Environments > -- > > Key: TINKERPOP-2737 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2737 > Project: TinkerPop > Issue Type: Improvement > Components: build-release, test-suite >Reporter: Lyndon Bauto >Priority: Major > Fix For: 3.7.0, 3.6.2, 3.5.5 > > > We have previously discussed having a dockerized build and test environment > in TinkerPop. This holds some advantages, such as making our build and test > system platform agnostic, allowing more modularity and plugability in our > build system, among other things. > The existing build and test environment works, but does require a fairly > extensive build and test environment. > There is currently some duplication of server config and scripts in the > gremlin-go codebase, this should also be removed when handling this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2737) Dockerized Build and Test Environments
[ https://issues.apache.org/jira/browse/TINKERPOP-2737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia closed TINKERPOP-2737. --- > Dockerized Build and Test Environments > -- > > Key: TINKERPOP-2737 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2737 > Project: TinkerPop > Issue Type: Improvement > Components: build-release, test-suite >Reporter: Lyndon Bauto >Priority: Major > Fix For: 3.7.0, 3.6.2, 3.5.5 > > > We have previously discussed having a dockerized build and test environment > in TinkerPop. This holds some advantages, such as making our build and test > system platform agnostic, allowing more modularity and plugability in our > build system, among other things. > The existing build and test environment works, but does require a fairly > extensive build and test environment. > There is currently some duplication of server config and scripts in the > gremlin-go codebase, this should also be removed when handling this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2836) Github actions do not run java driver integration tests
[ https://issues.apache.org/jira/browse/TINKERPOP-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2836: Fix Version/s: 3.7.0 3.6.2 3.5.5 > Github actions do not run java driver integration tests > --- > > Key: TINKERPOP-2836 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2836 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.5.4 >Reporter: Cole Greer >Priority: Minor > Fix For: 3.7.0, 3.6.2, 3.5.5 > > > Currently the java driver integration tests are never run by the github > actions. Actions should be updated to run these tests. > > This [PR|https://github.com/apache/tinkerpop/pull/1890] demonstrates that the > integration tests are not being run currently. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2836) Github actions do not run java driver integration tests
[ https://issues.apache.org/jira/browse/TINKERPOP-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia closed TINKERPOP-2836. --- > Github actions do not run java driver integration tests > --- > > Key: TINKERPOP-2836 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2836 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.5.4 >Reporter: Cole Greer >Priority: Minor > Fix For: 3.7.0, 3.6.2, 3.5.5 > > > Currently the java driver integration tests are never run by the github > actions. Actions should be updated to run these tests. > > This [PR|https://github.com/apache/tinkerpop/pull/1890] demonstrates that the > integration tests are not being run currently. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2767) Repeat Out Times traversal hangs indefinitely on first execution
[
https://issues.apache.org/jira/browse/TINKERPOP-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2767.
---
Fix Version/s: 3.5.6
Resolution: Fixed
> Repeat Out Times traversal hangs indefinitely on first execution
>
>
> Key: TINKERPOP-2767
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2767
> Project: TinkerPop
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.3
> Environment: Windows 10
>Reporter: Simon Zhao
>Priority: Major
> Fix For: 3.5.6
>
>
> Originally encountered when fixing TINKERPOP-2754
>
> The following traversal in JS seems to cause hanging the first time you run
> it on a newly launched gremlin-server (3.5.3) via docker
>
> {{await g.V('1').repeat(_.out()).times(1500).next();}}
>
> The same hanging occurs in gremlin-go.
>
> {code:java}
> _, err = g.With("evaluationTimeout",
> 1000).V("1").Repeat(gremlingo.T__.Out()).Times(int32(1500)).Next() {code}
>
> The timeout is optional, but indicates that something is going wrong since it
> is not returning. Interestingly enough, if the timeout is very low, then it
> won't hang because it will say the timeout was exceeded. This indicates that
> if the traversal is completed within the timeout, it's just not returning for
> some reason on the first call.
>
> If you were to write a script and invoke this snippet of code, it will hang.
> If you forcefully terminate the script and rerun it, then it doesn't hang.
>
> main.go
> {code:java}
> package main
> import (
>gremlingo "github.com/apache/tinkerpop/gremlin-go/v3/driver"
>"log"
> )
> func main() {
>driver, err :=
> gremlingo.NewDriverRemoteConnection("ws://localhost:45940/gremlin")
>if err != nil {
> log.Print("Err creating DRC")
> return
>}
>defer driver.Close()
>log.Println("Start")
>g := gremlingo.Traversal_().WithRemote(driver)
>LABEL := "test"
>_, err = g.V().HasLabel(LABEL).Drop().Next()
>_, err = g.AddV(LABEL).Property(gremlingo.T.Id, "1").Next()
>_, err = g.AddV(LABEL).Property(gremlingo.T.Id, "2").Next()
>_, err =
> g.AddE(LABEL).From(gremlingo.T__.V("1")).To(gremlingo.T__.V("2")).Property(gremlingo.T.Id,
> "e1").Next()
>_, err =
> g.AddE(LABEL).From(gremlingo.T__.V("2")).To(gremlingo.T__.V("1")).Property(gremlingo.T.Id,
> "e2").Next()
>if err != nil {
> log.Println("Error during setup")
> return
>}
>log.Println("Start the problematic traversal")
>_, err = g.With("evaluationTimeout",
> 1000).V("1").Repeat(gremlingo.T__.Out()).Times(int32(1500)).Next()
>if err != nil {
> log.Println("Error with the problematic traversal, but we didn't hang")
> return
>}
>log.Println("End")
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2861) Fix incorrect symlinks in source release zip
[ https://issues.apache.org/jira/browse/TINKERPOP-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691849#comment-17691849 ] Yang Xia commented on TINKERPOP-2861: - As this issue is a result of symlink creation on macOS for the last release, we are resolving this by restricting the release process to Linux environment only for the future. > Fix incorrect symlinks in source release zip > > > Key: TINKERPOP-2861 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2861 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.5.5 >Reporter: Divij Vaidya >Priority: Blocker > > The zip for the source code which is released contains a incorrect symlink > which would cause problems for folks who download the source code zip and try > to run gremlin.sh. > We need to fix this. > More context: > [https://lists.apache.org/thread/0f0pcmn1f6k8k324t470t4mp0o64mzdq] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2861) Fix incorrect symlinks in source release zip
[ https://issues.apache.org/jira/browse/TINKERPOP-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia closed TINKERPOP-2861. --- Fix Version/s: 3.5.6 Resolution: Resolved > Fix incorrect symlinks in source release zip > > > Key: TINKERPOP-2861 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2861 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.5.5 >Reporter: Divij Vaidya >Priority: Blocker > Fix For: 3.5.6 > > > The zip for the source code which is released contains a incorrect symlink > which would cause problems for folks who download the source code zip and try > to run gremlin.sh. > We need to fix this. > More context: > [https://lists.apache.org/thread/0f0pcmn1f6k8k324t470t4mp0o64mzdq] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (TINKERPOP-2767) Repeat Out Times traversal hangs indefinitely on first execution
[
https://issues.apache.org/jira/browse/TINKERPOP-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia reopened TINKERPOP-2767:
-
We need to address changes needed in 3.6-dev for this issue.
> Repeat Out Times traversal hangs indefinitely on first execution
>
>
> Key: TINKERPOP-2767
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2767
> Project: TinkerPop
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.3
> Environment: Windows 10
>Reporter: Simon Zhao
>Priority: Major
> Fix For: 3.5.6
>
>
> Originally encountered when fixing TINKERPOP-2754
>
> The following traversal in JS seems to cause hanging the first time you run
> it on a newly launched gremlin-server (3.5.3) via docker
>
> {{await g.V('1').repeat(_.out()).times(1500).next();}}
>
> The same hanging occurs in gremlin-go.
>
> {code:java}
> _, err = g.With("evaluationTimeout",
> 1000).V("1").Repeat(gremlingo.T__.Out()).Times(int32(1500)).Next() {code}
>
> The timeout is optional, but indicates that something is going wrong since it
> is not returning. Interestingly enough, if the timeout is very low, then it
> won't hang because it will say the timeout was exceeded. This indicates that
> if the traversal is completed within the timeout, it's just not returning for
> some reason on the first call.
>
> If you were to write a script and invoke this snippet of code, it will hang.
> If you forcefully terminate the script and rerun it, then it doesn't hang.
>
> main.go
> {code:java}
> package main
> import (
>gremlingo "github.com/apache/tinkerpop/gremlin-go/v3/driver"
>"log"
> )
> func main() {
>driver, err :=
> gremlingo.NewDriverRemoteConnection("ws://localhost:45940/gremlin")
>if err != nil {
> log.Print("Err creating DRC")
> return
>}
>defer driver.Close()
>log.Println("Start")
>g := gremlingo.Traversal_().WithRemote(driver)
>LABEL := "test"
>_, err = g.V().HasLabel(LABEL).Drop().Next()
>_, err = g.AddV(LABEL).Property(gremlingo.T.Id, "1").Next()
>_, err = g.AddV(LABEL).Property(gremlingo.T.Id, "2").Next()
>_, err =
> g.AddE(LABEL).From(gremlingo.T__.V("1")).To(gremlingo.T__.V("2")).Property(gremlingo.T.Id,
> "e1").Next()
>_, err =
> g.AddE(LABEL).From(gremlingo.T__.V("2")).To(gremlingo.T__.V("1")).Property(gremlingo.T.Id,
> "e2").Next()
>if err != nil {
> log.Println("Error during setup")
> return
>}
>log.Println("Start the problematic traversal")
>_, err = g.With("evaluationTimeout",
> 1000).V("1").Repeat(gremlingo.T__.Out()).Times(int32(1500)).Next()
>if err != nil {
> log.Println("Error with the problematic traversal, but we didn't hang")
> return
>}
>log.Println("End")
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (TINKERPOP-2861) Fix incorrect symlinks in source release zip
[ https://issues.apache.org/jira/browse/TINKERPOP-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia reopened TINKERPOP-2861: - > Fix incorrect symlinks in source release zip > > > Key: TINKERPOP-2861 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2861 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.5.5 >Reporter: Divij Vaidya >Priority: Blocker > Fix For: 3.5.6 > > > The zip for the source code which is released contains a incorrect symlink > which would cause problems for folks who download the source code zip and try > to run gremlin.sh. > We need to fix this. > More context: > [https://lists.apache.org/thread/0f0pcmn1f6k8k324t470t4mp0o64mzdq] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2861) Fix incorrect symlinks in source release zip
[ https://issues.apache.org/jira/browse/TINKERPOP-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia closed TINKERPOP-2861. --- > Fix incorrect symlinks in source release zip > > > Key: TINKERPOP-2861 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2861 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.5.5 >Reporter: Divij Vaidya >Priority: Blocker > Fix For: 3.6.3, 3.5.6 > > > The zip for the source code which is released contains a incorrect symlink > which would cause problems for folks who download the source code zip and try > to run gremlin.sh. > We need to fix this. > More context: > [https://lists.apache.org/thread/0f0pcmn1f6k8k324t470t4mp0o64mzdq] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TINKERPOP-2861) Fix incorrect symlinks in source release zip
[ https://issues.apache.org/jira/browse/TINKERPOP-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia resolved TINKERPOP-2861. - Fix Version/s: 3.6.3 Resolution: Resolved > Fix incorrect symlinks in source release zip > > > Key: TINKERPOP-2861 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2861 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.5.5 >Reporter: Divij Vaidya >Priority: Blocker > Fix For: 3.6.3, 3.5.6 > > > The zip for the source code which is released contains a incorrect symlink > which would cause problems for folks who download the source code zip and try > to run gremlin.sh. > We need to fix this. > More context: > [https://lists.apache.org/thread/0f0pcmn1f6k8k324t470t4mp0o64mzdq] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2767) Repeat Out Times traversal hangs indefinitely on first execution
[
https://issues.apache.org/jira/browse/TINKERPOP-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2767.
---
Fix Version/s: 3.6.3
Resolution: Fixed
> Repeat Out Times traversal hangs indefinitely on first execution
>
>
> Key: TINKERPOP-2767
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2767
> Project: TinkerPop
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.3
> Environment: Windows 10
>Reporter: Simon Zhao
>Priority: Major
> Fix For: 3.6.3, 3.5.6
>
>
> Originally encountered when fixing TINKERPOP-2754
>
> The following traversal in JS seems to cause hanging the first time you run
> it on a newly launched gremlin-server (3.5.3) via docker
>
> {{await g.V('1').repeat(_.out()).times(1500).next();}}
>
> The same hanging occurs in gremlin-go.
>
> {code:java}
> _, err = g.With("evaluationTimeout",
> 1000).V("1").Repeat(gremlingo.T__.Out()).Times(int32(1500)).Next() {code}
>
> The timeout is optional, but indicates that something is going wrong since it
> is not returning. Interestingly enough, if the timeout is very low, then it
> won't hang because it will say the timeout was exceeded. This indicates that
> if the traversal is completed within the timeout, it's just not returning for
> some reason on the first call.
>
> If you were to write a script and invoke this snippet of code, it will hang.
> If you forcefully terminate the script and rerun it, then it doesn't hang.
>
> main.go
> {code:java}
> package main
> import (
>gremlingo "github.com/apache/tinkerpop/gremlin-go/v3/driver"
>"log"
> )
> func main() {
>driver, err :=
> gremlingo.NewDriverRemoteConnection("ws://localhost:45940/gremlin")
>if err != nil {
> log.Print("Err creating DRC")
> return
>}
>defer driver.Close()
>log.Println("Start")
>g := gremlingo.Traversal_().WithRemote(driver)
>LABEL := "test"
>_, err = g.V().HasLabel(LABEL).Drop().Next()
>_, err = g.AddV(LABEL).Property(gremlingo.T.Id, "1").Next()
>_, err = g.AddV(LABEL).Property(gremlingo.T.Id, "2").Next()
>_, err =
> g.AddE(LABEL).From(gremlingo.T__.V("1")).To(gremlingo.T__.V("2")).Property(gremlingo.T.Id,
> "e1").Next()
>_, err =
> g.AddE(LABEL).From(gremlingo.T__.V("2")).To(gremlingo.T__.V("1")).Property(gremlingo.T.Id,
> "e2").Next()
>if err != nil {
> log.Println("Error during setup")
> return
>}
>log.Println("Start the problematic traversal")
>_, err = g.With("evaluationTimeout",
> 1000).V("1").Repeat(gremlingo.T__.Out()).Times(int32(1500)).Next()
>if err != nil {
> log.Println("Error with the problematic traversal, but we didn't hang")
> return
>}
>log.Println("End")
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2905) gremlin-go gorillaTransporter.logHandler is not initialized correctly and leads to panic
[
https://issues.apache.org/jira/browse/TINKERPOP-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2905.
---
Fix Version/s: 3.7.0
3.6.3
3.5.6
Resolution: Fixed
> gremlin-go gorillaTransporter.logHandler is not initialized correctly and
> leads to panic
>
>
> Key: TINKERPOP-2905
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2905
> Project: TinkerPop
> Issue Type: Bug
> Components: go
>Affects Versions: 3.5.0
>Reporter: Kemal Hadimli
>Priority: Major
> Labels: go
> Fix For: 3.7.0, 3.6.3, 3.5.6
>
>
> Whenever the gorillaTransporter needs to write a log message we get a nil
> dereference error:
> {code:java}
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0
> pc=0x710432]goroutine 22 [running]:
> github.com/nicksnyder/go-i18n/v2/i18n.(*Localizer).getMessageTemplate(0x0,
> {0xc4a40c, 0x17}, 0x0)
> /Users/disq/go/pkg/mod/github.com/nicksnyder/go-i18n/v2@v2.2.1/i18n/localizer.go:182
> +0x32
> github.com/nicksnyder/go-i18n/v2/i18n.(*Localizer).LocalizeWithTag(0xb?,
> 0xc92e68)
> /Users/disq/go/pkg/mod/github.com/nicksnyder/go-i18n/v2@v2.2.1/i18n/localizer.go:158
> +0x29b github.com/nicksnyder/go-i18n/v2/i18n.(*Localizer).Localize(...)
>
> /Users/disq/go/pkg/mod/github.com/nicksnyder/go-i18n/v2@v2.2.1/i18n/localizer.go:113
>
> github.com/apache/tinkerpop/gremlin-go/v3/driver.(*logHandler).logf(0xc000241d68,
> 0x4, {0xc4a40c?, 0x0?}, {0xc003d3b520, 0x2, 0x2})
> /Users/disq/Downloads/tinkerpop/gremlin-go/driver/logger.go:93 +0x8d
> github.com/apache/tinkerpop/gremlin-go/v3/driver.(*gorillaTransporter).writeLoop(0xc000241d40)
>
> /Users/disq/Downloads/tinkerpop/gremlin-go/driver/gorillaTransporter.go:189
> +0x508 created by
> github.com/apache/tinkerpop/gremlin-go/v3/driver.(*gorillaTransporter).Connect
>
> /Users/disq/Downloads/tinkerpop/gremlin-go/driver/gorillaTransporter.go:90
> +0x332
> {code}
> Since {{logHandler}} is not initialized with the constructor (zero value is
> used instead) {{logVerbosity}} is not passed on and {{localizer}} is also
> {{{}nil{}}}. This leads to a nil dereference error when the localizer is used
> in the logger. Turning logging off (setting {{logVerbosity}} to {{{}Off{}}})
> also doesn't work because the verbosity value is also affected and not passed
> on.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2912) Improve error message for addE() when traverser is incorrect
[
https://issues.apache.org/jira/browse/TINKERPOP-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2912:
Priority: Critical (was: Minor)
> Improve error message for addE() when traverser is incorrect
>
>
> Key: TINKERPOP-2912
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2912
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.5.5
>Reporter: Stephen Mallette
>Priority: Critical
>
> For this:
> {code}
> gremlin> g.addV('A').as('a').addE('self').addE('self2').to('a')
> addE(self2) could not find a Vertex for from() - encountered: TinkerEdge
> Type ':help' or ':h' for help.
> Display stack trace? [yN]n
> {code}
> The traverser for the second {{addE('self2')}} is not a {{Vertex}}` - it is
> the previously added {{Edge}} of {{addE('self')}}. Since `from()` is not
> provided for the second {{addE('self2')}} it uses the current traverser and
> we get the exception shown. The exception is a bit confusing for those who
> don't realize what it means. Change the exception to: "addE(self2) could not
> find a Vertex specified for from() - a TinkerEdge was specified instead" - or
> perhaps a better message?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2909) Throw ClassCastException
[
https://issues.apache.org/jira/browse/TINKERPOP-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2909.
---
Resolution: Not A Bug
> Throw ClassCastException
>
>
> Key: TINKERPOP-2909
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2909
> Project: TinkerPop
> Issue Type: Bug
> Components: driver, server
>Affects Versions: 3.6.2
> Environment: - TinkerGraph Version: 3.6.2
> - Operating system: macOS 13.2.1
> - API/Driver: Java
>Reporter: Zeyang Zhuang
>Priority: Major
>
> I first randomly create a graph. Then when I run the following query:
> `g.V().in('el1').as('x').V().both('el0','el1').inE('el1').outV().where(within('x'))`
> is thrown with an exception. I think this query is syntactically correct,
> but I keep triggering this kind of problem. I generate the query based on the
> rule which can be refered from:
> [https://stackoverflow.com/questions/48067834/gremlin-intersection-operation].
> Following this instruction, I think it's allowed to generate this kind of
> queries.
> *Expected behavior:*
> No exception should be expected to throw. Or futher messages or prompts
> should be thrown.
> *Actual behavior:*
> A `java.util.concurrent.ExecutionException` is thrown. And I'm not really
> sure whether this problem should happen so I report this.
> ```
> java.util.concurrent.ExecutionException:
> org.apache.tinkerpop.gremlin.driver.exception.ResponseException:
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerVertex cannot be
> cast to java.util.Collection
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2908) Throw ExecutionException for property
[
https://issues.apache.org/jira/browse/TINKERPOP-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2908.
---
Resolution: Not A Bug
> Throw ExecutionException for property
> -
>
> Key: TINKERPOP-2908
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2908
> Project: TinkerPop
> Issue Type: Bug
> Components: driver, server
>Affects Versions: 3.6.2
> Environment: - TinkerGraph Version: 3.6.2
> - Operating system: macOS 13.2.1
> - API/Driver: Java
>Reporter: Zeyang Zhuang
>Priority: Major
>
> I first randomly create a graph. Then when I run the following query:
> `g.E().and(__.values('ep3')).where(values('ep1').max().is(lt('}b?\u').or(not(between('윥,aIe','J켛'NL')).and(not(lt('u}s,p'.or(outside('UE8IX','0.2398615058061513'`
> is thrown with an exception. I think this query is syntactically correct,
> but I keep triggering this kind of problem.
> *Expected behavior:*
> No exception should be expected to throw. Or futher messages or prompts
> should be thrown.
> *Actual behavior:*
> A `java.util.concurrent.ExecutionException` is thrown. And I'm not really
> sure whether this problem should happen so I report this.
> ```
> TinkerGraph exception :
> java.util.concurrent.ExecutionException:
> org.apache.tinkerpop.gremlin.driver.exception.ResponseException: startup
> failed:
> General error during parsing: Did not find four digit hex character code.
> line: 1 col:65
> groovyjarjarantlr.TokenStreamIOException: Did not find four digit hex
> character code. line: 1 col:65
> at
> org.codehaus.groovy.antlr.parser.GroovyLexer.nextToken(GroovyLexer.java:733)
> at
> org.codehaus.groovy.antlr.parser.GroovyLexer$1.nextToken(GroovyLexer.java:262)
> at groovyjarjarantlr.TokenBuffer.fill(TokenBuffer.java:69)
> at groovyjarjarantlr.TokenBuffer.LA(TokenBuffer.java:80)
> at groovyjarjarantlr.LLkParser.LA(LLkParser.java:52)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.pathExpression(GroovyRecognizer.java:11797)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.postfixExpression(GroovyRecognizer.java:13527)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.unaryExpressionNotPlusMinus(GroovyRecognizer.java:13496)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.powerExpressionNotPlusMinus(GroovyRecognizer.java:13200)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.multiplicativeExpression(GroovyRecognizer.java:13132)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.additiveExpression(GroovyRecognizer.java:12802)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.shiftExpression(GroovyRecognizer.java:10066)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.relationalExpression(GroovyRecognizer.java:12707)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.equalityExpression(GroovyRecognizer.java:12631)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.regexExpression(GroovyRecognizer.java:12579)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.andExpression(GroovyRecognizer.java:12547)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.exclusiveOrExpression(GroovyRecognizer.java:12515)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.inclusiveOrExpression(GroovyRecognizer.java:12483)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.logicalAndExpression(GroovyRecognizer.java:12451)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.logicalOrExpression(GroovyRecognizer.java:12419)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.conditionalExpression(GroovyRecognizer.java:4947)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.assignmentExpression(GroovyRecognizer.java:8216)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.expression(GroovyRecognizer.java:10206)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.strictContextExpression(GroovyRecognizer.java:9481)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.argument(GroovyRecognizer.java:14123)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.argList(GroovyRecognizer.java:6714)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.methodCallArgs(GroovyRecognizer.java:12105)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.pathElement(GroovyRecognizer.java:11684)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.pathExpression(GroovyRecognizer.java:11814)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.postfixExpression(GroovyRecognizer.java:13527)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.unaryExpressionNotPlusMinus(GroovyRecognizer.java:13496)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.powerExpressionNotPlusMinus(GroovyRecognizer.java:13200)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.mul
[jira] [Commented] (TINKERPOP-2909) Throw ClassCastException
[
https://issues.apache.org/jira/browse/TINKERPOP-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704767#comment-17704767
]
Yang Xia commented on TINKERPOP-2909:
-
Closing this issue for now, as Stephen has provided a resolution. Please feel
free to re-open if needed.
> Throw ClassCastException
>
>
> Key: TINKERPOP-2909
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2909
> Project: TinkerPop
> Issue Type: Bug
> Components: driver, server
>Affects Versions: 3.6.2
> Environment: - TinkerGraph Version: 3.6.2
> - Operating system: macOS 13.2.1
> - API/Driver: Java
>Reporter: Zeyang Zhuang
>Priority: Major
>
> I first randomly create a graph. Then when I run the following query:
> `g.V().in('el1').as('x').V().both('el0','el1').inE('el1').outV().where(within('x'))`
> is thrown with an exception. I think this query is syntactically correct,
> but I keep triggering this kind of problem. I generate the query based on the
> rule which can be refered from:
> [https://stackoverflow.com/questions/48067834/gremlin-intersection-operation].
> Following this instruction, I think it's allowed to generate this kind of
> queries.
> *Expected behavior:*
> No exception should be expected to throw. Or futher messages or prompts
> should be thrown.
> *Actual behavior:*
> A `java.util.concurrent.ExecutionException` is thrown. And I'm not really
> sure whether this problem should happen so I report this.
> ```
> java.util.concurrent.ExecutionException:
> org.apache.tinkerpop.gremlin.driver.exception.ResponseException:
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerVertex cannot be
> cast to java.util.Collection
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2908) Throw ExecutionException for property
[
https://issues.apache.org/jira/browse/TINKERPOP-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704768#comment-17704768
]
Yang Xia commented on TINKERPOP-2908:
-
Closing based on comment above.
> Throw ExecutionException for property
> -
>
> Key: TINKERPOP-2908
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2908
> Project: TinkerPop
> Issue Type: Bug
> Components: driver, server
>Affects Versions: 3.6.2
> Environment: - TinkerGraph Version: 3.6.2
> - Operating system: macOS 13.2.1
> - API/Driver: Java
>Reporter: Zeyang Zhuang
>Priority: Major
>
> I first randomly create a graph. Then when I run the following query:
> `g.E().and(__.values('ep3')).where(values('ep1').max().is(lt('}b?\u').or(not(between('윥,aIe','J켛'NL')).and(not(lt('u}s,p'.or(outside('UE8IX','0.2398615058061513'`
> is thrown with an exception. I think this query is syntactically correct,
> but I keep triggering this kind of problem.
> *Expected behavior:*
> No exception should be expected to throw. Or futher messages or prompts
> should be thrown.
> *Actual behavior:*
> A `java.util.concurrent.ExecutionException` is thrown. And I'm not really
> sure whether this problem should happen so I report this.
> ```
> TinkerGraph exception :
> java.util.concurrent.ExecutionException:
> org.apache.tinkerpop.gremlin.driver.exception.ResponseException: startup
> failed:
> General error during parsing: Did not find four digit hex character code.
> line: 1 col:65
> groovyjarjarantlr.TokenStreamIOException: Did not find four digit hex
> character code. line: 1 col:65
> at
> org.codehaus.groovy.antlr.parser.GroovyLexer.nextToken(GroovyLexer.java:733)
> at
> org.codehaus.groovy.antlr.parser.GroovyLexer$1.nextToken(GroovyLexer.java:262)
> at groovyjarjarantlr.TokenBuffer.fill(TokenBuffer.java:69)
> at groovyjarjarantlr.TokenBuffer.LA(TokenBuffer.java:80)
> at groovyjarjarantlr.LLkParser.LA(LLkParser.java:52)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.pathExpression(GroovyRecognizer.java:11797)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.postfixExpression(GroovyRecognizer.java:13527)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.unaryExpressionNotPlusMinus(GroovyRecognizer.java:13496)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.powerExpressionNotPlusMinus(GroovyRecognizer.java:13200)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.multiplicativeExpression(GroovyRecognizer.java:13132)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.additiveExpression(GroovyRecognizer.java:12802)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.shiftExpression(GroovyRecognizer.java:10066)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.relationalExpression(GroovyRecognizer.java:12707)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.equalityExpression(GroovyRecognizer.java:12631)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.regexExpression(GroovyRecognizer.java:12579)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.andExpression(GroovyRecognizer.java:12547)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.exclusiveOrExpression(GroovyRecognizer.java:12515)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.inclusiveOrExpression(GroovyRecognizer.java:12483)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.logicalAndExpression(GroovyRecognizer.java:12451)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.logicalOrExpression(GroovyRecognizer.java:12419)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.conditionalExpression(GroovyRecognizer.java:4947)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.assignmentExpression(GroovyRecognizer.java:8216)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.expression(GroovyRecognizer.java:10206)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.strictContextExpression(GroovyRecognizer.java:9481)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.argument(GroovyRecognizer.java:14123)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.argList(GroovyRecognizer.java:6714)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.methodCallArgs(GroovyRecognizer.java:12105)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.pathElement(GroovyRecognizer.java:11684)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.pathExpression(GroovyRecognizer.java:11814)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.postfixExpression(GroovyRecognizer.java:13527)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.unaryExpressionNotPlusMinus(GroovyRecognizer.java:13496)
> at
> org.codehaus.groovy.antlr.parser.GroovyRecognizer.powerExpressionNotPlusMinus(GroovyRecognizer.java:1
[jira] [Commented] (TINKERPOP-2907) Throw ExecutionException for property
[
https://issues.apache.org/jira/browse/TINKERPOP-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704769#comment-17704769
]
Yang Xia commented on TINKERPOP-2907:
-
Closing this issue for now, as Stephen has provided a resolution. Please feel
free to re-open if needed.
> Throw ExecutionException for property
> -
>
> Key: TINKERPOP-2907
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2907
> Project: TinkerPop
> Issue Type: Bug
> Components: driver, server
>Affects Versions: 3.6.2
> Environment: - TinkerGraph Version: 3.6.2
> - Operating system: macOS 13.2.1
> - API/Driver: Java
>Reporter: Zeyang Zhuang
>Priority: Major
>
> I first randomly create a graph. Then when I run the following query:
> `g.V().has('vp4',
> between(0.10558513485092047,0.27458978042693427).and(between(0.4688484640878603,Infinity))).and(__.order().by(desc)).hasNot('vp1')`
> is thrown with an exception. I think this query is syntactically correct,
> but I keep triggering this kind of problem. Can TinkerGraph supports Infinity
> comparison?
> *Expected behavior:*
> No exception should be expected to throw. Or futher messages or prompts
> should be thrown.
> *Actual behavior:*
> A `java.util.concurrent.ExecutionException` is thrown. And I'm not really
> sure whether this problem should happen so I report this. I think it should
> support the Infinity rules.
> ```
> TinkerGraph exception :
> java.util.concurrent.ExecutionException:
> org.apache.tinkerpop.gremlin.driver.exception.ResponseException: No such
> property: Infinity for class: Script126
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2907) Throw ExecutionException for property
[
https://issues.apache.org/jira/browse/TINKERPOP-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2907.
---
Resolution: Not A Bug
> Throw ExecutionException for property
> -
>
> Key: TINKERPOP-2907
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2907
> Project: TinkerPop
> Issue Type: Bug
> Components: driver, server
>Affects Versions: 3.6.2
> Environment: - TinkerGraph Version: 3.6.2
> - Operating system: macOS 13.2.1
> - API/Driver: Java
>Reporter: Zeyang Zhuang
>Priority: Major
>
> I first randomly create a graph. Then when I run the following query:
> `g.V().has('vp4',
> between(0.10558513485092047,0.27458978042693427).and(between(0.4688484640878603,Infinity))).and(__.order().by(desc)).hasNot('vp1')`
> is thrown with an exception. I think this query is syntactically correct,
> but I keep triggering this kind of problem. Can TinkerGraph supports Infinity
> comparison?
> *Expected behavior:*
> No exception should be expected to throw. Or futher messages or prompts
> should be thrown.
> *Actual behavior:*
> A `java.util.concurrent.ExecutionException` is thrown. And I'm not really
> sure whether this problem should happen so I report this. I think it should
> support the Infinity rules.
> ```
> TinkerGraph exception :
> java.util.concurrent.ExecutionException:
> org.apache.tinkerpop.gremlin.driver.exception.ResponseException: No such
> property: Infinity for class: Script126
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2906) Query using coalesce adding the same vertex twice
[
https://issues.apache.org/jira/browse/TINKERPOP-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2906:
Priority: Critical (was: Major)
> Query using coalesce adding the same vertex twice
> -
>
> Key: TINKERPOP-2906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2906
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.0, 3.6.2
>Reporter: Kelvin Lawrence
>Priority: Critical
>
> While looking into a question on Stack Overflow about selectively adding a
> vertex based on a set of values in a list, I think I may have run into an odd
> issue. Note that this can also be solved using mergeV, but that
> notwithstanding, the behavior below seems odd. It can be reproduced just
> using TinkerGraph and the Gremlin Console. Everything works as expected until
> the RHS of the coalesce() step is an addV() step.
>
> {code:java}
> gremlin> g.addV('Person').property('name','Sam')
> ==>v[16]gremlin> g
> ==>graphtraversalsource[tinkergraph[vertices:1 edges:0], standard]gremlin>
> g.inject(['Sam','Peter','Frank']).
> ..1> unfold().as('find').
> ..2> V().as('p').
> ..3> coalesce(
> ..4> where(eq('p')).
> ..5> by(select('find')).
> ..6> by('name'),constant(1))
> ==>v[16]
> ==>1
> ==>1gremlin> g.inject(['Sam','Peter','Frank']).
> ..1> unfold().as('find').
> ..2> V().as('p').
> ..3> coalesce(
> ..4> where(eq('p')).
> ..5> by(select('find')).
> ..6> by('name'),select('find'))
> ==>v[16]
> ==>Peter
> ==>Frankgremlin> g.inject(['Sam','Peter','Frank']).
> ..1> unfold().as('find').
> ..2> V().as('p').
> ..3> coalesce(
> ..4> where(eq('p')).
> ..5> by(select('find')).
> ..6> by('name'),addV('Person').property('name',select('find'))
> ..7> )
> ==>v[16]
> ==>v[18]
> ==>v[20]
> ==>v[22]gremlin> g.V().valueMap(true)
> ==>[id:16,label:Person,name:[Sam]]
> ==>[id:18,label:Person,name:[Peter]]
> ==>[id:20,label:Person,name:[Frank]]
> ==>[id:22,label:Person,name:[Frank]]
>
> gremlin> g.V().drop()gremlin> g.addV('Person').property('name','Sam')
> ==>v[24]gremlin> g.inject(['Sam','Peter','Frank']).
> ..1> unfold().as('find').
> ..2> V().as('p').
> ..3> coalesce(
> ..4> where(eq('p')).
> ..5> by(select('find')).
> ..6> by('name'),
> ..7> addV('Person').property('name',select('find'))).profile()
> ==>Traversal Metrics
> Step Count Traversers Time (ms) % Dur
> =
> InjectStep([[Sam, Peter, Frank]]) 1 1 0.043 4.19
> UnfoldStep@[find] 3 3 0.083 8.00
> TinkerGraphStep(vertex,[])@[p] 4 4 0.155 14.91
> CoalesceStep([[WherePredicateStep(null,eq(p),[[... 4 4 0.761 72.89
> WherePredicateStep(null,eq(p),[[SelectOneStep... 1 1 0.181
> SelectOneStep(last,find,null) 4 4 0.057
> AddVertexStep({name=[[SelectOneStep(last,find... 3 3 0.246
> SelectOneStep(last,find,null) 3 3 0.025
> >TOTAL - - 1.044 -
> gremlin> g.inject(['Sam','Peter','Frank']).
> ..1> unfold().as('find').V().profile()
> ==>Traversal Metrics
> Step Count Traversers Time (ms) % Dur
> =
> InjectStep([[Sam, Peter, Frank]]) 1 1 0.028 8.93
> UnfoldStep@[find] 3 3 0.043 13.97
> TinkerGraphStep(vertex,[]) 3 3 0.241 77.10
> >TOTAL - - 0.313 -
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2904) Forget to throw GremlinTypeErrorException when using is(predicate) to compare NaN
[
https://issues.apache.org/jira/browse/TINKERPOP-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2904:
Priority: Critical (was: Major)
> Forget to throw GremlinTypeErrorException when using is(predicate) to compare
> NaN
> --
>
> Key: TINKERPOP-2904
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2904
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Miracy Cavendish
>Priority: Critical
>
> By the design of Gremlin, an exception should be thrown when compared with
> NaN.
> However, I found that when using ```is(predicate)``` to compare, the
> exception is always swallowed, and this issue occurs on all GDBs support
> Gremlin, such as "g.inject(Double.NaN).is(gt(3))"
> {code:java}
> public static final GremlinValueComparator COMPARABILITY = new
> GremlinValueComparator() {
> /**
> * Compare two Gremlin value objects per the Comparability semantics.
> Throws type errors for NaN comparison
> * and for cross-type comparison (including nulltype).
> *
> * Use this method for P.lt/lte/gt/gte.
> */
> @Override
> public int compare(final Object f, final Object s) {
> // For Compare, NaN always produces ERROR
> if (eitherAreNaN(f, s))
> throwTypeError();
> // For Compare we do not cross type boundaries, including null
> if (!comparable(f, s))
> throwTypeError();
> // comparable(f, s) assures that type(f) == type(s)
> final Type type = Type.type(f);
> return comparator(type).compare(f, s);
> }
> ... {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2902) Critical security vulnerability in snakeyaml
[ https://issues.apache.org/jira/browse/TINKERPOP-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2902: Priority: Critical (was: Major) > Critical security vulnerability in snakeyaml > > > Key: TINKERPOP-2902 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2902 > Project: TinkerPop > Issue Type: Bug > Components: console, server >Affects Versions: 3.6.2, 3.5.5 >Reporter: Aaron Coady >Priority: Critical > > This critical security vulnerability was identified in versions of snakeyaml > prior to 2.0 > [https://nvd.nist.gov/vuln/detail/CVE-2022-1471] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2901) Incorrect result caused by has(key, predicate)
[
https://issues.apache.org/jira/browse/TINKERPOP-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2901:
Priority: Critical (was: Major)
> Incorrect result caused by has(key, predicate)
> --
>
> Key: TINKERPOP-2901
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2901
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Miracy Cavendish
>Priority: Critical
>
> Hi! I execute the following gremlin statements:
>
> {code:java}
> (1) g.V().where(__.values("PersonalId").is(within(4,8,7,10,9,3))).count()
> => 6
> (2)
> g.V().where(__.values("PersonalId").is(within(4,8,7,10,9,3))).has("prop4",
> gt(1)).count()
> => 0
> (3)
> g.V().where(__.values("PersonalId").is(within(4,8,7,10,9,3))).not(__.has("prop4",
> gt(1))).count()
> => 4
> # Query Partition => (1) should equals (2) + (3)
> (4)
> g.V().where(__.values("PersonalId").is(within(4,8,7,10,9,3))).values("prop4")
> => {-3.5550649939662193e+18, 1.1868212582852746e+18, NaN}
> (5) g.inject(-3.5550649939662193e+18, 1.1868212582852746e+18,
> Double.NaN).is(gt(1)).count()
> => 1{code}
> I believe there might be an issue with the has(key, predicate) method based
> on the results that I have obtained.
> However, I am having difficulty further isolating the bug. Would you be able
> to help me reproduce the issue and confirm whether there is indeed a bug, or
> if I may have misunderstood the has(key, predicate) method? Thank you.
> The graph is created as follows:
> {code:java}
> g.addV("Vlabel1").property("prop4",
> -2.2940462564994032e+17).property("prop30",
> "1VjYYDjUBPCI5pKd").property("prop2",
> 2.885236496196127e+18).property("prop27",
> -1.283089519858595e+18).property("prop28",
> -177934796716677957).property("prop11",
> Double.POSITIVE_INFINITY).property("prop7", Double.NaN).property("prop13",
> 1582080133).property("prop12", "ZfcpYP42sDhMoli").property("prop26",
> -369822694828473072).property("prop15", false).property("prop24",
> -2035481923).property("prop3", -8.101739153023826e+17).property("prop18",
> -8647655841519618606).property("prop17",
> Double.NEGATIVE_INFINITY).property("prop21", "9WXEq").property("prop5",
> 7015971082047412708).property("prop23", false).property("prop16",
> -2545300721734184124).property("prop8", false).property("prop9",
> Double.NEGATIVE_INFINITY).property("prop19", -1148359097).property("prop10",
> 707520215).property("prop29", 8230830081810437976).property("prop20",
> 3.8750319078997024e+17).property("prop14",
> 4460313502400034603).property("prop22", Double.NaN).property("PersonalId",
> 1)g.addV("Vlabel2").property("prop13", 844274909).property("prop14",
> -1075402369199667167).property("PersonalId",
> 2)g.addV("Vlabel3").property("prop7",
> 1.882109465594965e+18).property("prop15", false).property("prop4",
> -3.5550649939662193e+18).property("prop9",
> Double.POSITIVE_INFINITY).property("prop17",
> Double.NEGATIVE_INFINITY).property("prop24", 1755404150).property("prop21",
> "i4zl5FELCSxw977").property("prop13", 837413089).property("prop27",
> Double.NaN).property("prop12", "qihyjdv4ac").property("prop2",
> Double.NEGATIVE_INFINITY).property("prop22",
> Double.POSITIVE_INFINITY).property("prop11",
> -1.2786380272506816e+18).property("prop20",
> 1.69612491533634e+18).property("prop30",
> "IxJp6GCr5FRvbvpm6ua").property("prop29",
> -7960090835127371110).property("prop25", true).property("prop18",
> 1839549868490228748).property("prop16",
> -5686358023541700304).property("prop5",
> 5956272628376797503).property("prop19", -1735914445).property("prop23",
> true).property("prop1", Double.POSITIVE_INFINITY).property("prop3",
> -2.871901232555182e+16).property("prop26",
> 7437263094806337639).property("prop8", false).property("PersonalId",
> 3)g.addV("Vlabel4").property("prop3",
> 1.5543717370352646e+17).property("prop18",
> -7149746309261129994).property("prop24", -320785419).property("prop2",
> -1.3058283314253888e+18).property("prop1",
> -1.0673961612545854e+17).property("prop10", -601759324).property("prop16",
> -2436094159597901640).property("prop8", false).property("prop30",
> "gtrb5gw").property("prop26", 3672383367334424219).property("prop28",
> 478907755955172).property("prop12", "w6ursX930r2Y7r").property("prop27",
> 6.736691901333204e+17).property("prop6",
> -5129032340661124781).property("prop9",
> Double.POSITIVE_INFINITY).property("prop15", true).property("prop23",
> true).property("prop29", 3775213037193570604).property("prop19",
> 434486748).property("prop13", -1813611800).property("prop22",
> Double.POSITIVE_INFINITY).property("prop5",
> 6634760243334332508).property("prop11", Double.NaN).property("prop7",
> 1.265249695254938e+18).property("prop17",
> Double.NEGATIVE_INFI
[jira] [Updated] (TINKERPOP-2899) SampleGlobalStep samples inefficiently with TraverserSet running into hash collisions
[
https://issues.apache.org/jira/browse/TINKERPOP-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2899:
Affects Version/s: 3.5.5
> SampleGlobalStep samples inefficiently with TraverserSet running into hash
> collisions
> -
>
> Key: TINKERPOP-2899
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2899
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.5.5
>Reporter: steigma
>Priority: Major
>
> For some queries, the SampleGlobalStep can take a huge amount of time. For
> example, on a Gremlin variant of the LUBM dataset and the following query
> {code:java}
> g.V().hasLabel('Course').sample(1000).in('teacherOf').path() {code}
> the sample step has 108000 traversers as input, but requires over 200
> seconds. More precisely: Collecting all traversers from previous step with
> processAllStarts (see
> [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/SampleGlobalStep.java#L83-L85])
> takes 108344 ms, thereby createProjectedTraverser: 1416 ms,
> traverserSet::add: 106238 ms. The barrierConsumer finished sampling in 121088
> ms, whereby the loop was executed 53356191 times.
>
> There seem to be two issues:
>
> 1. There are many hash collisions when adding the projected traverser to the
> map in the TraverserSet (see
> [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/traverser/util/TraverserSet.java#L91],
> called from the prcessAllStarts
> ([https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/SampleGlobalStep.java#L84]).
> For example, for
> v[[http://www.Department0.University15.edu/Course0|http://www.department0.university15.edu/Course0]],
> we compute the hash code via {{{}super.hashCode() ^
> this.path.hashCode(){}}}, which is {{-2056934079 - -2056934048 = 33}}
> (basically the hash code of the id string XOR the hash code of the path,
> i.e., singleton list of the id string). This leads to many very similar hash
> codes, e.g.,
> {code:java}
> 33
> 103
> 33
> 227
> 33
> 111
> 33
> 995
> 33
> 103
> 33
> 31
> 481
> 39
> 97
> 35
> 225
> 47
> 97
> 35
> 993
> 39
> 225
> 99
> 33
> ... {code}
>
> 2. The sampling algorithm seems to be extremely inefficient (often running
> the loop again without adding a new sample). It is not completely clear why
> it was written that way (lack of documentation), but it may have been
> necessary to correctly handling these “bulks”.
>
> The second issue could potentially be addressed by checking whether all
> traversers have the same weight
> ([https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/SampleGlobalStep.java#L96]),
> which seems to be the case in this example, and then use a more efficient
> sampling approach that just samples a corresponding number of integers
> between 0 and the number of traversers in the sample set and store these
> numbers in a set (with count). With that we can iterate through the
> traverserSet and use the corresponding traversers if we have it sampled.
>
> For the first issue, we can probably just avoid putting them in the
> TraverserSet and use an ArrayList instead. Then we could also directly sample
> from this ArrayList, which may even make this bulk handling superfluous?
>
> There is however also an "efficient" rewrite of this query using fold, local
> sample and unfold:
> {code:java}
> g.V().hasLabel('Course').fold().sample(Scope.local,1000).unfold().in('teacherOf').path()
> {code}
>
> The general question is, however, whether the {color:#1d1c1d}TraverserSet can
> lead to hash collisions in other places. Maybe it makes sense to reevaluate
> the usage of this TraverserSet{color} and, if useful/required, switch to
> something more efficient time-wise (which could then require a bit more
> memory).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2899) SampleGlobalStep samples inefficiently with TraverserSet running into hash collisions
[
https://issues.apache.org/jira/browse/TINKERPOP-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2899:
Priority: Critical (was: Major)
> SampleGlobalStep samples inefficiently with TraverserSet running into hash
> collisions
> -
>
> Key: TINKERPOP-2899
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2899
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.5.5
>Reporter: steigma
>Priority: Critical
>
> For some queries, the SampleGlobalStep can take a huge amount of time. For
> example, on a Gremlin variant of the LUBM dataset and the following query
> {code:java}
> g.V().hasLabel('Course').sample(1000).in('teacherOf').path() {code}
> the sample step has 108000 traversers as input, but requires over 200
> seconds. More precisely: Collecting all traversers from previous step with
> processAllStarts (see
> [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/SampleGlobalStep.java#L83-L85])
> takes 108344 ms, thereby createProjectedTraverser: 1416 ms,
> traverserSet::add: 106238 ms. The barrierConsumer finished sampling in 121088
> ms, whereby the loop was executed 53356191 times.
>
> There seem to be two issues:
>
> 1. There are many hash collisions when adding the projected traverser to the
> map in the TraverserSet (see
> [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/traverser/util/TraverserSet.java#L91],
> called from the prcessAllStarts
> ([https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/SampleGlobalStep.java#L84]).
> For example, for
> v[[http://www.Department0.University15.edu/Course0|http://www.department0.university15.edu/Course0]],
> we compute the hash code via {{{}super.hashCode() ^
> this.path.hashCode(){}}}, which is {{-2056934079 - -2056934048 = 33}}
> (basically the hash code of the id string XOR the hash code of the path,
> i.e., singleton list of the id string). This leads to many very similar hash
> codes, e.g.,
> {code:java}
> 33
> 103
> 33
> 227
> 33
> 111
> 33
> 995
> 33
> 103
> 33
> 31
> 481
> 39
> 97
> 35
> 225
> 47
> 97
> 35
> 993
> 39
> 225
> 99
> 33
> ... {code}
>
> 2. The sampling algorithm seems to be extremely inefficient (often running
> the loop again without adding a new sample). It is not completely clear why
> it was written that way (lack of documentation), but it may have been
> necessary to correctly handling these “bulks”.
>
> The second issue could potentially be addressed by checking whether all
> traversers have the same weight
> ([https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/SampleGlobalStep.java#L96]),
> which seems to be the case in this example, and then use a more efficient
> sampling approach that just samples a corresponding number of integers
> between 0 and the number of traversers in the sample set and store these
> numbers in a set (with count). With that we can iterate through the
> traverserSet and use the corresponding traversers if we have it sampled.
>
> For the first issue, we can probably just avoid putting them in the
> TraverserSet and use an ArrayList instead. Then we could also directly sample
> from this ArrayList, which may even make this bulk handling superfluous?
>
> There is however also an "efficient" rewrite of this query using fold, local
> sample and unfold:
> {code:java}
> g.V().hasLabel('Course').fold().sample(Scope.local,1000).unfold().in('teacherOf').path()
> {code}
>
> The general question is, however, whether the {color:#1d1c1d}TraverserSet can
> lead to hash collisions in other places. Maybe it makes sense to reevaluate
> the usage of this TraverserSet{color} and, if useful/required, switch to
> something more efficient time-wise (which could then require a bit more
> memory).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2897) Merged query using logical operator OR returns false results
[
https://issues.apache.org/jira/browse/TINKERPOP-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704773#comment-17704773
]
Yang Xia commented on TINKERPOP-2897:
-
Closed based on comment above.
> Merged query using logical operator OR returns false results
>
>
> Key: TINKERPOP-2897
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2897
> Project: TinkerPop
> Issue Type: Bug
> Components: driver, server
>Affects Versions: 3.6.2
> Environment: - TinkerGraph Version: 3.6.2
> - Operating system: macOS 13.2.1
> - API/Driver: Java
>Reporter: Zeyang Zhuang
>Priority: Major
>
> We discovered a bug that Syntax error using logical operator AND.
> - TinkerGraph Version: 3.6.2
> - Operating system: macOS 13.2.1
> - API/Driver: Java
> *Expected behavior:*
> We construct the following scenario: we randomly generate two queries Q1, Q2,
> and merge these two queries using OR logical operator into a new query Q3.
> Based on the OR calculation. The Q3 query result set should be the union of
> result sets from Q1 and Q2.
> We generate graph schema and data based on random strings and values. Here is
> one of our examples that triggered the bug.
> 1) `g.V().or(__.values('vp2'))` returns `[0, 18, 2]`
> 2) `g.V().out('el2','el1')` returns `[0, 0, 0, 0, 10, 12, 14, 16, 16, 18, 18,
> 2, 2, 2, 4, 6]`
> 3) `g.V().or(or(__.values('vp2')),out('el2','el1'))` returns `[0, 10, 14, 16,
> 18, 2, 4, 8]`
> We calculate the union result set of Q1 and Q2, which is `[0, 0, 0, 0, 10,
> 12, 14, 16, 16, 18, 18, 2, 2, 2, 4, 6]`.
> The union result set doesn't equal to Q3 result set.
> *Actual behavior:*
> The union result set should equal to Q3 result set. We did trigger some cases
> conform to this requirement, but still there're some cases that violate this
> constraint. This might be a duplicate but the query and logical operator is
> different so I reported it just in case.
> *Steps to reproduce:*
> We create a graph with 10 nodes and 20 edges. We try to make it clear to
> reproduce the bugs, *{*}hope{*}* to not cause much inconvenience to your
> reviewing, but we believe the problem does exist.
> Following the following graph data generation query, we can reproduce the
> bugs:
> Create data
> ```
> Vertex:
> g.addV('vl0').property('vp2',''-|꿃x\'').property(T.id,0)
> g.addV('vl0').property('vp2',''6j}ꎱY'').property(T.id,2)
> g.addV('vl1').property('vp0','-1469571896011420642').property(T.id,4)
> g.addV('vl1').property('vp0','-8118881859321711963').property(T.id,6)
> g.addV('vl1').property('vp0','5851992385413580838').property(T.id,8)
> g.addV('vl1').property('vp0','-4650710188385909827').property(T.id,10)
> g.addV('vl1').property('vp0','-1088319260591605148').property(T.id,12)
> g.addV('vl1').property('vp0','7016141397206128700').property(T.id,14)
> g.addV('vl1').property('vp0','6786856070484969672').property(T.id,16)
> g.addV('vl0').property('vp2',''6j}ꎱY'').property(T.id,18)
> Edge:
> g.V(10).as('10').V(18).as('18').addE('el2').from('10').to('18')
> g.V(18).as('18').V(14).as('14').addE('el1').from('18').to('14')
> g.V(0).as('0').V(16).as('16').addE('el1').from('0').to('16')
> g.V(0).as('0').V(6).as('6').addE('el0').from('0').to('6')
> g.V(18).as('18').V(12).as('12').addE('el0').from('18').to('12')
> g.V(2).as('2').V(4).as('4').addE('el1').from('2').to('4')
> g.V(0).as('0').V(10).as('10').addE('el1').from('0').to('10')
> g.V(14).as('14').V(2).as('2').addE('el2').from('14').to('2')
> g.V(0).as('0').V(4).as('4').addE('el1').from('0').to('4')
> g.V(2).as('2').V(8).as('8').addE('el0').from('2').to('8')
> g.V(4).as('4').V(0).as('0').addE('el2').from('4').to('0')
> g.V(12).as('12').V(2).as('2').addE('el2').from('12').to('2')
> g.V(2).as('2').V(8).as('8').addE('el1').from('2').to('8')
> g.V(0).as('0').V(10).as('10').addE('el0').from('0').to('10')
> g.V(6).as('6').V(0).as('0').addE('el2').from('6').to('0')
> g.V(2).as('2').V(14).as('14').addE('el1').from('2').to('14')
> g.V(16).as('16').V(0).as('0').addE('el2').from('16').to('0')
> g.V(18).as('18').V(8).as('8').addE('el1').from('18').to('8')
> g.V(0).as('0').V(14).as('14').addE('el1').from('0').to('14')
> g.V(16).as('16').V(2).as('2').addE('el2').from('16').to('2')
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2897) Merged query using logical operator OR returns false results
[
https://issues.apache.org/jira/browse/TINKERPOP-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2897.
---
Resolution: Not A Bug
> Merged query using logical operator OR returns false results
>
>
> Key: TINKERPOP-2897
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2897
> Project: TinkerPop
> Issue Type: Bug
> Components: driver, server
>Affects Versions: 3.6.2
> Environment: - TinkerGraph Version: 3.6.2
> - Operating system: macOS 13.2.1
> - API/Driver: Java
>Reporter: Zeyang Zhuang
>Priority: Major
>
> We discovered a bug that Syntax error using logical operator AND.
> - TinkerGraph Version: 3.6.2
> - Operating system: macOS 13.2.1
> - API/Driver: Java
> *Expected behavior:*
> We construct the following scenario: we randomly generate two queries Q1, Q2,
> and merge these two queries using OR logical operator into a new query Q3.
> Based on the OR calculation. The Q3 query result set should be the union of
> result sets from Q1 and Q2.
> We generate graph schema and data based on random strings and values. Here is
> one of our examples that triggered the bug.
> 1) `g.V().or(__.values('vp2'))` returns `[0, 18, 2]`
> 2) `g.V().out('el2','el1')` returns `[0, 0, 0, 0, 10, 12, 14, 16, 16, 18, 18,
> 2, 2, 2, 4, 6]`
> 3) `g.V().or(or(__.values('vp2')),out('el2','el1'))` returns `[0, 10, 14, 16,
> 18, 2, 4, 8]`
> We calculate the union result set of Q1 and Q2, which is `[0, 0, 0, 0, 10,
> 12, 14, 16, 16, 18, 18, 2, 2, 2, 4, 6]`.
> The union result set doesn't equal to Q3 result set.
> *Actual behavior:*
> The union result set should equal to Q3 result set. We did trigger some cases
> conform to this requirement, but still there're some cases that violate this
> constraint. This might be a duplicate but the query and logical operator is
> different so I reported it just in case.
> *Steps to reproduce:*
> We create a graph with 10 nodes and 20 edges. We try to make it clear to
> reproduce the bugs, *{*}hope{*}* to not cause much inconvenience to your
> reviewing, but we believe the problem does exist.
> Following the following graph data generation query, we can reproduce the
> bugs:
> Create data
> ```
> Vertex:
> g.addV('vl0').property('vp2',''-|꿃x\'').property(T.id,0)
> g.addV('vl0').property('vp2',''6j}ꎱY'').property(T.id,2)
> g.addV('vl1').property('vp0','-1469571896011420642').property(T.id,4)
> g.addV('vl1').property('vp0','-8118881859321711963').property(T.id,6)
> g.addV('vl1').property('vp0','5851992385413580838').property(T.id,8)
> g.addV('vl1').property('vp0','-4650710188385909827').property(T.id,10)
> g.addV('vl1').property('vp0','-1088319260591605148').property(T.id,12)
> g.addV('vl1').property('vp0','7016141397206128700').property(T.id,14)
> g.addV('vl1').property('vp0','6786856070484969672').property(T.id,16)
> g.addV('vl0').property('vp2',''6j}ꎱY'').property(T.id,18)
> Edge:
> g.V(10).as('10').V(18).as('18').addE('el2').from('10').to('18')
> g.V(18).as('18').V(14).as('14').addE('el1').from('18').to('14')
> g.V(0).as('0').V(16).as('16').addE('el1').from('0').to('16')
> g.V(0).as('0').V(6).as('6').addE('el0').from('0').to('6')
> g.V(18).as('18').V(12).as('12').addE('el0').from('18').to('12')
> g.V(2).as('2').V(4).as('4').addE('el1').from('2').to('4')
> g.V(0).as('0').V(10).as('10').addE('el1').from('0').to('10')
> g.V(14).as('14').V(2).as('2').addE('el2').from('14').to('2')
> g.V(0).as('0').V(4).as('4').addE('el1').from('0').to('4')
> g.V(2).as('2').V(8).as('8').addE('el0').from('2').to('8')
> g.V(4).as('4').V(0).as('0').addE('el2').from('4').to('0')
> g.V(12).as('12').V(2).as('2').addE('el2').from('12').to('2')
> g.V(2).as('2').V(8).as('8').addE('el1').from('2').to('8')
> g.V(0).as('0').V(10).as('10').addE('el0').from('0').to('10')
> g.V(6).as('6').V(0).as('0').addE('el2').from('6').to('0')
> g.V(2).as('2').V(14).as('14').addE('el1').from('2').to('14')
> g.V(16).as('16').V(0).as('0').addE('el2').from('16').to('0')
> g.V(18).as('18').V(8).as('8').addE('el1').from('18').to('8')
> g.V(0).as('0').V(14).as('14').addE('el1').from('0').to('14')
> g.V(16).as('16').V(2).as('2').addE('el2').from('16').to('2')
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2895) Merged query using logical operator AND returns false results
[
https://issues.apache.org/jira/browse/TINKERPOP-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704774#comment-17704774
]
Yang Xia commented on TINKERPOP-2895:
-
Closed based on comments above.
> Merged query using logical operator AND returns false results
> -
>
> Key: TINKERPOP-2895
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2895
> Project: TinkerPop
> Issue Type: Bug
> Components: driver, server
>Affects Versions: 3.6.2
> Environment: - TinkerGraph Version: 3.6.2
> - Operating system: macOS 13.2.1
> - API/Driver: Java
>Reporter: Zeyang Zhuang
>Priority: Major
>
> We discovered a bug that Merged query using logical operator AND returns
> false results.
> - TinkerGraph Version: 3.6.2
> - Operating system: macOS 13.2.1
> - API/Driver: Java
> *Expected behavior:*
> We construct the following scenario: we randomly generate two queries Q1, Q2,
> and merge these two queries using AND logical operator into a new query Q3.
> Based on the AND calculation. The Q3 query result set should be the
> intersection of result sets from Q1 and Q2.
> We generate graph schema and data based on random strings and values. Here is
> one of our examples that triggered the bug.
> 1) `g.V().outE('el0','el2').bothV()` returns `[0, 0, 11, 11, 13, 13, 13, 13,
> 18, 18, 18, 18, 18, 2, 2, 2, 2, 2, 2, 2, 6, 6, 6, 6, 6, 8, 8, 8]`
> 2) `g.V().hasLabel('vl1','vl0')` returns `[16, 18, 2, 21, 4, 6, 8]`
> 3) `g.V().and(outE('el0','el2').bothV(),hasLabel('vl1','vl0'))` returns `[18,
> 2, 6]`.
> We calculate the intersection result set of Q1 and Q2, which is `[18, 2, 6,
> 8]`.
> The intersection result set doesn't equal to Q3 result set.
> *Actual behavior:*
> The intersection result set should equal to Q3 result set. We did trigger
> some cases conform to this requirement, but still there're some cases that
> violate this constraint.
> *Steps to reproduce:*
> We create a graph with 10 nodes and 20 edges. We try to make it clear to
> reproduce the bugs, {*}{{*}}hope{{*}}{*} to not cause much inconvenience to
> your reviewing, but we believe the problem does exist.
> Following the following graph data generation query, we can reproduce the
> bugs:
> Create data
> ```
> Vertex:
> g.addV('vl2').property('vp2','0.11229777').property(T.id,0)
> g.addV('vl1').property('vp1','0.7532909965461835').property(T.id,2)
> g.addV('vl0').property('vp6','-882633195435277600').property(T.id,4)
> g.addV('vl1').property('vp4','7665355125606600882').property(T.id,6)
> g.addV('vl1').property('vp1','0.7532909965461835').property('vp4','3838824259062394782').property(T.id,8)
> g.addV('vl2').property('vp4','6730135576265295973').property(T.id,11)
> g.addV('vl2').property('vp3','-6896539503167143038').property('vp4','-2940639995931981142').property(T.id,13)
> g.addV('vl0').property('vp6','-2552831883676257311').property(T.id,16)
> g.addV('vl1').property('vp1','0.4100010612879974').property('vp4','-2768293334048120500').property(T.id,18)
> g.addV('vl0').property('vp6','8251747935808021903').property(T.id,21)
> Edge:
> g.V(0).as('0').V(2).as('2').addE('el1').from('0').to('2')
> g.V(8).as('8').V(6).as('6').addE('el0').from('8').to('6')
> g.V(0).as('0').V(18).as('18').addE('el1').from('0').to('18')
> g.V(6).as('6').V(13).as('13').addE('el2').from('6').to('13')
> g.V(18).as('18').V(2).as('2').addE('el0').from('18').to('2')
> g.V(18).as('18').V(0).as('0').addE('el2').from('18').to('0')
> g.V(6).as('6').V(18).as('18').addE('el0').from('6').to('18')
> g.V(2).as('2').V(11).as('11').addE('el2').from('2').to('11')
> g.V(8).as('8').V(13).as('13').addE('el2').from('8').to('13')
> g.V(11).as('11').V(8).as('8').addE('el1').from('11').to('8')
> g.V(18).as('18').V(13).as('13').addE('el2').from('18').to('13')
> g.V(8).as('8').V(0).as('0').addE('el2').from('8').to('0')
> g.V(6).as('6').V(11).as('11').addE('el2').from('6').to('11')
> g.V(11).as('11').V(18).as('18').addE('el1').from('11').to('18')
> g.V(2).as('2').V(6).as('6').addE('el0').from('2').to('6')
> g.V(13).as('13').V(6).as('6').addE('el1').from('13').to('6')
> g.V(0).as('0').V(6).as('6').addE('el1').from('0').to('6')
> g.V(2).as('2').V(13).as('13').addE('el2').from('2').to('13')
> g.V(2).as('2').V(18).as('18').addE('el0').from('2').to('18')
> g.V(2).as('2').V(2).as('2').addE('el0').from('2').to('2')
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2893) Incorrectly comparing a counted value with multiple predicates
[
https://issues.apache.org/jira/browse/TINKERPOP-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2893:
Priority: Critical (was: Minor)
> Incorrectly comparing a counted value with multiple predicates
> --
>
> Key: TINKERPOP-2893
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2893
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Lei Tang
>Priority: Critical
>
> We use a composition of two predicates inside(-1,1).and(lt(-1)) to filter
> numbers that are greater than -1 and less -1. Obviously, no values satisfy
> this condition. Therefore, we expect Tinkergraph returns an empty set.
> However, a vertex is returned.
> {code:java}
> gremlin> :> g.V().where(__.in('knows').count().is(inside(-1,1).and(lt(-1
> ==>v[0] {code}
> The graph of this example is as following.
> {code:java}
> Vertex bob = g.addV("person").property("name", "Bob").next(); // v[0]
> Vertex alice = g.addV("person").property("name", "Alice").next(); // v[1]
> Edge edge1 = g.addE("knows").from(bob).to(alice).next();{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2895) Merged query using logical operator AND returns false results
[
https://issues.apache.org/jira/browse/TINKERPOP-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2895.
---
Resolution: Not A Problem
> Merged query using logical operator AND returns false results
> -
>
> Key: TINKERPOP-2895
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2895
> Project: TinkerPop
> Issue Type: Bug
> Components: driver, server
>Affects Versions: 3.6.2
> Environment: - TinkerGraph Version: 3.6.2
> - Operating system: macOS 13.2.1
> - API/Driver: Java
>Reporter: Zeyang Zhuang
>Priority: Major
>
> We discovered a bug that Merged query using logical operator AND returns
> false results.
> - TinkerGraph Version: 3.6.2
> - Operating system: macOS 13.2.1
> - API/Driver: Java
> *Expected behavior:*
> We construct the following scenario: we randomly generate two queries Q1, Q2,
> and merge these two queries using AND logical operator into a new query Q3.
> Based on the AND calculation. The Q3 query result set should be the
> intersection of result sets from Q1 and Q2.
> We generate graph schema and data based on random strings and values. Here is
> one of our examples that triggered the bug.
> 1) `g.V().outE('el0','el2').bothV()` returns `[0, 0, 11, 11, 13, 13, 13, 13,
> 18, 18, 18, 18, 18, 2, 2, 2, 2, 2, 2, 2, 6, 6, 6, 6, 6, 8, 8, 8]`
> 2) `g.V().hasLabel('vl1','vl0')` returns `[16, 18, 2, 21, 4, 6, 8]`
> 3) `g.V().and(outE('el0','el2').bothV(),hasLabel('vl1','vl0'))` returns `[18,
> 2, 6]`.
> We calculate the intersection result set of Q1 and Q2, which is `[18, 2, 6,
> 8]`.
> The intersection result set doesn't equal to Q3 result set.
> *Actual behavior:*
> The intersection result set should equal to Q3 result set. We did trigger
> some cases conform to this requirement, but still there're some cases that
> violate this constraint.
> *Steps to reproduce:*
> We create a graph with 10 nodes and 20 edges. We try to make it clear to
> reproduce the bugs, {*}{{*}}hope{{*}}{*} to not cause much inconvenience to
> your reviewing, but we believe the problem does exist.
> Following the following graph data generation query, we can reproduce the
> bugs:
> Create data
> ```
> Vertex:
> g.addV('vl2').property('vp2','0.11229777').property(T.id,0)
> g.addV('vl1').property('vp1','0.7532909965461835').property(T.id,2)
> g.addV('vl0').property('vp6','-882633195435277600').property(T.id,4)
> g.addV('vl1').property('vp4','7665355125606600882').property(T.id,6)
> g.addV('vl1').property('vp1','0.7532909965461835').property('vp4','3838824259062394782').property(T.id,8)
> g.addV('vl2').property('vp4','6730135576265295973').property(T.id,11)
> g.addV('vl2').property('vp3','-6896539503167143038').property('vp4','-2940639995931981142').property(T.id,13)
> g.addV('vl0').property('vp6','-2552831883676257311').property(T.id,16)
> g.addV('vl1').property('vp1','0.4100010612879974').property('vp4','-2768293334048120500').property(T.id,18)
> g.addV('vl0').property('vp6','8251747935808021903').property(T.id,21)
> Edge:
> g.V(0).as('0').V(2).as('2').addE('el1').from('0').to('2')
> g.V(8).as('8').V(6).as('6').addE('el0').from('8').to('6')
> g.V(0).as('0').V(18).as('18').addE('el1').from('0').to('18')
> g.V(6).as('6').V(13).as('13').addE('el2').from('6').to('13')
> g.V(18).as('18').V(2).as('2').addE('el0').from('18').to('2')
> g.V(18).as('18').V(0).as('0').addE('el2').from('18').to('0')
> g.V(6).as('6').V(18).as('18').addE('el0').from('6').to('18')
> g.V(2).as('2').V(11).as('11').addE('el2').from('2').to('11')
> g.V(8).as('8').V(13).as('13').addE('el2').from('8').to('13')
> g.V(11).as('11').V(8).as('8').addE('el1').from('11').to('8')
> g.V(18).as('18').V(13).as('13').addE('el2').from('18').to('13')
> g.V(8).as('8').V(0).as('0').addE('el2').from('8').to('0')
> g.V(6).as('6').V(11).as('11').addE('el2').from('6').to('11')
> g.V(11).as('11').V(18).as('18').addE('el1').from('11').to('18')
> g.V(2).as('2').V(6).as('6').addE('el0').from('2').to('6')
> g.V(13).as('13').V(6).as('6').addE('el1').from('13').to('6')
> g.V(0).as('0').V(6).as('6').addE('el1').from('0').to('6')
> g.V(2).as('2').V(13).as('13').addE('el2').from('2').to('13')
> g.V(2).as('2').V(18).as('18').addE('el0').from('2').to('18')
> g.V(2).as('2').V(2).as('2').addE('el0').from('2').to('2')
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2891) Inconsistent behavior when comparing a counted value with a negative value
[
https://issues.apache.org/jira/browse/TINKERPOP-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2891:
Priority: Critical (was: Minor)
> Inconsistent behavior when comparing a counted value with a negative value
> --
>
> Key: TINKERPOP-2891
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2891
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Lei Tang
>Priority: Critical
>
> I compare a value that should be greater than or equal to 0 with a negative
> value.
> {code:java}
> gremlin> :> g.V().where(__.in().count().is(eq(-3)))
> Not a legal range: [0, -2]
> gremlin> :> g.V().where(__.in().count().is(eq(-2))){code}
> I find that Tinkergraph throws an exception when comparing negative values
> less than -2, but does nothing when comparing with -2.
> I'm curious why they behave differently.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2890) Avoid exceptions on local scope based steps where possible
[
https://issues.apache.org/jira/browse/TINKERPOP-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2890:
Priority: Critical (was: Minor)
> Avoid exceptions on local scope based steps where possible
> --
>
> Key: TINKERPOP-2890
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2890
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.5.5
>Reporter: Stephen Mallette
>Priority: Critical
>
> If you {{g.inject([1,2], 1])dedup(local)}} you get an casting error because
> "1" is not an {{Iterable}} and {{local}} only works with that type. Would be
> better if a {{dedup()}} of a non-iterable just returned the object itself.
> Consider other steps that use {{local}} and make similar improvements there
> for consistency.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2889) Support kerberos authentication for gremlin-javascript
[ https://issues.apache.org/jira/browse/TINKERPOP-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2889: Affects Version/s: 3.5.5 > Support kerberos authentication for gremlin-javascript > -- > > Key: TINKERPOP-2889 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2889 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Affects Versions: 3.5.5 >Reporter: Tom Kolanko >Priority: Minor > > Currently only the Java and Python drivers support kerberos authentication. > Ideally all driver variants would support it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2880) Deserialization of Untrusted Data in Neo4j
[ https://issues.apache.org/jira/browse/TINKERPOP-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia closed TINKERPOP-2880. --- Resolution: Not A Bug Closing per discussion on dev: https://lists.apache.org/thread/hz3rf0rr79198g97kn9k92x46h2goo0k > Deserialization of Untrusted Data in Neo4j > -- > > Key: TINKERPOP-2880 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2880 > Project: TinkerPop > Issue Type: Improvement > Components: neo4j >Affects Versions: 3.6.2 >Reporter: Jim Foscue >Priority: Major > Labels: Ironbank > > Vulnerability in neo4j-3.4.11. > Need to update to 3.5 or higher. > [https://github.com/advisories/GHSA-pc4w-8v5j-29w9] > > Package path... > * /opt/gremlin-server/ext/neo4j-gremlin/lib/neo4j-3.4.11.jar > * /opt/gremlin-server/ext/neo4j-gremlin/plugin/neo4j-3.4.11.jar > * /root/.groovy/grapes/org.neo4j/neo4j/jars/neo4j-3.4.11.jar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2878) Incorrect handling of local operations when there are duplicate elements
[
https://issues.apache.org/jira/browse/TINKERPOP-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2878:
Priority: Critical (was: Major)
> Incorrect handling of local operations when there are duplicate elements
>
>
> Key: TINKERPOP-2878
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2878
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.2
>Reporter: Miracy Cavendish
>Priority: Critical
>
> When using “local” to query the vertex with maximum out-degree among
> vertices, there is a different result between using “dedup()” and without
> “dedup()”.
> {code:java}
> Gremlin1: g.V().both().local(__.out().count()).max()
> Result1: 280
> Gremlin2: g.V().both().dedup().local(__.out().count()).max()
> Result2: 14{code}
> _Result1_ should equal _Result2_ according to the [gremlin
> document|https://tinkerpop.apache.org/javadocs/3.4.1/core/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.html#local-org.apache.tinkerpop.gremlin.process.traversal.Traversal-]
> “Local provides a execute a specified traversal on a single element within a
> stream.”, whereas 280 ≠ 14.
> The possible reason is that the database does not handle the bulked data
> correctly when there are duplicate elements: for the reduced data
> (There are x vertices with ID v)， the database will map it to x *
> out(v).count() (a number) instead of , which results in
> inconsistency.
> We noticed that there is an example of “local” provided by the ["Tinkerpop
> Documents”|https://tinkerpop.apache.org/docs/current/reference/#local-step],
> which shows the difference between _“local”_ and {_}“flatMap”’{_}, and we can
> not obtain the correct result in the provided case since _“local”_ propagates
> the traverser through the internal traversal as is without splitting/cloning
> it.
> Nevertheless, the results of the current execution of the above statement
> also contradict the [gremlin
> document|https://tinkerpop.apache.org/javadocs/3.4.1/core/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.html#local-org.apache.tinkerpop.gremlin.process.traversal.Traversal-]
> but could be alleviated. Therefore, we suggest using a second way
> of handling reduced data to alleviate this situation.
> The graph is created by the following statements:
> {code:java}
> g.addV("Vlabel1").property("prop11", true).property("prop26",
> -1.3054643785208727e+18).property("prop3",
> 5955883311802481410).property("PersonalId", 1)
> g.addV("Vlabel2").property("prop23", 1013597808).property("prop14",
> Double.POSITIVE_INFINITY).property("prop29",
> -8.088511244487521e+18).property("prop1",
> -791166414100353228).property("prop10", Double.NaN).property("prop20",
> false).property("prop12", -1.611044197269977e+18).property("prop8",
> Double.POSITIVE_INFINITY).property("prop28",
> "r8OwmXN0z4xVA32DuW").property("prop7", true).property("prop18",
> 122416389).property("prop4", -133008224708918302).property("prop16",
> Double.POSITIVE_INFINITY).property("prop5",
> 2.199870305073074e+18).property("prop30", 1951661449).property("PersonalId",
> 2)
> g.addV("Vlabel3").property("prop13", -1833987394).property("prop11",
> false).property("prop20", true).property("prop28", "Eb").property("prop26",
> Double.POSITIVE_INFINITY).property("prop19",
> "fkOMPiHGK4Qh9AEt").property("prop4", 7223784666736222475).property("prop21",
> "emdyKI4gibcntwr9xr1R").property("prop8",
> 1.6766837870245322e+18).property("prop6",
> "KPvJU8zUZkDujXO5").property("prop5",
> Double.POSITIVE_INFINITY).property("prop16",
> Double.NEGATIVE_INFINITY).property("prop29",
> -6.379213156782167e+16).property("prop9",
> -2639063587618099127).property("prop2",
> -4223871862589164789).property("prop7", true).property("prop22",
> 3.3866441258784246e+18).property("prop12",
> Double.NEGATIVE_INFINITY).property("prop15",
> Double.POSITIVE_INFINITY).property("prop27", -811138702).property("prop18",
> -823086061).property("prop30", 1766879986).property("prop10",
> Double.NEGATIVE_INFINITY).property("prop25", true).property("prop17",
> -7.221182960918364e+17).property("prop3",
> 3709150069759562136).property("prop24", true).property("prop23",
> 2089722858).property("prop1", 4952669033574350283).property("PersonalId", 3)
> g.addV("Vlabel4").property("prop18", 1921954359).property("prop9",
> 3679390972557414017).property("prop28", "zea").property("prop5",
> -5.37655340395617e+18).property("prop23", 873631855).property("prop29",
> -4.730510618138025e+18).property("prop13", 262081621).property("prop27",
> 954111430).property("prop25", true).property("prop7",
> false).property("prop12", Double.POSITIVE_INFINITY).property("prop24",
> false).property("Per
[jira] [Closed] (TINKERPOP-2875) Duplicate elements are omitted when turning off bulk optimization
[
https://issues.apache.org/jira/browse/TINKERPOP-2875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2875.
---
Resolution: Not A Bug
> Duplicate elements are omitted when turning off bulk optimization
> -
>
> Key: TINKERPOP-2875
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2875
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Lei Tang
>Priority: Major
>
> I create three vertices and two edges.
> {code:java}
> Vertex v1 = g.addV("vl0").property("vp0", 1).next(); // v[1]
> Vertex v2 = g.addV("vl0").property("vp0", 2).next(); // v[2]
> Vertex v3 = g.addV("vl0").property("vp0", 3).next(); // v[3]
> Edge e1 = g.addE("el0").from(v1).to(v2).next();
> Edge e2 = g.addE("el0").from(v1).to(v3).next();{code}
> When I execute the query 'g.E().outV()' without using bulk optimization, I
> expect the result \{v1,v1} is returned. However, it removes the duplicate
> vertices.
> {code:java}
> gremlin> :> g.withBulk(false).E().outV()
> ==>v[1]
> gremlin> :> g.E().outV()
> ==>v[1]
> ==>v[1]
> {code}
> Since I do not use bulk operations in this query, I expect that even if we
> turn off bulk opitmization, we can compute the correct result.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2871) Borrowed count can be wildly incorrect
[ https://issues.apache.org/jira/browse/TINKERPOP-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2871: Priority: Critical (was: Minor) > Borrowed count can be wildly incorrect > -- > > Key: TINKERPOP-2871 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2871 > Project: TinkerPop > Issue Type: Bug > Components: driver >Affects Versions: 3.5.5 >Reporter: Stephen Mallette >Priority: Critical > > It doesn't seem like it affects the algorithm for borrowing/closing > connections in the pool but the borrowed counter can sometimes reach wildly > large numbers. it shows up in the log and is confusing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2863) HasId Step generates incorrect results when given a list of IDs mid-traversal
[
https://issues.apache.org/jira/browse/TINKERPOP-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2863:
Priority: Critical (was: Major)
> HasId Step generates incorrect results when given a list of IDs mid-traversal
> -
>
> Key: TINKERPOP-2863
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2863
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.2
>Reporter: Taylor Riggan
>Priority: Critical
>
> In most situations, hasId() will accept a list of potential IDs to filter on
> and implicitly use within() filtering semantics to return the correct
> results. Examples:
> {code:java}
> g.V().hasId(['1','2'])
> {code}
> returns:
> {code:java}
> [v[1], v[2]]{code}
> or
> {code:java}
> g.E().hasId(['5140','5261']){code}
> returns:
> {code:java}
> [e[5140][1-route->51], e[5261][1-route->398]]{code}
> However, when using the same form of semantics mid-traversal, both of these
> queries return empty results:
> {code:java}
> g.V().has('code','ATL').outE('route').hasId(['5140','5261'])
> g.V().has('code','ATL').outE('route').inV().hasId(['2','3'])
> {code}
> When using profile() against both queries, the hasId() bytecode gets
> transformed into
> {code:java}
> HasStep([~id.eq([5140, 5261])]) {code}
> This equates to finding a vertex or edge with an ID that matches the entire
> list instead of the elements within the list.
> The preceding was tested against Gremlin Server 3.6.2 with the Airroutes
> dataset.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2862) A grammar in TinkerPop should accept withoutStrategies
[
https://issues.apache.org/jira/browse/TINKERPOP-2862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2862:
Fix Version/s: (was: 3.7.0)
> A grammar in TinkerPop should accept withoutStrategies
> --
>
> Key: TINKERPOP-2862
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2862
> Project: TinkerPop
> Issue Type: Improvement
> Components: language
>Affects Versions: 3.6.1, 3.5.4
>Reporter: Norio Akagi
>Priority: Major
>
> In our Grammar, we have {{withStrategies}} but not {{{}withoutStrategies{}}}.
> [https://github.com/apache/tinkerpop/blob/08afd4e475b56189500c31361b624ecc687e8b7b/gremlin-language/src/main/antlr4/Gremlin.g4#L65]
>
> We should support so that a caller can disable a specific TinkerPop optimizer
> at will. Note that graph providers can have their own Strategy, which may be
> out of scope of {{withoutStrategies.}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2856) math() step fails if variable name contains a keyword
[
https://issues.apache.org/jira/browse/TINKERPOP-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2856:
Priority: Critical (was: Major)
> math() step fails if variable name contains a keyword
> -
>
> Key: TINKERPOP-2856
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2856
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.4
> Environment: Any Gremlin version that has the math() step. Reproduced
> on 3.6.0
>Reporter: Kelvin Lawrence
>Priority: Critical
>
> As reported on
> [StackOverflow|https://stackoverflow.com/questions/74121856/gremlin-reserved-word-exp]
> if a variable used as part of the math() step contains a reserved word such
> as "exp" the evaluation of the expression fails. For example
>
> {code:java}
> math('number1-expected_value').next(){code}
> results in
> {code:java}
> *GremlinServerError: 499: {"detailedMessage":"Unknown function or variable
> 'cted_value' at pos 20 in expression 'number1 -
> expected_value'","requestId":"01e3f9e6-3cf2-4af0-bf94-5a4979d488b4","code":"InvalidParameterException"}*{code}
> {{{}I am able to reproduce this in the Gremlin Console using TinkerPop
> version 3.6.0 using:{}}}}}{}}}
> {code:java}
> gremlin> g.inject(1).as('expa').constant(2).as('c').math('c - expa')
> Unknown function or variable 'a' at pos 7 in expression 'c - expa'
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> gremlin> g.inject(1).as('a').constant(2).as('c').math('c - a')
> ==>1.0 {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2852) Update Maven plugin for docker-images building for M1 compatibility
[ https://issues.apache.org/jira/browse/TINKERPOP-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2852: Priority: Critical (was: Major) > Update Maven plugin for docker-images building for M1 compatibility > --- > > Key: TINKERPOP-2852 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2852 > Project: TinkerPop > Issue Type: Improvement > Components: build-release >Affects Versions: 3.5.4 >Reporter: Yang Xia >Priority: Critical > > The current Maven plug in we use for the `docker-image` building profile is > no longer maintained > ([https://github.com/spotify/dockerfile-maven)|https://github.com/spotify/dockerfile-maven).], > and it is also not compatible with M1 Macs. > We should consider swapping the plug in for an actively maintained one that > is M1 compatible, for example > [https://github.com/fabric8io/docker-maven-plugin/issues/1257.|https://github.com/fabric8io/docker-maven-plugin/issues/1257] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2855) Performance degradation in TinkerGraph 3.5.4 and 3.5.5
[
https://issues.apache.org/jira/browse/TINKERPOP-2855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2855:
Priority: Critical (was: Major)
> Performance degradation in TinkerGraph 3.5.4 and 3.5.5
> --
>
> Key: TINKERPOP-2855
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2855
> Project: TinkerPop
> Issue Type: Bug
> Components: tinkergraph
>Affects Versions: 3.5.4, 3.5.5
> Environment: Ubuntu 22.04.1, docker
>Reporter: Gleb Sinyavskiy
>Priority: Critical
> Labels: bug, performance
>
> Hello,
> I few days ago I tried to update gremlin-server in our project from 3.5.3 to
> 3.5.4 and found out that it's test suite got 5 times slower. We use the
> official docker image(tinkerpop/gremlin-server) with some configuration
> changes:
> {code:java}
> gremlin.tinkergraph.vertexIdManager=ANY
> gremlin.tinkergraph.edgeIdManager=ANY {code}
> The app uses user-generated string ids and heavily relies on the upsert
> pattern from the [recipes|https://tinkerpop.apache.org/docs/3.5.4/recipes/].
> Yesterday I made an investigation and narrowed it down to the performance of
> the upsert pattern. I also discovered that the issue is not related to our
> configuration changes and can be reproduced with vanilla image and LONG ids.
> I prepared a [simple script that reproduces the
> issue|https://github.com/zhulik/gremlin-server-performance-issue/] and
> contacted Stephen Mallette on discord. They confirmed the issue exists, but
> only in 3.5.4, 3.6.0 performs as expected. They also wrote a groovy script
> that reproduces the problem:
> {code:groovy}
> g = TinkerGraph.open().traversal()
> batches = (0..<100).collect{ (0..<100) }
> start = System.currentTimeMillis()
> for (batch in batches) {
> b = g
> for (id in batch) {
> b = b.V(id).fold().coalesce(__.unfold(), __.addV("test").property(T.id,
> id))
> }
> b.iterate()
> }
> System.currentTimeMillis() - start
> {code}
> [discord
> message|https://discord.com/channels/838910279550238720/838910279550238723/1064964247823593502]
> Both my and Stephen's scripts perform a few times slower when executed
> against 3.5.4 in compare to 3.5.3 or 3.6.0.
> *Steps to reproduce:*
> Run my or Stephen's script against vanilla tinkerpop/gremlin-server:3.5.4
> docker image
> *Expected result:*
> Script's execution time matches it's time when executed against 3.5.3 or 3.6.0
> *Observed result:*
> The script is 5-7 times slower.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2845) Race conditions in Go GLV
[
https://issues.apache.org/jira/browse/TINKERPOP-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2845:
Priority: Critical (was: Major)
> Race conditions in Go GLV
> -
>
> Key: TINKERPOP-2845
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2845
> Project: TinkerPop
> Issue Type: Bug
> Components: go
>Affects Versions: 3.7.0
>Reporter: Cole Greer
>Priority: Critical
>
> While working on writing tests for the Go GLV using
> [gremlin-socket-server|https://issues.apache.org/jira/browse/TINKERPOP-2819],
> 2 possible race conditions were detected by go test -race. The provided test
> code I will include is relying on configuration and docker setup which has
> not yet been merged to tinkerpop and is being included for reference only. I
> will update this ticket once the relevant supporting code is included in
> Tinkerpop and these tests can be run.
>
> Race condition 1:
> {code:java}
> func TestClientAgainstSocketServer(t *testing.T) {
>// Integration test variables.
>testNoAuthEnable := getEnvOrDefaultBool("RUN_INTEGRATION_TESTS", true)
>settings :=
> FromYaml(getEnvOrDefaultString("GREMLIN_SOCKET_SERVER_CONFIG_PATH",
> "../../gremlin-tools/gremlin-socket-server/conf/test-ws-gremlin.yaml"))
>testSocketServerUrl := getEnvOrDefaultString("GREMLIN_SOCKET_SERVER_URL",
> "ws://localhost")
>testSocketServerUrl = fmt.Sprintf("%s:%v/gremlin", testSocketServerUrl,
> settings.PORT)
>t.Run("Should try create new connection if closed by server", func(t
> *testing.T) {
> skipTestsIfNotEnabled(t, integrationTestSuiteName, testNoAuthEnable)
> client, _ := NewClient(testSocketServerUrl)
> //The server will immediately close the connection upon receiving this
> request creating a 1005 error
> resultSet, _ := client.Submit("1", map[string]interface{}{"requestId":
> settings.CLOSE_CONNECTION_REQUEST_ID})
> resultSet.One()
> client.Close()
>})
> } {code}
> {code:java}
> === RUN TestClientAgainstSocketServer === CONT
> TestClientAgainstSocketServer testing.go:1319: race detected during
> execution of test --- FAIL: TestClientAgainstSocketServer (1.04s) === RUN
> TestClientAgainstSocketServer/Should_try_create_new_connection_if_closed_by_server
> 2022/12/16 10:43:37 Connecting. 2022/12/16 10:43:38 Read loop error
> 'websocket: close 1005 (no status)', closing read loop. 2022/12/16 10:43:38
> Read loop error 'websocket: close 1005 (no status)', closing read loop.
> == WARNING: DATA RACE Write at 0x00c000358040 by goroutine
> 15:
> github.com/apache/tinkerpop/gremlin-go/v3/driver.(*channelResultSet).setError()
> /Users/coleg/tinkerpop/gremlin-go/driver/resultSet.go:79 +0x80
> github.com/apache/tinkerpop/gremlin-go/v3/driver.(*synchronizedMap).closeAll()
> /Users/coleg/tinkerpop/gremlin-go/driver/connection.go:154 +0xfc
> github.com/apache/tinkerpop/gremlin-go/v3/driver.readErrorHandler()
> /Users/coleg/tinkerpop/gremlin-go/driver/protocol.go:93 +0xd8
> github.com/apache/tinkerpop/gremlin-go/v3/driver.(*gremlinServerWSProtocol).readLoop()
> /Users/coleg/tinkerpop/gremlin-go/driver/protocol.go:70 +0x448
> github.com/apache/tinkerpop/gremlin-go/v3/driver.newGremlinServerWSProtocol.func1()
> /Users/coleg/tinkerpop/gremlin-go/driver/protocol.go:200 +0x4cPrevious
> read at 0x00c000358040 by goroutine 8:
> github.com/apache/tinkerpop/gremlin-go/v3/driver.(*channelResultSet).One()
> /Users/coleg/tinkerpop/gremlin-go/driver/resultSet.go:171 +0x34
> github.com/apache/tinkerpop/gremlin-go/v3/driver.TestClientAgainstSocketServer.func1()
> /Users/coleg/tinkerpop/gremlin-go/driver/client_test.go:122 +0x1a4
> testing.tRunner()
> /opt/homebrew/Cellar/go/1.19.1/libexec/src/testing/testing.go:1446 +0x188
> testing.(*T).Run.func1()
> /opt/homebrew/Cellar/go/1.19.1/libexec/src/testing/testing.go:1493
> +0x40Goroutine 15 (running) created at:
> github.com/apache/tinkerpop/gremlin-go/v3/driver.newGremlinServerWSProtocol()
> /Users/coleg/tinkerpop/gremlin-go/driver/protocol.go:200 +0x398
> github.com/apache/tinkerpop/gremlin-go/v3/driver.createConnection()
> /Users/coleg/tinkerpop/gremlin-go/driver/connection.go:110 +0x204
> github.com/apache/tinkerpop/gremlin-go/v3/driver.newLoadBalancingPool.func1()
> /Users/coleg/tinkerpop/gremlin-go/driver/connectionPool.go:150
> +0xa8Goroutine 8 (running) created at: testing.(*T).Run()
> /opt/homebrew/Cellar/go/1.19.1/libexec/src/testing/testing.go:1493 +0x55c
> github.com/apache/tinkerpop/gremlin-go/v3/driver.TestClientAgainstSocketServer()
> /Users/coleg/tinkerpop/gremlin-go/driver/client_test.go:115 +0x1cc
> testing.tRunner()
> /opt/homebre
[jira] [Updated] (TINKERPOP-2832) Nature of sessions and driver reconnect allow bytecode transactions to appear to remain open
[ https://issues.apache.org/jira/browse/TINKERPOP-2832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2832: Priority: Critical (was: Major) > Nature of sessions and driver reconnect allow bytecode transactions to appear > to remain open > > > Key: TINKERPOP-2832 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2832 > Project: TinkerPop > Issue Type: Bug > Components: driver, server >Affects Versions: 3.5.4 >Reporter: Stephen Mallette >Priority: Critical > > The driver is design to reconnect if it loses its connection to the server. > For sessions a close can happen if there is a timeout on the session itself. > On the server the session is invalidated, but on the client side, it tries to > reconnect using the same session id. Unfortunately this reconnect creates a > scenario for bytecode transactions where it can appear as though you're > working the same transaction when you are not. > Test to demonstrate shown > [here|https://github.com/apache/tinkerpop/commit/4528ec33ab56e3c0526ad8b38494674c64754e54] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2820) gremlin-python _close_session race condition/FD leak
[
https://issues.apache.org/jira/browse/TINKERPOP-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2820:
Priority: Critical (was: Minor)
> gremlin-python _close_session race condition/FD leak
>
>
> Key: TINKERPOP-2820
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2820
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.6.1
>Reporter: Alex Hamilton
>Priority: Critical
>
> There is a race condition in gremlin-python when closing session-based
> connections that results in leaking file descriptors for event loops -
> eventually leading to an `OSError [Errno 24] too many open files` error after
> enough transactions occur.
> The problem stems from a race condition when closing session based
> connections that causes the event loop opened for the session's connection to
> be left open.
> The problem is completely contained in these two methods from
> `gremlin_python.driver.client.py`
> ```py
> def close(self):
> # prevent the Client from being closed more than once. it raises errors
> if new jobby jobs
> # get submitted to the executor when it is shutdown
> if self._closed:
> return
> if self._session_enabled:
> self._close_session() # 1. (see below)
> log.info("Closing Client with url '%s'", self._url)
> while not self._pool.empty(): # 3. (see below)
> conn = self._pool.get(True)
> conn.close()
> self._executor.shutdown()
> self._closed = True
> def _close_session(self):
> message = request.RequestMessage(
> processor='session', op='close',
> args=\{'session': str(self._session)})
> conn = self._pool.get(True)
> return conn.write(message).result() # 2. (see below)
> ```
> 1. `_close_session()` called
> 2. `.result()` waits for the _write_ to finish, but does *not* wait for the
> _read_ to finish. `conn` does not get put back into `self._pool` until AFTER
> the read finishes (`gremlin_python.driver.connection.Connection._receive()`).
> However, this method returns early and goes to 3.
> 3. this while loop is not entered to close out the connections. This leaves
> the conn's event loop running, never to be closed.
> I was able to solve this by modifying `_close_session` as follows:
> ```py
> def _close_session(self):
> message = request.RequestMessage(
> processor='session', op='close',
> args=\{'session': str(self._session)})
> conn = self._pool.get(True)
> try:
> write_result_set = conn.write(message).result()
> return write_result_set.all().result() # wait for _receive() to finish
> except protocol.GremlinServerError:
> pass
> ```
> I'm not sure if this is the correct solution, but wanted to point out the bug.
> In the meantime however, I wrote a context manager to handle this cleanup for
> me
> ```py
> @contextlib.contextmanager
> def transaction():
> tx = g.tx()
> gtx = tx.begin()
> try:
> yield tx, gtx
> tx.commit()
> except Exception as e:
> tx.rollback()
> finally:
> while not tx._session_based_connection._client._pool.empty():
> conn = tx._session_based_connection._client._pool.get(True)
> conn.close()
> logger.info("Closed abandoned session connection")
> with transaction() as (tx, gtx):
> foo = gtx.some_traversal().to_list()
> # do something with foo
> gtx.some_other_traversal().iterate()
> ```
> Cheers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2782) WebSocketAuthorizationHandler does not transfer the request's sessionId, needed in UnifiedHandler
[
https://issues.apache.org/jira/browse/TINKERPOP-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2782:
Affects Version/s: (was: 3.6.0)
(was: 3.5.3)
(was: 3.5.4)
(was: 3.6.1)
> WebSocketAuthorizationHandler does not transfer the request's sessionId,
> needed in UnifiedHandler
> -
>
> Key: TINKERPOP-2782
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2782
> Project: TinkerPop
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.2
>Reporter: Rusi Popov
>Priority: Major
>
> When the gremlin-server.yaml configures the gremlin server to use the
> UnifiedChannelizer with an explicit Authorizer:
> {code:yaml}
> channelizer: org.apache.tinkerpop.gremlin.server.channel.UnifiedChannelizer
> authorization:
> authorizer:
> {code}
> the UnifiedChannelizer registers
> org.apache.tinkerpop.gremlin.server.handler.WebSocketAuthorizationHandler
> before org.apache.tinkerpop.gremlin.server.handler.UnifiedHandler in the
> pipeline.
> The WebSocketAuthorizationHandler uses the Authorizer to transform the
> bytecode, builds a new request message with the transformed bytecode, and
> pushes the new message down the pipeline for processing:
> (in 3.6.1 these are lines 66-77)
> {code:java}
> case Tokens.OPS_BYTECODE:
> final Bytecode bytecode = (Bytecode)
> requestMessage.getArgs().get(Tokens.ARGS_GREMLIN);
> final Map aliases = (Map)
> requestMessage.getArgs().get(Tokens.ARGS_ALIASES);
> final Bytecode restrictedBytecode = authorizer.authorize(user, bytecode,
> aliases);
> final RequestMessage restrictedMsg =
> RequestMessage.build(Tokens.OPS_BYTECODE).
> overrideRequestId(requestMessage.getRequestId()).
> processor("traversal").
> addArg(Tokens.ARGS_GREMLIN, restrictedBytecode).
> addArg(Tokens.ARGS_ALIASES, aliases).create();
> ctx.fireChannelRead(restrictedMsg);
> break;
> {code}
> Next is the org.apache.tinkerpop.gremlin.server.handler.UnifiedHandler, which
> uses session ID for session detection:
> (lines 146-147)
> {code:java}
> final Optional optMultiTaskSession =
> msg.optionalArgs(Tokens.ARGS_SESSION);
> final String sessionId =
> optMultiTaskSession.orElse(msg.getRequestId().toString());
> {code}
> *The problem:*
> WebSocketAuthorizationHandler does not transfer the Tokens.ARGS_SESSION to
> the UnifiedHandler so it uses request's ID as every time a new session ID
> *Suggestion:*
> in WebSocketAuthorizationHandler iterate on the args and copy every arg but
> ARGS_GREMLIN, then set the latter to the restricted bytecode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2784) Gremlin Server on Windows in GitHub Actions slows down significantly for some tests occasionally
[ https://issues.apache.org/jira/browse/TINKERPOP-2784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia closed TINKERPOP-2784. --- Resolution: Invalid Windows GHA are disabled for now due to GitHub not able to run Linux based images on Windows Servers. We may re-open in the future if they are enabled. > Gremlin Server on Windows in GitHub Actions slows down significantly for some > tests occasionally > > > Key: TINKERPOP-2784 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2784 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.5.4 > Environment: Windows - GitHub Actions >Reporter: Rithin Kumar R S >Priority: Minor > > Gremlin Server has been observed to occasionally slow down when running > Integration and Cucumber Tests on Windows in GitHub Actions. Here is an > example illustrating the slowdown: > Every so often (~2% of the time) on GitHub Actions, the Windows workflow for > Gremlin Javascript will fail. There is a recurring failure from the scenario > 'g_V_connectedComponent_hasXcomponentX' on the 'When iterated to list' step > in 'ConnectedComponent.feature'. This can be observed in this Workflow Run: > [Link|https://github.com/L0Lmaker/tinkerpop/runs/7755756716?check_suite_focus=true#step:4:12408]. > When 'g_V_connectedComponent_hasXcomponentX' fails, sometimes other > scenarios like 'g_V_dedup_connectedComponent_hasXcomponentX' can also fail. > On adding some server logs, on the failed tests we can observe that on the > server side, the request is still processed but takes longer than the > Cucumber threshold ([Link > |https://github.com/L0Lmaker/tinkerpop/runs/7755756716?check_suite_focus=true#step:4:11942]). > We can also see that the slow down is not limited to just the specific > Scenario > ([Link|https://github.com/L0Lmaker/tinkerpop/runs/7755756716?check_suite_focus=true#step:4:11941]). > For reference, these are the usual runtimes for the same Steps respectively, > but on a different workflow run > (['connectedComponent()'|https://github.com/L0Lmaker/tinkerpop/runs/7755709203?check_suite_focus=true#step:4:11861] > and > ['dedup()'|[https://github.com/L0Lmaker/tinkerpop/runs/7755709203?check_suite_focus=true#step:4:11862]]). > This ticket is to track the investigation of the slowdown on Gremlin Server > on Windows in GitHub Actions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2780) Floating Javascript Integration Test Promise Error for GitHub Actions on windows
[
https://issues.apache.org/jira/browse/TINKERPOP-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2780.
---
Resolution: Invalid
Windows GHA are disabled until GitHub enables Linux images on Windows servers.
> Floating Javascript Integration Test Promise Error for GitHub Actions on
> windows
>
>
> Key: TINKERPOP-2780
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2780
> Project: TinkerPop
> Issue Type: Improvement
> Components: build-release, javascript
>Affects Versions: 3.5.4
>Reporter: Yang Xia
>Priority: Minor
>
> We see occasional GHA failures on Windows involving to timeout errors with
> Promises, such as one below:
> {code:java}
> [INFO] 1 failing
> [INFO]
> [INFO] 1) Client
> [INFO] #submit()
> [INFO] should send bytecode:
> [INFO] Error: Timeout of 5000ms exceeded. For async tests and hooks,
> ensure "done()" is called; if returning a Promise, ensure it resolves.
> (D:\a\tinkerpop\tinkerpop\gremlin-javascript\src\main\javascript\gremlin-javascript\test\integration\client-tests.js){code}
> May be related with errors in ConnectedComponents
> https://issues.apache.org/jira/browse/TINKERPOP-2779
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2770) Some Tinkerpop Modules do not build from non-root subfolders
[ https://issues.apache.org/jira/browse/TINKERPOP-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia closed TINKERPOP-2770. --- Resolution: Not A Problem It is recommended to run everything from root, or use `-pl` to execute submodules. > Some Tinkerpop Modules do not build from non-root subfolders > > > Key: TINKERPOP-2770 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2770 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.5.3 > Environment: Windows and Linux >Reporter: Rithin Kumar R S >Priority: Minor > > When maven commands are run from Tinkerpop root, all modules are able to run > the commands successfully, but when they are run from any of the sub-modules, > there are some modules that will not run successfully. > [Here|https://github.com/apache/tinkerpop/pull/1739#pullrequestreview-1023065425] > is an example. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2760) Pending Windows Tasks post Windows Build fixes
[
https://issues.apache.org/jira/browse/TINKERPOP-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2760.
---
Resolution: Invalid
GHA for Windows is disabled due to Linux image not able to run on Windows
Server in GitHub. Closing.
> Pending Windows Tasks post Windows Build fixes
> --
>
> Key: TINKERPOP-2760
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2760
> Project: TinkerPop
> Issue Type: Improvement
> Components: build-release
>Affects Versions: 3.5.3
> Environment: Windows
>Reporter: Rithin Kumar R S
>Priority: Minor
>
> Some pending tasks post
> [TINKERPOP-2749](https://issues.apache.org/jira/browse/TINKERPOP-2749)
> include:
> * Dotnet has inconsistent GitHub Actions failures for Windows Build
> * Dotnet local build on Windows changes some special characters on some files
> * The Spark {{mvn verify ...}} command defined for the Ubuntu GitHub Actions
> workflow fails on Windows.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2749) Support Windows Build
[ https://issues.apache.org/jira/browse/TINKERPOP-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia closed TINKERPOP-2749. --- Resolution: Fixed Windows build has been enabled to a usable extend. No further action for now as GHA for Windows is disabled due to Linux image not able to run on Windows Server in GitHub. > Support Windows Build > - > > Key: TINKERPOP-2749 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2749 > Project: TinkerPop > Issue Type: Improvement > Components: build-release >Affects Versions: 3.5.3 >Reporter: Lyndon Bauto >Assignee: Lyndon Bauto >Priority: Major > > Currently the Windows build fails due to a number of issues. There are > failures in: > * gremlin-javascript > * gremlin-dotnet-source > * hadoop-gremlin > * spark-gremlin > * gremlint > the hadoop-gremlin and spark-gremlin issues are a little more complex and > will require additional investigation, but for now we can look to resolve the > existing issues and get all other builds working in GitHub actions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2902) Critical security vulnerability in snakeyaml
[ https://issues.apache.org/jira/browse/TINKERPOP-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia closed TINKERPOP-2902. --- Fix Version/s: 3.7.0 3.6.3 3.5.6 Resolution: Fixed > Critical security vulnerability in snakeyaml > > > Key: TINKERPOP-2902 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2902 > Project: TinkerPop > Issue Type: Bug > Components: console, server >Affects Versions: 3.6.2, 3.5.5 >Reporter: Aaron Coady >Priority: Critical > Fix For: 3.7.0, 3.6.3, 3.5.6 > > > This critical security vulnerability was identified in versions of snakeyaml > prior to 2.0 > [https://nvd.nist.gov/vuln/detail/CVE-2022-1471] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2904) Forget to throw GremlinTypeErrorException when using is(predicate) to compare NaN
[
https://issues.apache.org/jira/browse/TINKERPOP-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2904:
Affects Version/s: 3.6.2
(was: 3.5.5)
> Forget to throw GremlinTypeErrorException when using is(predicate) to compare
> NaN
> --
>
> Key: TINKERPOP-2904
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2904
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.2
>Reporter: Miracy Cavendish
>Priority: Critical
>
> By the design of Gremlin, an exception should be thrown when compared with
> NaN.
> However, I found that when using ```is(predicate)``` to compare, the
> exception is always swallowed, and this issue occurs on all GDBs support
> Gremlin, such as "g.inject(Double.NaN).is(gt(3))"
> {code:java}
> public static final GremlinValueComparator COMPARABILITY = new
> GremlinValueComparator() {
> /**
> * Compare two Gremlin value objects per the Comparability semantics.
> Throws type errors for NaN comparison
> * and for cross-type comparison (including nulltype).
> *
> * Use this method for P.lt/lte/gt/gte.
> */
> @Override
> public int compare(final Object f, final Object s) {
> // For Compare, NaN always produces ERROR
> if (eitherAreNaN(f, s))
> throwTypeError();
> // For Compare we do not cross type boundaries, including null
> if (!comparable(f, s))
> throwTypeError();
> // comparable(f, s) assures that type(f) == type(s)
> final Type type = Type.type(f);
> return comparator(type).compare(f, s);
> }
> ... {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2904) Forget to throw GremlinTypeErrorException when using is(predicate) to compare NaN
[
https://issues.apache.org/jira/browse/TINKERPOP-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2904.
---
Resolution: Not A Bug
> Forget to throw GremlinTypeErrorException when using is(predicate) to compare
> NaN
> --
>
> Key: TINKERPOP-2904
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2904
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.2
>Reporter: Miracy Cavendish
>Priority: Critical
>
> By the design of Gremlin, an exception should be thrown when compared with
> NaN.
> However, I found that when using ```is(predicate)``` to compare, the
> exception is always swallowed, and this issue occurs on all GDBs support
> Gremlin, such as "g.inject(Double.NaN).is(gt(3))"
> {code:java}
> public static final GremlinValueComparator COMPARABILITY = new
> GremlinValueComparator() {
> /**
> * Compare two Gremlin value objects per the Comparability semantics.
> Throws type errors for NaN comparison
> * and for cross-type comparison (including nulltype).
> *
> * Use this method for P.lt/lte/gt/gte.
> */
> @Override
> public int compare(final Object f, final Object s) {
> // For Compare, NaN always produces ERROR
> if (eitherAreNaN(f, s))
> throwTypeError();
> // For Compare we do not cross type boundaries, including null
> if (!comparable(f, s))
> throwTypeError();
> // comparable(f, s) assures that type(f) == type(s)
> final Type type = Type.type(f);
> return comparator(type).compare(f, s);
> }
> ... {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2918) Utils.GenerateUserAgent assumes Gremlin.Net.dll to be present when, in some environments, it is not.
[
https://issues.apache.org/jira/browse/TINKERPOP-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2918.
---
Fix Version/s: 3.7.0
3.6.3
3.5.6
Resolution: Fixed
> Utils.GenerateUserAgent assumes Gremlin.Net.dll to be present when, in some
> environments, it is not.
>
>
> Key: TINKERPOP-2918
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2918
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.6.2, 3.5.5
>Reporter: Daniel C. Weber
>Priority: Blocker
> Fix For: 3.7.0, 3.6.3, 3.5.6
>
>
> The dotnet driver in v3.6.2 adds the ability to add a user agent to the
> request.
> To get the user agent name, Gremlin.Net.Process.Utils.GenerateUserAgent uses
> AssemblyName.GetAssemblyName("Gremlin.Net.dll") (see
> [here|https://github.com/apache/tinkerpop/blob/125e5bf4560546c9727dd25ff4d590f34c7d625b/gremlin-dotnet/src/Gremlin.Net/Process/Utils.cs#L81])
> Because the dll is referenced in a relative manner, in some environments
> (Visual studio debugging and Docker deployment for me), this results in a
> FileNotFoundException. In my specific local case, the path prefixed is the
> path where the csproj is.
> However, it works in a different project (also VS locally). I have no idea
> yet why. Also, I would file a pull request that would just use
> GetExecutingAssembly() instead of AssemblyName.GetAssemblyName (because the
> executing code is in that specific dll), but there's probably a reason for it
> not being used. Then again, using GetExecutingAssembly for the application
> name seems odd, was that supposed to be GetEntryAssembly?
> Will happily provide more insight and code.
> cc: [~Florian Hockmann]
> Edit: Proposed change in https://github.com/apache/tinkerpop/pull/2005
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (TINKERPOP-2911) CountStrategy converts count().is(0) wrongly under ConnectiveStrategy
[
https://issues.apache.org/jira/browse/TINKERPOP-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia reassigned TINKERPOP-2911:
---
Assignee: Ken Hu
> CountStrategy converts count().is(0) wrongly under ConnectiveStrategy
> -
>
> Key: TINKERPOP-2911
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2911
> Project: TinkerPop
> Issue Type: Bug
> Components: process, test-suite
>Affects Versions: 3.4.13, 3.6.2, 3.5.5
>Reporter: Norio Akagi
>Assignee: Ken Hu
>Priority: Critical
>
> A query example:
> {noformat}
> // 2nd branch is just a dummy, and assuming we don't have an edge with label
> "none"
> g.V().where(or(out("none").out().count().is(0), has("none"))) {noformat}
> Here, CountStrategy tries to convert {{count().is(0)}} to {{not(...).}}
> However, when it is under ConnectiveStrategy, it tries to read Steps from
> tail to beginning and include Steps until it finds the first non-filter Step.
> So in this case, it becomes
> {noformat}
> [GraphStep(vertex,[]), OrStep([[VertexStep(OUT,[none],vertex),
> NotStep([VertexStep(OUT,edge)])],
> [TraversalFilterStep([NeptunePropertiesStep([none],property)])]])]{noformat}
> So the first out("none") is outside of NotStep, whereas the 2nd out() is
> inside.
> The original intention of this query is that the 1st branch under {{or}}
> should return {{true}} in the first branch, because there is no such edge
> with the label {{"none"}} and {{{}count = 0{}}}.
> However this optimization returns the opposite result. Because the first
> {{VertexStep(OUT,[none],vertex)}} is now outside of {{{}NotStep{}}}, the 1st
> branch returns {{{}false{}}}.
> It seems this logic was intentionally introduced while back ago
> [https://github.com/apache/tinkerpop/commit/36bd2a2447529371d950b2df6de36ea49957ab55]
> So just reverting this change may not be the permanent fix. We should
> investigate what should be the correct behavior for CountStrategy to apply
> under ConnectivityStep.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2911) CountStrategy converts count().is(0) wrongly under ConnectiveStrategy
[
https://issues.apache.org/jira/browse/TINKERPOP-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2911.
---
Fix Version/s: 3.7.0
3.6.3
3.5.6
Resolution: Fixed
> CountStrategy converts count().is(0) wrongly under ConnectiveStrategy
> -
>
> Key: TINKERPOP-2911
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2911
> Project: TinkerPop
> Issue Type: Bug
> Components: process, test-suite
>Affects Versions: 3.4.13, 3.6.2, 3.5.5
>Reporter: Norio Akagi
>Assignee: Ken Hu
>Priority: Critical
> Fix For: 3.7.0, 3.6.3, 3.5.6
>
>
> A query example:
> {noformat}
> // 2nd branch is just a dummy, and assuming we don't have an edge with label
> "none"
> g.V().where(or(out("none").out().count().is(0), has("none"))) {noformat}
> Here, CountStrategy tries to convert {{count().is(0)}} to {{not(...).}}
> However, when it is under ConnectiveStrategy, it tries to read Steps from
> tail to beginning and include Steps until it finds the first non-filter Step.
> So in this case, it becomes
> {noformat}
> [GraphStep(vertex,[]), OrStep([[VertexStep(OUT,[none],vertex),
> NotStep([VertexStep(OUT,edge)])],
> [TraversalFilterStep([NeptunePropertiesStep([none],property)])]])]{noformat}
> So the first out("none") is outside of NotStep, whereas the 2nd out() is
> inside.
> The original intention of this query is that the 1st branch under {{or}}
> should return {{true}} in the first branch, because there is no such edge
> with the label {{"none"}} and {{{}count = 0{}}}.
> However this optimization returns the opposite result. Because the first
> {{VertexStep(OUT,[none],vertex)}} is now outside of {{{}NotStep{}}}, the 1st
> branch returns {{{}false{}}}.
> It seems this logic was intentionally introduced while back ago
> [https://github.com/apache/tinkerpop/commit/36bd2a2447529371d950b2df6de36ea49957ab55]
> So just reverting this change may not be the permanent fix. We should
> investigate what should be the correct behavior for CountStrategy to apply
> under ConnectivityStep.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (TINKERPOP-2899) SampleGlobalStep samples inefficiently with TraverserSet running into hash collisions
[
https://issues.apache.org/jira/browse/TINKERPOP-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia reassigned TINKERPOP-2899:
---
Assignee: Ken Hu
> SampleGlobalStep samples inefficiently with TraverserSet running into hash
> collisions
> -
>
> Key: TINKERPOP-2899
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2899
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.5.5
>Reporter: steigma
>Assignee: Ken Hu
>Priority: Critical
>
> For some queries, the SampleGlobalStep can take a huge amount of time. For
> example, on a Gremlin variant of the LUBM dataset and the following query
> {code:java}
> g.V().hasLabel('Course').sample(1000).in('teacherOf').path() {code}
> the sample step has 108000 traversers as input, but requires over 200
> seconds. More precisely: Collecting all traversers from previous step with
> processAllStarts (see
> [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/SampleGlobalStep.java#L83-L85])
> takes 108344 ms, thereby createProjectedTraverser: 1416 ms,
> traverserSet::add: 106238 ms. The barrierConsumer finished sampling in 121088
> ms, whereby the loop was executed 53356191 times.
>
> There seem to be two issues:
>
> 1. There are many hash collisions when adding the projected traverser to the
> map in the TraverserSet (see
> [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/traverser/util/TraverserSet.java#L91],
> called from the prcessAllStarts
> ([https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/SampleGlobalStep.java#L84]).
> For example, for
> v[[http://www.Department0.University15.edu/Course0|http://www.department0.university15.edu/Course0]],
> we compute the hash code via {{{}super.hashCode() ^
> this.path.hashCode(){}}}, which is {{-2056934079 - -2056934048 = 33}}
> (basically the hash code of the id string XOR the hash code of the path,
> i.e., singleton list of the id string). This leads to many very similar hash
> codes, e.g.,
> {code:java}
> 33
> 103
> 33
> 227
> 33
> 111
> 33
> 995
> 33
> 103
> 33
> 31
> 481
> 39
> 97
> 35
> 225
> 47
> 97
> 35
> 993
> 39
> 225
> 99
> 33
> ... {code}
>
> 2. The sampling algorithm seems to be extremely inefficient (often running
> the loop again without adding a new sample). It is not completely clear why
> it was written that way (lack of documentation), but it may have been
> necessary to correctly handling these “bulks”.
>
> The second issue could potentially be addressed by checking whether all
> traversers have the same weight
> ([https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/SampleGlobalStep.java#L96]),
> which seems to be the case in this example, and then use a more efficient
> sampling approach that just samples a corresponding number of integers
> between 0 and the number of traversers in the sample set and store these
> numbers in a set (with count). With that we can iterate through the
> traverserSet and use the corresponding traversers if we have it sampled.
>
> For the first issue, we can probably just avoid putting them in the
> TraverserSet and use an ArrayList instead. Then we could also directly sample
> from this ArrayList, which may even make this bulk handling superfluous?
>
> There is however also an "efficient" rewrite of this query using fold, local
> sample and unfold:
> {code:java}
> g.V().hasLabel('Course').fold().sample(Scope.local,1000).unfold().in('teacherOf').path()
> {code}
>
> The general question is, however, whether the {color:#1d1c1d}TraverserSet can
> lead to hash collisions in other places. Maybe it makes sense to reevaluate
> the usage of this TraverserSet{color} and, if useful/required, switch to
> something more efficient time-wise (which could then require a bit more
> memory).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2899) SampleGlobalStep samples inefficiently with TraverserSet running into hash collisions
[
https://issues.apache.org/jira/browse/TINKERPOP-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2899.
---
Fix Version/s: 3.7.0
3.6.3
3.5.6
Resolution: Fixed
> SampleGlobalStep samples inefficiently with TraverserSet running into hash
> collisions
> -
>
> Key: TINKERPOP-2899
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2899
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.5.5
>Reporter: steigma
>Assignee: Ken Hu
>Priority: Critical
> Fix For: 3.7.0, 3.6.3, 3.5.6
>
>
> For some queries, the SampleGlobalStep can take a huge amount of time. For
> example, on a Gremlin variant of the LUBM dataset and the following query
> {code:java}
> g.V().hasLabel('Course').sample(1000).in('teacherOf').path() {code}
> the sample step has 108000 traversers as input, but requires over 200
> seconds. More precisely: Collecting all traversers from previous step with
> processAllStarts (see
> [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/SampleGlobalStep.java#L83-L85])
> takes 108344 ms, thereby createProjectedTraverser: 1416 ms,
> traverserSet::add: 106238 ms. The barrierConsumer finished sampling in 121088
> ms, whereby the loop was executed 53356191 times.
>
> There seem to be two issues:
>
> 1. There are many hash collisions when adding the projected traverser to the
> map in the TraverserSet (see
> [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/traverser/util/TraverserSet.java#L91],
> called from the prcessAllStarts
> ([https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/SampleGlobalStep.java#L84]).
> For example, for
> v[[http://www.Department0.University15.edu/Course0|http://www.department0.university15.edu/Course0]],
> we compute the hash code via {{{}super.hashCode() ^
> this.path.hashCode(){}}}, which is {{-2056934079 - -2056934048 = 33}}
> (basically the hash code of the id string XOR the hash code of the path,
> i.e., singleton list of the id string). This leads to many very similar hash
> codes, e.g.,
> {code:java}
> 33
> 103
> 33
> 227
> 33
> 111
> 33
> 995
> 33
> 103
> 33
> 31
> 481
> 39
> 97
> 35
> 225
> 47
> 97
> 35
> 993
> 39
> 225
> 99
> 33
> ... {code}
>
> 2. The sampling algorithm seems to be extremely inefficient (often running
> the loop again without adding a new sample). It is not completely clear why
> it was written that way (lack of documentation), but it may have been
> necessary to correctly handling these “bulks”.
>
> The second issue could potentially be addressed by checking whether all
> traversers have the same weight
> ([https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/SampleGlobalStep.java#L96]),
> which seems to be the case in this example, and then use a more efficient
> sampling approach that just samples a corresponding number of integers
> between 0 and the number of traversers in the sample set and store these
> numbers in a set (with count). With that we can iterate through the
> traverserSet and use the corresponding traversers if we have it sampled.
>
> For the first issue, we can probably just avoid putting them in the
> TraverserSet and use an ArrayList instead. Then we could also directly sample
> from this ArrayList, which may even make this bulk handling superfluous?
>
> There is however also an "efficient" rewrite of this query using fold, local
> sample and unfold:
> {code:java}
> g.V().hasLabel('Course').fold().sample(Scope.local,1000).unfold().in('teacherOf').path()
> {code}
>
> The general question is, however, whether the {color:#1d1c1d}TraverserSet can
> lead to hash collisions in other places. Maybe it makes sense to reevaluate
> the usage of this TraverserSet{color} and, if useful/required, switch to
> something more efficient time-wise (which could then require a bit more
> memory).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2926) Gremlin-Java > An UnsupportedOperationException occurs on calling next() after a merge step with the option step modulator if the element does not exist
[
https://issues.apache.org/jira/browse/TINKERPOP-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2926:
Priority: Blocker (was: Major)
> Gremlin-Java > An UnsupportedOperationException occurs on calling next()
> after a merge step with the option step modulator if the element does not
> exist
>
>
> Key: TINKERPOP-2926
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2926
> Project: TinkerPop
> Issue Type: Bug
> Components: driver
>Affects Versions: 3.6.2
>Reporter: Andrew Kirk
>Priority: Blocker
> Attachments: MergeTestApp.java
>
>
> Using Gremlin-Java, when the option step modulator is used in combination
> with a merge step, an `UnsupportedOperationException` is thrown upon calling
> `next()` if the specified element does not already exist.
> Using an example from the docs, the following construct works fine in the
> console if the element does not already exist:
> {code:groovy}
> gremlin> g.mergeV([(T.id):300]).
> option(Merge.onCreate,[(T.label):'Dog', name:'Toby', age:10]).
> option(Merge.onMatch,[age:11])
> {code}
> But, if we try to do the same thing in Java, we'll get an exception:
> {code:java}
> g.mergeV(Map.of(T.id, 300))
> .option(
> Merge.onCreate,
> Map.of(
> T.label, "Dog",
> "name", "Toby",
> "age", 10
> )
> )
> .option(
> Merge.onMatch,
> Map.of("age", 11)
> )
> .next();
> {code}
> Exception:
> {noformat}
> Exception in thread "main" java.lang.UnsupportedOperationException
> at
> java.base/java.util.ImmutableCollections.uoe(ImmutableCollections.java:142)
> at
> java.base/java.util.ImmutableCollections$AbstractImmutableMap.putAll(ImmutableCollections.java:1073)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.MergeVertexStep.onCreateMap(MergeVertexStep.java:205)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.MergeVertexStep.flatMap(MergeVertexStep.java:168)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.FlatMapStep.processNextStart(FlatMapStep.java:49)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.MergeStep.processNextStart(MergeStep.java:165)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:135)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:40)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.next(DefaultTraversal.java:249)
> at
> io.integralla.tinkerpop.poc.MergeWithOption.main(MergeWithOption.java:44)
> {noformat}
> If the element is first added (via an add or merge step), the merge with
> option works as expected.
> A full example is provided in the attached MergeTestApp.java
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-2929) Introduce new marker interfaces to identify whether a step can perform write or delete or both
Yang Xia created TINKERPOP-2929:
---
Summary: Introduce new marker interfaces to identify whether a
step can perform write or delete or both
Key: TINKERPOP-2929
URL: https://issues.apache.org/jira/browse/TINKERPOP-2929
Project: TinkerPop
Issue Type: Improvement
Components: process
Affects Versions: 3.6.2
Reporter: Yang Xia
As described in the PR [https://github.com/apache/tinkerpop/pull/2025]
{quote}Currently all steps that can change graph data implements Mutating
interface. However, there is no straight forward way to know whether the step
can perform write or delete or both on the graph data. This PR introduces two
new marker interfaces {{Writing}} and {{Deleting}} defining whether step can
perform write or delete or both.
In addition to this, this PR creates a static map of Traversal steps that shall
be added for a given operator. Both can be combined to assess whether a given
query can perform read or write or delete or any combination of these before
query execution.
{quote}
For details see dev list post:
[https://lists.apache.org/thread/433bc2qr5owvjcfn0tbj55sgz95zg6df]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2929) Introduce new marker interfaces to identify whether a step can perform write or delete or both
[
https://issues.apache.org/jira/browse/TINKERPOP-2929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2929.
---
Fix Version/s: 3.7.0
3.6.3
Assignee: Yang Xia
Resolution: Fixed
> Introduce new marker interfaces to identify whether a step can perform write
> or delete or both
> --
>
> Key: TINKERPOP-2929
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2929
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.6.2
>Reporter: Yang Xia
>Assignee: Yang Xia
>Priority: Major
> Fix For: 3.7.0, 3.6.3
>
>
> As described in the PR [https://github.com/apache/tinkerpop/pull/2025]
> {quote}Currently all steps that can change graph data implements Mutating
> interface. However, there is no straight forward way to know whether the step
> can perform write or delete or both on the graph data. This PR introduces two
> new marker interfaces {{Writing}} and {{Deleting}} defining whether step can
> perform write or delete or both.
> In addition to this, this PR creates a static map of Traversal steps that
> shall be added for a given operator. Both can be combined to assess whether a
> given query can perform read or write or delete or any combination of these
> before query execution.
> {quote}
> For details see dev list post:
> [https://lists.apache.org/thread/433bc2qr5owvjcfn0tbj55sgz95zg6df]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2929) Introduce new marker interfaces to identify whether a step can perform write or delete or both
[
https://issues.apache.org/jira/browse/TINKERPOP-2929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714764#comment-17714764
]
Yang Xia commented on TINKERPOP-2929:
-
[https://github.com/apache/tinkerpop/pull/2025] is merged.
> Introduce new marker interfaces to identify whether a step can perform write
> or delete or both
> --
>
> Key: TINKERPOP-2929
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2929
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.6.2
>Reporter: Yang Xia
>Assignee: Yang Xia
>Priority: Major
> Fix For: 3.7.0, 3.6.3
>
>
> As described in the PR [https://github.com/apache/tinkerpop/pull/2025]
> {quote}Currently all steps that can change graph data implements Mutating
> interface. However, there is no straight forward way to know whether the step
> can perform write or delete or both on the graph data. This PR introduces two
> new marker interfaces {{Writing}} and {{Deleting}} defining whether step can
> perform write or delete or both.
> In addition to this, this PR creates a static map of Traversal steps that
> shall be added for a given operator. Both can be combined to assess whether a
> given query can perform read or write or delete or any combination of these
> before query execution.
> {quote}
> For details see dev list post:
> [https://lists.apache.org/thread/433bc2qr5owvjcfn0tbj55sgz95zg6df]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
