[jira] [Updated] (TINKERPOP-1325) Query results with lambda step not serializable in OLAP
[
https://issues.apache.org/jira/browse/TINKERPOP-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1325:
Affects Version/s: (was: 3.2.1)
3.2.0-incubating
Component/s: (was: tinkergraph)
server
hadoop
> Query results with lambda step not serializable in OLAP
> ---
>
> Key: TINKERPOP-1325
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1325
> Project: TinkerPop
> Issue Type: Bug
> Components: hadoop, server
>Affects Versions: 3.2.0-incubating
> Environment: OSX 10.11.5
> apache-gremlin-console-3.2.1
>Reporter: Sergey Gmyzov
>
> Query with lambda step fails in OLAP mode:
> {code}
> gremlin> :remote config alias g ds232.a
> ==>g=ds232.a
> gremlin> :>
> schema.config().option('graph.traversal_sources.g.restrict_lambda').set(false);
> ==>null
> gremlin> :>
> schema.config().option('graph.traversal_sources.a.restrict_lambda').set(false);
> ==>null
> gremlin> :> graph.tx().commit();
> ==>null
> gremlin> :> g.V().has("movieId","m267").map{it.get().value("title")};
> org.apache.spark.SparkException: Task not serializable
> Display stack trace? [yN] y
> org.apache.tinkerpop.gremlin.groovy.plugin.RemoteException:
> org.apache.spark.SparkException: Task not serializable
> at
> org.apache.tinkerpop.gremlin.console.groovy.plugin.DriverRemoteAcceptor.submit(DriverRemoteAcceptor.java:156)
> at
> org.apache.tinkerpop.gremlin.console.commands.SubmitCommand.execute(SubmitCommand.groovy:41)
> at org.codehaus.groovy.tools.shell.Shell.execute(Shell.groovy:104)
> at
> org.codehaus.groovy.tools.shell.Groovysh.super$2$execute(Groovysh.groovy)
> at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1212)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
> at
> org.codehaus.groovy.tools.shell.Groovysh.executeCommand(Groovysh.groovy:259)
> at org.codehaus.groovy.tools.shell.Groovysh.execute(Groovysh.groovy:158)
> at
> org.apache.tinkerpop.gremlin.console.GremlinGroovysh.super$3$execute(GremlinGroovysh.groovy)
> at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1212)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
> at
> org.apache.tinkerpop.gremlin.console.GremlinGroovysh.execute(GremlinGroovysh.groovy:63)
> at org.codehaus.groovy.tools.shell.Shell.leftShift(Shell.groovy:122)
> at
> org.codehaus.groovy.tools.shell.ShellRunner.work(ShellRunner.groovy:95)
> at
> org.codehaus.groovy.tools.shell.InteractiveShellRunner.super$2$work(InteractiveShellRunner.groovy)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1212)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuper0(ScriptBytecodeAdapter.java:152)
> at
> org.codehaus.groovy.tools.shell.InteractiveShellRunner.work(InteractiveShellRunner.groovy:124)
> at
> org.codehaus.groovy.tools.shell.ShellRunner.run(ShellRunner.groovy:59)
> at
> org.codehaus.groovy.tools.shell.InteractiveShellRunner.super$2$run(InteractiveShellRunner.groovy)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
[jira] [Updated] (TINKERPOP-1235) Remove deprecated ProcessPerformanceSuite and TraversalPerformanceTest
[ https://issues.apache.org/jira/browse/TINKERPOP-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1235: Description: The JUnit Benchmark based performance tests were deprecated for 3.2.0-incubating given: TINKERPOP-1016 and TINKERPOP-1273 (was: The JUnit Benchmark based performance tests were deprecated for 3.2.0-incubating given: TINKERPOP-1016) > Remove deprecated ProcessPerformanceSuite and TraversalPerformanceTest > -- > > Key: TINKERPOP-1235 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1235 > Project: TinkerPop > Issue Type: Improvement > Components: test-suite >Affects Versions: 3.2.0-incubating >Reporter: Ted Wilmes >Priority: Minor > Labels: breaking, deprecation > > The JUnit Benchmark based performance tests were deprecated for > 3.2.0-incubating given: TINKERPOP-1016 and TINKERPOP-1273 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TINKERPOP-1310) Allow OLAP to return properties as Detached
stephen mallette created TINKERPOP-1310: --- Summary: Allow OLAP to return properties as Detached Key: TINKERPOP-1310 URL: https://issues.apache.org/jira/browse/TINKERPOP-1310 Project: TinkerPop Issue Type: Improvement Components: process Affects Versions: 3.2.0-incubating Reporter: stephen mallette Assignee: Marko A. Rodriguez Fix For: 3.2.1 Make it possible for an OLAP TraversalSource to have graph elements be returned with properties. Currently they return a "reference" vertex (which excludes all properties), but should have the option to be returned as a "detached" vertex (which includes all properties) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1332) Improve .explain() Dialogue
[
https://issues.apache.org/jira/browse/TINKERPOP-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15331811#comment-15331811
]
stephen mallette commented on TINKERPOP-1332:
-
I sort of agree with [~rjbriody] about pushing formatting into the output.
Maybe we should do a {{prettyPrint()}} method on {{TraversalExplanation}} that
does some formatting or something and leave {{toString()}} alone. In the
console we could probably detect a {{TraversalExplanation}} being eval'd out in
the console and then call the {{prettyPrint()}} (i think). Perhaps that would
solve the problem?
> Improve .explain() Dialogue
>
>
> Key: TINKERPOP-1332
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1332
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Russell Alexander Spitzer
>Assignee: Marko A. Rodriguez
>Priority: Minor
>
> Currently the output of explain gives you a long list of strategies but no
> details about their application
> {code}
> ==>Traversal Explanation
>
> Original Traversal [GraphStep(vertex,[]), CountGlobalStep]
> HaltedTraverserStrategy [D] [GraphStep(vertex,[]), CountGlobalStep]
> ConnectiveStrategy [D] [GraphStep(vertex,[]), CountGlobalStep]
> VertexProgramStrategy[D]
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]),
> ComputerResultStep]
> OrderLimitStrategy [O]
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]),
> ComputerResultStep]
> IdentityRemovalStrategy [O]
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]),
> ComputerResultStep]
> FilterRankingStrategy[O]
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]),
> ComputerResultStep]
> IncidentToAdjacentStrategy [O]
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]),
> ComputerResultStep]
> RangeByIsCountStrategy [O]
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]),
> ComputerResultStep]
> AdjacentToIncidentStrategy [O]
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]),
> ComputerResultStep]
> MatchPredicateStrategy [O]
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]),
> ComputerResultStep]
> GraphFilterStrategy [O]
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]),
> ComputerResultStep]
> PathProcessorStrategy[O]
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]),
> ComputerResultStep]
> SparkInterceptorStrategy [P]
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]),
> ComputerResultStep]
> SparkSingleIterationStrategy [P]
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]),
> ComputerResultStep]
> ProfileStrategy [F]
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]),
> ComputerResultStep]
> LambdaRestrictionStrategy[V]
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]),
> ComputerResultStep]
> ComputerVerificationStrategy [V]
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]),
> ComputerResultStep]
> StandardVerificationStrategy [V]
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]),
> ComputerResultStep]
> Final Traversal
> [TraversalVertexProgramStep([GraphStep(vertex,[]), CountGlobalStep]),
> ComputerResultStep]
> {code}
> It would be helpful if filter strategies for example would list the filters
> used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1221) Make sure HadoopPools is intialized in all the right spots of Giraph/Spark.
[ https://issues.apache.org/jira/browse/TINKERPOP-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1221: Issue Type: Improvement (was: Bug) > Make sure HadoopPools is intialized in all the right spots of Giraph/Spark. > --- > > Key: TINKERPOP-1221 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1221 > Project: TinkerPop > Issue Type: Improvement > Components: hadoop >Affects Versions: 3.1.1-incubating >Reporter: Marko A. Rodriguez > > ...yea, all the right spots. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1257) Bad SackTest variable use.
[
https://issues.apache.org/jira/browse/TINKERPOP-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1257.
---
Resolution: Fixed
Assignee: stephen mallette
Fixed via CTR on
https://github.com/apache/incubator-tinkerpop/commit/63e849c0057a7c313eb2bd33938e1a260c206bf7
> Bad SackTest variable use.
> --
>
> Key: TINKERPOP-1257
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1257
> Project: TinkerPop
> Issue Type: Bug
> Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
> Fix For: 3.1.3, 3.2.1
>
>
> From [~pietermartin-tinkerpop]
> {code}
> @Override
>
>
>
> public Traversal
> get_g_withSackX1_sumX_VX1X_localXoutXknowsX_barrierXnormSackXX_inXknowsX_barrier_sack(
>final Object v1Id) {
> TraversalScriptHelper.compute("g.withSack(1.0d,sum).V(${v1Id}).local(out('knows').barrier(normSack)).in('knows').barrier.sack",
> g, "v1Id", v1Id)
> }
> {code}
> The ${v1Id} should be just v1Id not ${v1Id}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TINKERPOP-1316) Remove deprecated constructor from GryoMessageSerializers
stephen mallette created TINKERPOP-1316: --- Summary: Remove deprecated constructor from GryoMessageSerializers Key: TINKERPOP-1316 URL: https://issues.apache.org/jira/browse/TINKERPOP-1316 Project: TinkerPop Issue Type: Improvement Components: driver Affects Versions: 3.2.1 Reporter: stephen mallette Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1196) Calls to Result.one() might block indefinitely
[ https://issues.apache.org/jira/browse/TINKERPOP-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1196. --- Resolution: Fixed Fix Version/s: 3.2.1 This PR was merged a while ago - forgot to close the issue. > Calls to Result.one() might block indefinitely > -- > > Key: TINKERPOP-1196 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1196 > Project: TinkerPop > Issue Type: Bug > Components: driver >Affects Versions: 3.1.1-incubating >Reporter: stephen mallette >Assignee: stephen mallette > Fix For: 3.1.3, 3.2.1 > > > There are no reproduction steps for this but it does seem to happen from on > very rare occasion for some unknown reason. Need to investigate more. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1139) [Neo4JGraph] GraphTraversal with SubgraphStrategy removes addLabelStep (as("b"))
[
https://issues.apache.org/jira/browse/TINKERPOP-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15333632#comment-15333632
]
stephen mallette commented on TINKERPOP-1139:
-
[~mm33] thanks for reporting this - it will be fixed in the 3.1.3 and 3.2.1
releases.
> [Neo4JGraph] GraphTraversal with SubgraphStrategy removes addLabelStep
> (as("b"))
>
>
> Key: TINKERPOP-1139
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1139
> Project: TinkerPop
> Issue Type: Bug
> Components: neo4j
>Affects Versions: 3.1.0-incubating
>Reporter: Martijn Maas
>Assignee: stephen mallette
> Fix For: 3.1.3, 3.2.1
>
>
> I am using the Neo4jGraph with the following SubgraphStrategy:
> {code}
> SubgraphStrategy.build().vertexCriterion(has("isLatest", true)).create();
> {code}
> I have 2 traversals. This one working works:
> {code}
> Map languageCounts =
> searchResult.as("a").inE("isCreatedBy").outV().outE("hasWorkLanguage").inV().as("b").dedup("a",
> "b")
> .has("wwlanguage_name").groupCount()
> .by("wwlanguage_name").next();
> {code}
> This translates to:
> {code}
> [Neo4jGraphStep([],vertex)@[a],
> TraversalFilterStep([HasStep([isLatest.eq(true)])]),
> VertexStep(IN,[isCreatedBy],edge),
> TraversalFilterStep([AndStep([[EdgeVertexStep(IN),
> TraversalFilterStep([HasStep([isLatest.eq(true)])]),
> TraversalFilterStep([HasStep([isLatest.eq(true)])])], [EdgeVertexStep(OUT),
> TraversalFilterStep([HasStep([isLatest.eq(true)])]),
> TraversalFilterStep([HasStep([isLatest.eq(true)])])]])]),
> EdgeVertexStep(OUT), TraversalFilterStep([HasStep([isLatest.eq(true)])]),
> VertexStep(OUT,[hasWorkLanguage],edge),
> TraversalFilterStep([AndStep([[EdgeVertexStep(IN),
> TraversalFilterStep([HasStep([isLatest.eq(true)])]),
> TraversalFilterStep([HasStep([isLatest.eq(true)])])], [EdgeVertexStep(OUT),
> TraversalFilterStep([HasStep([isLatest.eq(true)])]),
> TraversalFilterStep([HasStep([isLatest.eq(true)])])]])]),
> EdgeVertexStep(IN)@[b], TraversalFilterStep([HasStep([isLatest.eq(true)])]),
> TraversalFilterStep([PropertiesStep([wwlanguage_name],property)]),
> DedupGlobalStep([a, b]), GroupCountStep(value(wwlanguage_name))]
> {code}
> This one fails:
> {code}
> Map languageCounts =
> searchResult.as("a").in("isCreatedBy").out("hasWorkLanguage").as("b")
>.dedup("a",
> "b").has("wwlanguage_name")
> .groupCount().by("wwlanguage_name").next();
> {code}
> This translates to:
> {code}
> [Neo4jGraphStep([],vertex)@[a],
> TraversalFilterStep([HasStep([isLatest.eq(true)])]),
> VertexStep(IN,[isCreatedBy],edge),
> TraversalFilterStep([AndStep([[EdgeVertexStep(IN),
> TraversalFilterStep([HasStep([isLatest.eq(true)])]),
> TraversalFilterStep([HasStep([isLatest.eq(true)])])], [EdgeVertexStep(OUT),
> TraversalFilterStep([HasStep([isLatest.eq(true)])]),
> TraversalFilterStep([HasStep([isLatest.eq(true)])])]])]),
> EdgeVertexStep(OUT), TraversalFilterStep([HasStep([isLatest.eq(true)])]),
> VertexStep(OUT,[hasWorkLanguage],edge),
> TraversalFilterStep([AndStep([[EdgeVertexStep(IN),
> TraversalFilterStep([HasStep([isLatest.eq(true)])]),
> TraversalFilterStep([HasStep([isLatest.eq(true)])])], [EdgeVertexStep(OUT),
> TraversalFilterStep([HasStep([isLatest.eq(true)])]),
> TraversalFilterStep([HasStep([isLatest.eq(true)])])]])]), EdgeVertexStep(IN),
> TraversalFilterStep([HasStep([isLatest.eq(true)])]),
> TraversalFilterStep([PropertiesStep([wwlanguage_name],property)]),
> DedupGlobalStep([a, b]), GroupCountStep(value(wwlanguage_name))]
> {code}
> The failing query misses the '@[b]' of the last EdgeVertexStep(IN).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1301) Provide Javadoc for ScriptInput/OutputFormat's
[ https://issues.apache.org/jira/browse/TINKERPOP-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1301. --- Resolution: Done Assignee: stephen mallette Fix Version/s: 3.2.1 3.1.3 > Provide Javadoc for ScriptInput/OutputFormat's > -- > > Key: TINKERPOP-1301 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1301 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Affects Versions: 3.2.0-incubating >Reporter: Lewis John McGibbney >Assignee: stephen mallette >Priority: Minor > Fix For: 3.1.3, 3.2.1 > > > Right now > [ScriptInputFormat|http://tinkerpop.apache.org/javadocs/3.2.1-SNAPSHOT/full/index.html?org/apache/tinkerpop/gremlin/hadoop/structure/io/script/ScriptInputFormat.html] > and > [ScriptOutputFormat|http://tinkerpop.apache.org/javadocs/3.2.1-SNAPSHOT/full/index.html?org/apache/tinkerpop/gremlin/hadoop/structure/io/script/ScriptOutputFormat.html] > are not documented. Descriptions are however present over on some old > [TitanDB > documentation|http://s3.thinkaurelius.com/docs/titan/0.5.0/script-io-format.html] > which can be used to provide Javadoc level documentation for developers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TINKERPOP-939) Neo4jGraph should support HighAvailability (Neo4jHA).
[
https://issues.apache.org/jira/browse/TINKERPOP-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette reassigned TINKERPOP-939:
--
Assignee: stephen mallette (was: Daniel Kuppitz)
> Neo4jGraph should support HighAvailability (Neo4jHA).
> -
>
> Key: TINKERPOP-939
> URL: https://issues.apache.org/jira/browse/TINKERPOP-939
> Project: TinkerPop
> Issue Type: Improvement
> Components: neo4j
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
> Fix For: 3.1.3
>
>
> We should support Neo4j HA in the {{Neo4jGraph}} distribution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1063) TinkerGraph performance enhancements
[ https://issues.apache.org/jira/browse/TINKERPOP-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15334518#comment-15334518 ] stephen mallette commented on TINKERPOP-1063: - Ended up implementing the latter in the comment above - tests pass now. > TinkerGraph performance enhancements > > > Key: TINKERPOP-1063 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1063 > Project: TinkerPop > Issue Type: Improvement > Components: tinkergraph >Affects Versions: 3.1.0-incubating >Reporter: stephen mallette >Assignee: stephen mallette > Fix For: 3.1.3 > > > Improve TinkerGraph performance in relation to the Ferma Benchmark which > shows a reasonably wide gap between TP2 and TP3. We probably won't achieve > parity with Blueprints but it would be nice to carve away some time to lessen > the gap. > https://github.com/Syncleus/Ferma-benchmark -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-939) Neo4jGraph should support HighAvailability (Neo4jHA).
[
https://issues.apache.org/jira/browse/TINKERPOP-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15334498#comment-15334498
]
stephen mallette commented on TINKERPOP-939:
Just for future reference, in case there's a need to test again. You can open
three Gremlin Console instances and then paste one of these in each:
{code}
conf = new BaseConfiguration()
conf.setProperty('gremlin.neo4j.directory','/tmp/neo4j.server1')
conf.setProperty('gremlin.neo4j.conf.ha.server_id','1')
conf.setProperty('gremlin.neo4j.conf.ha.initial_hosts','localhost:5001\\,localhost:5002\\,localhost:5003')
conf.setProperty('gremlin.neo4j.conf.ha.cluster_server','localhost:5001')
conf.setProperty('gremlin.neo4j.conf.ha.server','localhost:6001')
graph = Neo4jGraph.open(conf)
conf = new BaseConfiguration()
conf.setProperty('gremlin.neo4j.directory','/tmp/neo4j.server2')
conf.setProperty('gremlin.neo4j.conf.ha.server_id','2')
conf.setProperty('gremlin.neo4j.conf.ha.initial_hosts','localhost:5001\\,localhost:5002\\,localhost:5003')
conf.setProperty('gremlin.neo4j.conf.ha.cluster_server','localhost:5002')
conf.setProperty('gremlin.neo4j.conf.ha.server','localhost:6002')
graph = Neo4jGraph.open(conf)
conf = new BaseConfiguration()
conf.setProperty('gremlin.neo4j.directory','/tmp/neo4j.server3')
conf.setProperty('gremlin.neo4j.conf.ha.server_id','3')
conf.setProperty('gremlin.neo4j.conf.ha.initial_hosts','localhost:5001\\,localhost:5002\\,localhost:5003')
conf.setProperty('gremlin.neo4j.conf.ha.cluster_server','localhost:5003')
conf.setProperty('gremlin.neo4j.conf.ha.server','localhost:6003')
graph = Neo4jGraph.open(conf)
{code}
> Neo4jGraph should support HighAvailability (Neo4jHA).
> -
>
> Key: TINKERPOP-939
> URL: https://issues.apache.org/jira/browse/TINKERPOP-939
> Project: TinkerPop
> Issue Type: Improvement
> Components: neo4j
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
> Fix For: 3.1.3
>
>
> We should support Neo4j HA in the {{Neo4jGraph}} distribution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TINKERPOP-1342) Allow setting scriptEvaluationTimeout in driver
stephen mallette created TINKERPOP-1342: --- Summary: Allow setting scriptEvaluationTimeout in driver Key: TINKERPOP-1342 URL: https://issues.apache.org/jira/browse/TINKERPOP-1342 Project: TinkerPop Issue Type: Improvement Components: driver Affects Versions: 3.1.2-incubating Reporter: stephen mallette Assignee: stephen mallette Fix For: 3.1.3 Allow this setting to be applied in the driver somehow so as to give the user the ability to override the server setting in the request. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TINKERPOP-1383) publish-docs.sh might publish to current to early
stephen mallette created TINKERPOP-1383:
---
Summary: publish-docs.sh might publish to current to early
Key: TINKERPOP-1383
URL: https://issues.apache.org/jira/browse/TINKERPOP-1383
Project: TinkerPop
Issue Type: Bug
Components: build-release
Affects Versions: 3.1.3
Reporter: stephen mallette
Assignee: Daniel Kuppitz
Fix For: 3.1.4, 3.2.2
In the standard release flow of things, the release manager runs
`bin/publish-docs.sh` right before VOTE which means that `/current` gets
updated at least 3 days before we announce the release.
Maybe updating current should be a specific command?
{code}
bin/publish-docs.sh --update userName
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1383) publish-docs.sh might publish to current too early
[
https://issues.apache.org/jira/browse/TINKERPOP-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1383:
Summary: publish-docs.sh might publish to current too early (was:
publish-docs.sh might publish to current to early)
> publish-docs.sh might publish to current too early
> --
>
> Key: TINKERPOP-1383
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1383
> Project: TinkerPop
> Issue Type: Bug
> Components: build-release
>Affects Versions: 3.1.3
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
> Fix For: 3.1.4, 3.2.2
>
>
> In the standard release flow of things, the release manager runs
> `bin/publish-docs.sh` right before VOTE which means that `/current` gets
> updated at least 3 days before we announce the release.
> Maybe updating current should be a specific command?
> {code}
> bin/publish-docs.sh --update userName
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1385) Refactor Profiling test cases
[
https://issues.apache.org/jira/browse/TINKERPOP-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1385:
Affects Version/s: 3.2.1
Priority: Minor (was: Major)
Component/s: test-suite
> Refactor Profiling test cases
> -
>
> Key: TINKERPOP-1385
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1385
> Project: TinkerPop
> Issue Type: Bug
> Components: test-suite
>Affects Versions: 3.2.1
>Reporter: Matthias Broecheler
>Assignee: Bob Briody
>Priority: Minor
>
> The following test cases make assumptions about the number of steps in the
> traversal. A particular TinkerPop implementation may have strategies that
> change those steps and/or add additional steps to the traversal, thus
> breaking those tests.
> The tests should be rewritten/adjusted to be more lenient and accommodate
> additional implementation strategies.
> {code}
> org.apache.tinkerpop.gremlin.process.traversal.step.map.ProfileTest$Traversals
> .g_V_sideEffectXThread_sleepX10XX_sideEffectXThread_sleepX5XX_profileXmetricsX
> .g_V_whereXinXcreatedX_count_isX1XX_name_profile
> .g_V_whereXinXcreatedX_count_isX1XX_name_profileXmetricsX
> .g_V_sideEffectXThread_sleepX10XX_sideEffectXThread_sleepX5XX_profile
> org.apache.tinkerpop.gremlin.structure.SerializationTest$GraphSONTest.shouldSerializeTraversalMetrics
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1386) Bump to Netty 4.0.39.Final
[ https://issues.apache.org/jira/browse/TINKERPOP-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1386: Description: Consider bumping Netty to 4.0.39.Final - there are a number of bug/security fixes available. http://netty.io/news/2016/03/21/4-0-35-Final.html http://netty.io/news/2016/04/04/4-0-36-Final.html http://netty.io/news/2016/06/07/4-0-37-Final.html http://netty.io/news/2016/07/01/4-0-38-Final-4-1-2-Final.html http://netty.io/news/2016/07/15/4-0-39-Final-4-1-3-Final.html was:Consider bumping Netty to 4.0.39.Final - there are a number of bug/security fixes available. > Bump to Netty 4.0.39.Final > -- > > Key: TINKERPOP-1386 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1386 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.1.3 >Reporter: stephen mallette >Assignee: stephen mallette > Fix For: 3.1.4, 3.2.2 > > > Consider bumping Netty to 4.0.39.Final - there are a number of bug/security > fixes available. > http://netty.io/news/2016/03/21/4-0-35-Final.html > http://netty.io/news/2016/04/04/4-0-36-Final.html > http://netty.io/news/2016/06/07/4-0-37-Final.html > http://netty.io/news/2016/07/01/4-0-38-Final-4-1-2-Final.html > http://netty.io/news/2016/07/15/4-0-39-Final-4-1-3-Final.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1375) Possible ByteBuf leak for certain transactional scenarios
[ https://issues.apache.org/jira/browse/TINKERPOP-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15392157#comment-15392157 ] stephen mallette commented on TINKERPOP-1375: - Thanks [~robertdale] - i created TINKERPOP-1386 to deal with that. > Possible ByteBuf leak for certain transactional scenarios > - > > Key: TINKERPOP-1375 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1375 > Project: TinkerPop > Issue Type: Bug > Components: server >Affects Versions: 3.2.0-incubating >Reporter: stephen mallette >Assignee: stephen mallette > > Not sure how to recreate this but certain transactional scenarios in sessions > seem to generate a standard Netty "LEAK" log message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1383) publish-docs.sh might publish to current too early
[
https://issues.apache.org/jira/browse/TINKERPOP-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15388427#comment-15388427
]
stephen mallette commented on TINKERPOP-1383:
-
+1
> publish-docs.sh might publish to current too early
> --
>
> Key: TINKERPOP-1383
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1383
> Project: TinkerPop
> Issue Type: Bug
> Components: build-release
>Affects Versions: 3.1.3
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
> Fix For: 3.1.4, 3.2.2
>
>
> In the standard release flow of things, the release manager runs
> `bin/publish-docs.sh` right before VOTE which means that `/current` gets
> updated at least 3 days before we announce the release.
> Maybe updating current should be a specific command?
> {code}
> bin/publish-docs.sh --update userName
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1391) issue with where filter
[
https://issues.apache.org/jira/browse/TINKERPOP-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1391:
Assignee: Daniel Kuppitz
Affects Version/s: 3.1.3
Fix Version/s: 3.1.4
Component/s: process
[~arikc] note that the workaround for now would be to write your traversal as:
{code}
gremlin> g.V().hasLabel('GROUP').where(__.outE("PART_OF").count().is(0))
==>v[0]
{code}
Looks like a bug in the traversal strategies:
{code}
gremlin>
g.V().hasLabel('GROUP').where(__.outE().hasLabel("PART_OF").count().is(eq(0))).explain()
==>Traversal Explanation
==
Original Traversal [GraphStep(vertex,[]),
HasStep([~label.eq(GROUP)]), TraversalFilterStep([VertexStep(OUT,edge),
HasStep([~label.eq(PART_OF)]), CountGlobalStep, IsStep(eq(0))])]
ConnectiveStrategy [D] [GraphStep(vertex,[]),
HasStep([~label.eq(GROUP)]), TraversalFilterStep([VertexStep(OUT,edge),
HasStep([~label.eq(PART_OF)]), CountGlobalStep, IsStep(eq(0))])]
IdentityRemovalStrategy [O] [GraphStep(vertex,[]),
HasStep([~label.eq(GROUP)]), TraversalFilterStep([VertexStep(OUT,edge),
HasStep([~label.eq(PART_OF)]), CountGlobalStep, IsStep(eq(0))])]
IncidentToAdjacentStrategy [O] [GraphStep(vertex,[]),
HasStep([~label.eq(GROUP)]), TraversalFilterStep([VertexStep(OUT,edge),
HasStep([~label.eq(PART_OF)]), CountGlobalStep, IsStep(eq(0))])]
AdjacentToIncidentStrategy [O] [GraphStep(vertex,[]),
HasStep([~label.eq(GROUP)]), TraversalFilterStep([VertexStep(OUT,edge),
HasStep([~label.eq(PART_OF)]), CountGlobalStep, IsStep(eq(0))])]
FilterRankingStrategy[O] [GraphStep(vertex,[]),
HasStep([~label.eq(GROUP)]), TraversalFilterStep([VertexStep(OUT,edge),
HasStep([~label.eq(PART_OF)]), CountGlobalStep, IsStep(eq(0))])]
MatchPredicateStrategy [O] [GraphStep(vertex,[]),
HasStep([~label.eq(GROUP)]), TraversalFilterStep([VertexStep(OUT,edge),
HasStep([~label.eq(PART_OF)]), CountGlobalStep, IsStep(eq(0))])]
RepeatUnrollStrategy [O] [GraphStep(vertex,[]),
HasStep([~label.eq(GROUP)]), TraversalFilterStep([VertexStep(OUT,edge),
HasStep([~label.eq(PART_OF)]), CountGlobalStep, IsStep(eq(0))])]
RangeByIsCountStrategy [O] [GraphStep(vertex,[]),
HasStep([~label.eq(GROUP)]), TraversalFilterStep([VertexStep(OUT,edge),
NotStep(![HasStep([~label.eq(PART_OF)])])])]
PathRetractionStrategy [O] [GraphStep(vertex,[]),
HasStep([~label.eq(GROUP)]), TraversalFilterStep([VertexStep(OUT,edge),
NotStep(![HasStep([~label.eq(PART_OF)])])])]
TinkerGraphStepStrategy [P] [TinkerGraphStep(vertex,[~label.eq(GROUP)]),
TraversalFilterStep([VertexStep(OUT,edge),
NotStep(![HasStep([~label.eq(PART_OF)])])])]
ProfileStrategy [F] [TinkerGraphStep(vertex,[~label.eq(GROUP)]),
TraversalFilterStep([VertexStep(OUT,edge),
NotStep(![HasStep([~label.eq(PART_OF)])])])]
StandardVerificationStrategy [V] [TinkerGraphStep(vertex,[~label.eq(GROUP)]),
TraversalFilterStep([VertexStep(OUT,edge),
NotStep(![HasStep([~label.eq(PART_OF)])])])]
Final Traversal[TinkerGraphStep(vertex,[~label.eq(GROUP)]),
TraversalFilterStep([VertexStep(OUT,edge),
NotStep(![HasStep([~label.eq(PART_OF)])])])]
{code}
{{NotStep}} shoudl be wrapped around {{VertexStep}} and {{HasStep}}. It should
generate this:
{code}
gremlin> g.V().hasLabel('GROUP').where(__.outE().not(hasLabel("PART_OF"))) //
what it does
gremlin> g.V().hasLabel('GROUP').where(__.not(outE().hasLabel("PART_OF"))) //
what it should do
==>v[0]
{code}
> issue with where filter
> ---
>
> Key: TINKERPOP-1391
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1391
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.1.3
>Reporter: Arik Cohen
>Assignee: Daniel Kuppitz
> Fix For: 3.1.4
>
>
> Graph g = TinkerGraph.open();
> g.addVertex(T.label,"GROUP","name","Acme");
>
> List list = g.traversal()
>.V()
>.hasLabel("GROUP")
>
> .where(__.outE().hasLabel("PART_OF").count().is(0))
>.toList();
>
> Assert.assertEquals(1, list.size()); // actual size is 0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TINKERPOP-1392) Remove support for java serialized Traversal
stephen mallette created TINKERPOP-1392:
---
Summary: Remove support for java serialized Traversal
Key: TINKERPOP-1392
URL: https://issues.apache.org/jira/browse/TINKERPOP-1392
Project: TinkerPop
Issue Type: Improvement
Components: server
Affects Versions: 3.2.1
Reporter: stephen mallette
Assignee: stephen mallette
Fix For: 3.2.2
Given TINKERPOP-1278 and {{Bytecode}} serialization of a {{Traversal}} the old
method of serializing {{Traversal}} with java serialization isn't that useful.
There seems to be little point in deprecating that functionality because the
only library that supports that protocol is gremlin-driver which will now use
the new approach. Dropping it completely wouldn't break anyone's code though we
still should consider it a "breaking" change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1375) Possible ByteBuf leak for certain transactional scenarios
[ https://issues.apache.org/jira/browse/TINKERPOP-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1375: Affects Version/s: (was: 3.2.0-incubating) 3.1.3 3.2.1 > Possible ByteBuf leak for certain transactional scenarios > - > > Key: TINKERPOP-1375 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1375 > Project: TinkerPop > Issue Type: Bug > Components: server >Affects Versions: 3.1.3, 3.2.1 >Reporter: stephen mallette >Assignee: stephen mallette > > Not sure how to recreate this but certain transactional scenarios in sessions > seem to generate a standard Netty "LEAK" log message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1388) Make ExpandableStepIterator non-final
[ https://issues.apache.org/jira/browse/TINKERPOP-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1388. --- Resolution: Done > Make ExpandableStepIterator non-final > - > > Key: TINKERPOP-1388 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1388 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.1.3 >Reporter: Matthias Broecheler >Assignee: stephen mallette >Priority: Minor > Fix For: 3.1.4, 3.2.2 > > > to allow TinkerPop implementations to extend it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1375) Possible ByteBuf leak for certain transactional scenarios
[
https://issues.apache.org/jira/browse/TINKERPOP-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1375.
---
Resolution: Fixed
Fix Version/s: 3.2.2
3.1.4
Fixed this in both 3.1.4:
https://github.com/apache/tinkerpop/commit/6be28270598862a7a92b88a67d18e5e8f198b92b
and 3.2.2:
https://github.com/apache/tinkerpop/commit/9913d64cd1f9050b3d047b59dcea34ee8507d2dd
In both cases, a failed transaction could have created a situation where a
{{Frame}} was not released and if that {{Frame}} contained a Netty {{Bytebuf}}
(which it likely would) then Netty would report a warning that the {{Bytebuf}}
had not been released.
> Possible ByteBuf leak for certain transactional scenarios
> -
>
> Key: TINKERPOP-1375
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1375
> Project: TinkerPop
> Issue Type: Bug
> Components: server
>Affects Versions: 3.1.3, 3.2.1
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.1.4, 3.2.2
>
>
> Not sure how to recreate this but certain transactional scenarios in sessions
> seem to generate a standard Netty "LEAK" log message.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1402) Impossible for graph implementations to provide a class resolver for Gryo IO
[
https://issues.apache.org/jira/browse/TINKERPOP-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413927#comment-15413927
]
stephen mallette commented on TINKERPOP-1402:
-
+1 - just sent a DISCUSS thread referenced as a link on this ticket
> Impossible for graph implementations to provide a class resolver for Gryo IO
>
>
> Key: TINKERPOP-1402
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1402
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.2.1
>Reporter: Bryn Cooke
>Priority: Critical
> Fix For: 3.2.2
>
>
> As far as I can tell there is no way for a graph implementation to specify a
> classresolver for the following code:
> {noformat}g.io(IoCore.gryo()).writer().create(){noformat}
> The problem is that inside the graph implementation we need to be able to do
> this:
> {noformat}
> public I io(final Io.Builder builder) {
> Io io =
> builder.graph(this).registry(MyRegistry.INSTANCE).classResolver(MyClassReolver.INSTANCE).create();
> {noformat}
> but only supplying a registry is supported.
> Other solutions could be to design GryoIo for extension so that it can be
> wrapped or to change the signature of Graph#io to:
> {noformat}
> public default Io io(final Io.Builder builder)
> {noformat}
> I would probably go for the signature change, so the graph is responsible for
> deciding the implementation that is returned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1402) Impossible for graph implementations to provide a class resolver for Gryo IO
[
https://issues.apache.org/jira/browse/TINKERPOP-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1402:
Fix Version/s: 3.2.2
> Impossible for graph implementations to provide a class resolver for Gryo IO
>
>
> Key: TINKERPOP-1402
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1402
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.2.1
>Reporter: Bryn Cooke
>Priority: Critical
> Fix For: 3.2.2
>
>
> As far as I can tell there is no way for a graph implementation to specify a
> classresolver for the following code:
> {noformat}g.io(IoCore.gryo()).writer().create(){noformat}
> The problem is that inside the graph implementation we need to be able to do
> this:
> {noformat}
> public I io(final Io.Builder builder) {
> Io io =
> builder.graph(this).registry(MyRegistry.INSTANCE).classResolver(MyClassReolver.INSTANCE).create();
> {noformat}
> but only supplying a registry is supported.
> Other solutions could be to design GryoIo for extension so that it can be
> wrapped or to change the signature of Graph#io to:
> {noformat}
> public default Io io(final Io.Builder builder)
> {noformat}
> I would probably go for the signature change, so the graph is responsible for
> deciding the implementation that is returned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1397) StarVertex self edge has buggy interaction with graph filters
[
https://issues.apache.org/jira/browse/TINKERPOP-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1397:
Affects Version/s: 3.1.3
Fix Version/s: 3.1.4
Component/s: process
> StarVertex self edge has buggy interaction with graph filters
> -
>
> Key: TINKERPOP-1397
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1397
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.1.3
>Reporter: Dan LaRocque
> Fix For: 3.1.4
>
>
> When StarVertex adds a self-loop, it adds an instance of concrete type
> {{StarOutEdge}} to both its {{outEdges}} map and its {{inEdges}} map.
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L321-L330
> (line 329 adds a {{StarOutEdge}} to the {{inEdges}} map)
> Having a {{StarOutEdge}} in the {{inEdges}} map mostly doesn't matter.
> However, this does matter in the {{applyGraphFilter}} method. This method
> uses {{instanceof StarOutEdge}} to guess whether an edge's original direction
> was in or out:
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L470
> If you trace {{applyGraphFilter}} through, you see that a {{StarVertex}} with
> a self-loop can pop out of {{applyGraphFilter}} with two out edges
> corresponding to the self loop and no in edges. This leads to weird
> traversal results. One way to trigger this is to write a
> {{GraphFilterAware}} {{InputRDD}} that produces {{StarVertex}} instances and
> then run a {{g.V()inE("somelabel")}}, so that TP pushes down the
> "somelabel" constraint, which is how I got here.
> I think {{addEdge}} should continue putting a {{StarOutEdge}} into
> {{outEdges}}, like it already does. -However, it should put a {{StarInEdge}}
> into {{inEdges}}. This would increase the object overhead associated with
> StarVertices that have self loops (two edge objs instead of one). If we
> wanted to be obsessive about optimizing this case we could probably pervert
> the {{inEdge}}/{{outEdge}} datastructure contents to do it, but IMHO that's
> not worth it.- Actually, I'm no longer convinced that's safe, since I think
> it would alter some of StarVertex's other semantics. For one, I think
> retrieving an edge and setting a property on it would probably break.
> I'll make a PR soon.
> I don't know all of the versions this affects, but I do know it affects 3.2.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (TINKERPOP-1398) 3.2.0-incubating javadocs link broken
[ https://issues.apache.org/jira/browse/TINKERPOP-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette reopened TINKERPOP-1398: - > 3.2.0-incubating javadocs link broken > - > > Key: TINKERPOP-1398 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1398 > Project: TinkerPop > Issue Type: Bug > Components: documentation >Reporter: Robert Dale >Assignee: stephen mallette >Priority: Trivial > Labels: documentation > Original Estimate: 5m > Remaining Estimate: 5m > > tinkerpop.apache.og -> Download -> 3.2.0-incubating -> javadoc > Should point to http://tinkerpop.apache.org/javadocs/3.2.0-incubating/full/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1398) 3.2.0-incubating javadocs link broken
[ https://issues.apache.org/jira/browse/TINKERPOP-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1398. --- Resolution: Done > 3.2.0-incubating javadocs link broken > - > > Key: TINKERPOP-1398 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1398 > Project: TinkerPop > Issue Type: Bug > Components: documentation >Reporter: Robert Dale >Assignee: stephen mallette >Priority: Trivial > Labels: documentation > Original Estimate: 5m > Remaining Estimate: 5m > > tinkerpop.apache.og -> Download -> 3.2.0-incubating -> javadoc > Should point to http://tinkerpop.apache.org/javadocs/3.2.0-incubating/full/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1405) profile() doesn't like withPath()
[
https://issues.apache.org/jira/browse/TINKERPOP-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15420888#comment-15420888
]
stephen mallette commented on TINKERPOP-1405:
-
Is it interesting that this problem doesn't seem to occur in 3.1.3?
{code}
gremlin> g.withPath().V().profile()
==>v[1]
==>v[2]
==>v[3]
==>v[4]
==>v[5]
==>v[6]
{code}
> profile() doesn't like withPath()
> -
>
> Key: TINKERPOP-1405
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1405
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Daniel Kuppitz
>
> {{profile()}} fails when used in conjunction with {{withPath()}}:
> {code}
> gremlin> g.withPath().V().profile()
> When specified, the profile()-Step must be the last step or followed only by
> the cap()-step.
> Display stack trace? [yN]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1404) Path/label optimization
[
https://issues.apache.org/jira/browse/TINKERPOP-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1404:
Affects Version/s: (was: 3.2.2)
3.2.1
> Path/label optimization
> ---
>
> Key: TINKERPOP-1404
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1404
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.1
>Reporter: pieter martin
>Assignee: pieter martin
> Labels: performance
>
> Currently path queries do a lot of label collection copying. This has a
> significant impact on performance.
> As the labels are known and set on the traverser when {{Traverser.split(r,
> step)}} is called there is no need to call {{Traverser.addLabels}} again in
> {{AbstractStep}}
> Also seeing as {{AbstractStep.getLabels()}} returns an {{UnmodifyableSet}}
> the step's labels can be used directly in the traverser. There is no need to
> make a copy of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1405) profile() doesn't like withPath()
[
https://issues.apache.org/jira/browse/TINKERPOP-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1405:
Component/s: process
> profile() doesn't like withPath()
> -
>
> Key: TINKERPOP-1405
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1405
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.1
>Reporter: Daniel Kuppitz
> Fix For: 3.2.2
>
>
> {{profile()}} fails when used in conjunction with {{withPath()}}:
> {code}
> gremlin> g.withPath().V().profile()
> When specified, the profile()-Step must be the last step or followed only by
> the cap()-step.
> Display stack trace? [yN]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1255) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/TINKERPOP-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1255. --- Resolution: Fixed I assume the new download page addresses the issues raised at this point. No "old" versions should be on the mirror at this point. > Please delete old releases from mirroring system > > > Key: TINKERPOP-1255 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1255 > Project: TinkerPop > Issue Type: Improvement > Components: build-release >Affects Versions: 3.1.1-incubating > Environment: > https://dist.apache.org/repos/dist/release/incubator/tinkerpop/ >Reporter: Sebb >Assignee: stephen mallette > > To reduce the load on the ASF mirrors, projects are required to delete old > releases [1] > Please can you remove all non-current releases? > Thanks! > [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1151) slf4j-log4j12 / log4j is only required for testing
[ https://issues.apache.org/jira/browse/TINKERPOP-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1151. --- Resolution: Fixed Fix Version/s: 3.2.2 > slf4j-log4j12 / log4j is only required for testing > -- > > Key: TINKERPOP-1151 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1151 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.1.0-incubating >Reporter: Hendy Irawan >Assignee: stephen mallette >Priority: Trivial > Labels: breaking > Fix For: 3.2.2 > > > Pull request: https://github.com/apache/incubator-tinkerpop/pull/229 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1228) Traversal Caching for TraversalOpProcessor
[
https://issues.apache.org/jira/browse/TINKERPOP-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1228.
---
Resolution: Not A Problem
Assignee: stephen mallette
This really isn't terribly useful an idea anymore with {{Bytecode}}
representation of a {{Traversal}} and side-effect data cached on the server.
> Traversal Caching for TraversalOpProcessor
> --
>
> Key: TINKERPOP-1228
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1228
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver, server
>Affects Versions: 3.2.0-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>
> Serialized traversals are big which makes repeated requests for the same
> traversal expensive. Would be better to cache these somehow for re-use to
> avoid the serialization and network overhead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1145) TraversalSource.script() as a general-solution to :>
[
https://issues.apache.org/jira/browse/TINKERPOP-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1145.
---
Resolution: Won't Fix
Assignee: stephen mallette
The work we have in TINKERPOP-1278 is a better approach to this problem.
> TraversalSource.script() as a general-solution to :>
>
>
> Key: TINKERPOP-1145
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1145
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.0-incubating, 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>
> In {{GraphComputer}}, if the traversal uses a lambda, the user has to use a
> "remote connection" and submit their traversal as a script-engine {{String}}
> via:
> {code}
> gremlin> :> g.V().group().by{it.name[0]}
> {code}
> For Gremlin Server, {{:>}} is currently the only way to submit traversals in
> the Gremlin Console.
> This is all bad. Why? Its Gremlin Console specific and we can solve it more
> elegantly with the work in TINKERPOP-971 and TINKERPOP-575.
> {code}
> g = graph.traversal().withComputer()
> g.V().group().by("name") // CURRENT AND GOOD
> {code}
> {code}
> g = graph.traversal().withComputer()
> g.script("g.V().group().by{it.name[0]}") // PROPOSED
> {code}
> {code}
> g = graph.traversal().withServer('127.0.0.1:8080')
> g.script("g.V().group().by{it.name[0]}") // PROPOSED
> {code}
> See {{TraversalScriptFunction}} for some pieces of the implementation.
> We could then make {{:>}} simply be shorthand for {{g.script()}}. However,
> outside the console, {{g.script()}} just works.
> Next, we can assume {{gremlin-groovy}}, but we could also allow:
> {code}
> g =
> graph.traversal().withServer('127.0.0.1:8080').withStrategies(ScriptEngineStrategy.for("gremlin-scala"))
> g.script("g.V().group().by(??)") // PROPOSED
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1390) IdentityRemoveStrategyTest fails randomly
[
https://issues.apache.org/jira/browse/TINKERPOP-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1390.
---
Resolution: Fixed
Assignee: stephen mallette
Fixed on
https://github.com/apache/tinkerpop/commit/9542419ff262d102f8f8ec21dc28d795fbe876bc
via CTR
> IdentityRemoveStrategyTest fails randomly
> -
>
> Key: TINKERPOP-1390
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1390
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.1
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.2.2
>
>
> This test fails for me on different occasions - enough for me to have noticed
> it happening:
> {code}
> shouldBeFaster(org.apache.tinkerpop.gremlin.process.traversal.strategy.optimization.IdentityRemovalStrategyTest$PerformanceTest)
> Time elapsed: 1.857 sec <<< FAILURE!
> java.lang.AssertionError: null
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.tinkerpop.gremlin.process.traversal.strategy.TraversalStrategyPerformanceTest.shouldBeFaster(TraversalStrategyPerformanceTest.java:107)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure
[
https://issues.apache.org/jira/browse/TINKERPOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419334#comment-15419334
]
stephen mallette commented on TINKERPOP-1278:
-
Implemented TINKERPOP-1347 on this branch.
> Implement Gremlin-Python and general purpose language variant test
> infrastructure
> -
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
> Issue Type: Improvement
> Components: language-variant
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model
> presented in
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
> Moreover, on every {{mvn clean install}}, the code for these variants is
> generated.
> Given the desire to separate language variants from language drivers, I think
> that a language driver for each variant above should be "plugable." Moreover,
> we should provide one driver implementation for each -- simple GremlinServer
> REST.
> {code}
> gremlin-variants/
> gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
> gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
> gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we
> have to implement each {{g_V_out_repeatXasXaXX}} test case in
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to
> convert all those tests from Gremlin-Java to the respective host language?
> However, even if we do that, we still have the problem of how to test the
> returned results.
> I think what we should test the returned results using the JVM. For instance,
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a
> massive headache. All we have to do is create a {{GraphProvider}} that uses
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java// manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1334) Provide a way to pull gremlin.driver.Cluster connection settings.
[ https://issues.apache.org/jira/browse/TINKERPOP-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1334. --- Resolution: Implemented Assignee: stephen mallette Fix Version/s: 3.2.2 Implemented via CTR at https://github.com/apache/tinkerpop/commit/5d87d279f2e142d25a4f92991b1caa5700c9b821 > Provide a way to pull gremlin.driver.Cluster connection settings. > - > > Key: TINKERPOP-1334 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1334 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Affects Versions: 3.2.0-incubating >Reporter: Rocco Varela >Assignee: stephen mallette > Fix For: 3.2.2 > > > I would like a way to extract all the default settings for a > gremlin.driver.Cluster connection. I would like to examine the number of > connections being used in a ConnectionPool, number of in-flight requests per > connection, etc. > I see ways for setting these fields here, but no way to extract them: > http://tinkerpop.incubator.apache.org/javadocs/3.0.1-SNAPSHOT/full/org/apache/tinkerpop/gremlin/driver/Cluster.Builder.html#maxConnectionPoolSize-int- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1230) Serialising lambdas for RemoteGraph
[
https://issues.apache.org/jira/browse/TINKERPOP-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419336#comment-15419336
]
stephen mallette commented on TINKERPOP-1230:
-
A method for lambda serialization was implemented on TINKERPOP-1278 as part of
the work on gremlin-python. This issue will close with that one.
> Serialising lambdas for RemoteGraph
> ---
>
> Key: TINKERPOP-1230
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1230
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver, server
>Affects Versions: 3.1.1-incubating
>Reporter: Michael Pollmeier
>Priority: Minor
>
> I just made an attempt to serialise lambdas and send them via the
> RemoteGraph. I didn't quite get there, but wanted to share my findings:
> * it's possible to serialise lambdas on the jvm by just extending
> `Serializable`:
> http://stackoverflow.com/questions/22807912/how-to-serialize-a-lambda/22808112#22808112
> * sending a normal predicate doesn't work (this is a Scala REPL but it should
> be pretty easy to convert this to java/groovy)
> val g = RemoteGraph.open("conf/remote-graph.properties").traversal()
> val pred1 = new java.util.function.Predicate[Traverser[Vertex]] { def
> test(v: Traverser[Vertex]) = true }
> g.V().filter(pred1).toList
> // java.lang.RuntimeException: java.io.NotSerializableException: $anon$1
> // on server: nothing
>
> * simply adding Serializable let's us send it over the wire, but the server
> doesn't deserialise it
> val pred2 = new java.util.function.Predicate[Traverser[Vertex]] with
> Serializable { def test(v: Traverser[Vertex]) = true }
> g.V().filter(pred2).toList
> // on server: [WARN] OpExecutorHandler - Could not deserialize the
> Traversal instance
> org.apache.tinkerpop.gremlin.server.op.OpProcessorException: Could
> not deserialize the Traversal instance
> at
> org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.iterateOp(TraversalOpProcessor.java:135)
> at
> org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:68)
> // on client:
> org.apache.tinkerpop.gremlin.driver.exception.ResponseException: $anon$1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1380) dedup() doesn't dedup in rare cases
[
https://issues.apache.org/jira/browse/TINKERPOP-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15386472#comment-15386472
]
stephen mallette commented on TINKERPOP-1380:
-
I just noticed this which [~dkuppitz] thinks might be related to this issue:
{code}
gremlin> t = g.V().aggregate('a')
==>v[1]
==>v[2]
==>v[3]
==>v[4]
==>v[5]
==>v[6]
gremlin> t.clone()
==>v[1]
==>v[2]
==>v[3]
==>v[4]
==>v[5]
==>v[6]
gremlin> t.getSideEffects().get('a')
==>v[1]
==>v[1]
==>v[2]
==>v[2]
==>v[3]
==>v[3]
==>v[4]
==>v[4]
==>v[5]
==>v[5]
==>v[6]
==>v[6]
{code}
calls to {{clone()}} are keeping side-effects. perhaps that is the root of the
problem here?
> dedup() doesn't dedup in rare cases
> ---
>
> Key: TINKERPOP-1380
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1380
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.1
>Reporter: Daniel Kuppitz
>
> I stumbled across this issue when I tried to solve a problem on the mailing
> list. It seems like a lot of steps need to be involved in order to make it
> reproducible.
> {code}
> gremlin> :set max-iteration 10
> gremlin>
> gremlin> g = TinkerFactory.createModern().traversal().withComputer()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], graphcomputer]
> gremlin>
> g.V().repeat(both()).until(cyclicPath()).path().aggregate("x").cap("x").unfold().dedup()
> ==>[v[1], v[2], v[1]]
> ==>[v[1], v[2], v[1]]
> ==>[v[1], v[3], v[1]]
> ==>[v[1], v[3], v[1]]
> ==>[v[1], v[4], v[1]]
> ==>[v[1], v[4], v[1]]
> ==>[v[2], v[1], v[2]]
> ==>[v[2], v[1], v[2]]
> ==>[v[3], v[1], v[3]]
> ==>[v[3], v[1], v[3]]
> ...
> {code}
> I can't reproduce it w/o using {{repeat()}}, {{aggregate()}} or {{cap()}}. It
> is reproducible without {{path()}} though. And then it even gets a little
> worse; check this out:
> {code}
> gremlin>
> g.V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x").unfold().dedup()
> ==>v[1]
> ==>v[1]
> ==>v[2]
> ==>v[2]
> ==>v[3]
> ==>v[3]
> ==>v[4]
> ==>v[4]
> ==>v[5]
> ==>v[5]
> ...
> gremlin>
> g.V().repeat(both()).until(cyclicPath()).aggregate("x").cap("x").unfold().dedup().dedup()
> java.lang.RuntimeException: java.lang.IllegalStateException:
> java.lang.IllegalArgumentException: The memory can only be set() during
> vertex program setup and terminate: x
> Display stack trace? [yN]
> {code}
> The exception occurs only in OLAP mode, but also for more meaningful patterns
> ({{.dedup().dedup()}} really doesn't make much sense).
> For a better / larger example see:
> https://groups.google.com/d/msg/gremlin-users/NMXExuvDjt0/ps7bJDYwAQAJ
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1342) Allow setting scriptEvaluationTimeout in driver
[ https://issues.apache.org/jira/browse/TINKERPOP-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1342: Fix Version/s: (was: 3.1.3) 3.1.4 > Allow setting scriptEvaluationTimeout in driver > --- > > Key: TINKERPOP-1342 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1342 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Affects Versions: 3.1.2-incubating >Reporter: stephen mallette >Assignee: stephen mallette > Fix For: 3.1.4 > > > Allow this setting to be applied in the driver somehow so as to give the user > the ability to override the server setting in the request. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1340) docs do not state at what version an API was introduced (or deprecated)
[ https://issues.apache.org/jira/browse/TINKERPOP-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1340: Fix Version/s: (was: 3.1.3) 3.1.4 > docs do not state at what version an API was introduced (or deprecated) > --- > > Key: TINKERPOP-1340 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1340 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Affects Versions: 3.2.0-incubating, 3.1.2-incubating >Reporter: Jason Plurad >Priority: Trivial > Labels: easyfix, newbie > Fix For: 3.2.1, 3.1.4 > > > An all-to-common problem for new developers coming to the TinkerPop is > figuring out which APIs work against the graph they are using. Since > TinkerPop is ahead of many graph implementation out there (Titan/TP 3.0.1, > Stardog/TP 3.0.2, Blazegraph/TP 3.1.0 -- kudos to Sqlg and Unipop for TP > 3.2.0!), it's really important that developers know which APIs in the current > docs are valid. Ideally the developers would go directly to that version of > the TP docs, but that doesn't always happen thanks to Google. > I propose doc updates on each Graph Traversal Step in the [reference > docs|http://tinkerpop.apache.org/docs/current/reference/#graph-traversal-steps] > and in the javadocs (on > [__.java|http://tinkerpop.apache.org/javadocs/current/full/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/__.html] > and on specific step implementations, i.e. > [AddEdgeStep.java|http://tinkerpop.apache.org/javadocs/current/full/org/apache/tinkerpop/gremlin/process/traversal/step/map/AddEdgeStep.html]). > It should state the specific version (3.y.z) the API was introduced or > deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TINKERPOP-980) Add a service script or daemon mode in the distribution
[ https://issues.apache.org/jira/browse/TINKERPOP-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-980: --- Fix Version/s: (was: 3.1.3) 3.1.4 > Add a service script or daemon mode in the distribution > --- > > Key: TINKERPOP-980 > URL: https://issues.apache.org/jira/browse/TINKERPOP-980 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.0.2-incubating >Reporter: Jeremy Hanna >Assignee: Dylan Millikin >Priority: Minor > Fix For: 3.1.4 > > > Based on this discussion, it looks like there was an example from [~dkuppitz] > on how to create a gremlin server service on linux: > https://groups.google.com/forum/#!msg/gremlin-users/uA48IQ3YJcw/4KnUKIS8HI4J > Here is a link to the gist for the service: > https://gist.github.com/dkuppitz/20bda51e3465a612cd9b > I think it would be great to include this or a way to daemonize the server > into the tinkerpop distribution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1287) StarGraph has an overdose of Stream usage.
[
https://issues.apache.org/jira/browse/TINKERPOP-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1287:
Fix Version/s: (was: 3.1.3)
3.1.4
> StarGraph has an overdose of Stream usage.
> --
>
> Key: TINKERPOP-1287
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1287
> Project: TinkerPop
> Issue Type: Improvement
> Components: hadoop, structure
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Ted Wilmes
> Fix For: 3.2.1, 3.1.4
>
> Attachments: stage0.svg, stage1.svg, stage2.svg
>
>
> {{StarGraph}} is loaded with {{Stream}}-usage. Gutting streams from
> TinkerGraph made it much faster. It would be good if we did the same thing
> for {{StarGraph}}.
> This can go into tp31/ and upmerge to master/.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TINKERPOP-1376) Rename TinkerPop artifacts
stephen mallette created TINKERPOP-1376: --- Summary: Rename TinkerPop artifacts Key: TINKERPOP-1376 URL: https://issues.apache.org/jira/browse/TINKERPOP-1376 Project: TinkerPop Issue Type: Improvement Components: build-release Affects Versions: 3.1.3 Reporter: stephen mallette Priority: Minor Fix For: 3.1.4 Rename files to include "apache-tinkerpop-" as a prefix. This is a bit more complicated than just renaming because it affects: * Assembly files * validate-distribution.sh * release documentation (when copying files to svn and such) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (TINKERPOP-1358) spark-gremlin tests require special setup
[ https://issues.apache.org/jira/browse/TINKERPOP-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette reopened TINKERPOP-1358: - > spark-gremlin tests require special setup > - > > Key: TINKERPOP-1358 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1358 > Project: TinkerPop > Issue Type: Test > Components: hadoop >Affects Versions: 3.2.0-incubating > Environment: Linux > No spark, hadoop installed, configured, or running. > No spark, hadoop env vars set. >Reporter: Robert Dale >Assignee: Marko A. Rodriguez > Fix For: 3.2.1 > > Attachments: console.txt > > > cd spark-gremlin; mvn clean install > Most tests fail with: > java.net.BindException: Cannot assign requested address: Service > 'sparkDriver' failed after 16 retries! > Eventually leads to resource starvation: OutOfMemoryError: unable to create > new native thread. Presumably because exceptions are not caught and > SparkContexts closed. > If tests require external server, perhaps they would be best served as > integration tests. Otherwise, there's some undocumented special sauce > missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1358) spark-gremlin tests require special setup
[ https://issues.apache.org/jira/browse/TINKERPOP-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1358: Labels: (was: spark) > spark-gremlin tests require special setup > - > > Key: TINKERPOP-1358 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1358 > Project: TinkerPop > Issue Type: Test > Components: hadoop >Affects Versions: 3.2.0-incubating > Environment: Linux > No spark, hadoop installed, configured, or running. > No spark, hadoop env vars set. >Reporter: Robert Dale >Assignee: Marko A. Rodriguez > Fix For: 3.2.1 > > Attachments: console.txt > > > cd spark-gremlin; mvn clean install > Most tests fail with: > java.net.BindException: Cannot assign requested address: Service > 'sparkDriver' failed after 16 retries! > Eventually leads to resource starvation: OutOfMemoryError: unable to create > new native thread. Presumably because exceptions are not caught and > SparkContexts closed. > If tests require external server, perhaps they would be best served as > integration tests. Otherwise, there's some undocumented special sauce > missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1358) spark-gremlin tests require special setup
[ https://issues.apache.org/jira/browse/TINKERPOP-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1358: Fix Version/s: (was: 3.2.1) > spark-gremlin tests require special setup > - > > Key: TINKERPOP-1358 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1358 > Project: TinkerPop > Issue Type: Test > Components: hadoop >Affects Versions: 3.2.0-incubating > Environment: Linux > No spark, hadoop installed, configured, or running. > No spark, hadoop env vars set. >Reporter: Robert Dale >Assignee: Marko A. Rodriguez > Attachments: console.txt > > > cd spark-gremlin; mvn clean install > Most tests fail with: > java.net.BindException: Cannot assign requested address: Service > 'sparkDriver' failed after 16 retries! > Eventually leads to resource starvation: OutOfMemoryError: unable to create > new native thread. Presumably because exceptions are not caught and > SparkContexts closed. > If tests require external server, perhaps they would be best served as > integration tests. Otherwise, there's some undocumented special sauce > missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1358) spark-gremlin tests require special setup
[ https://issues.apache.org/jira/browse/TINKERPOP-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1358. --- Resolution: Not A Problem > spark-gremlin tests require special setup > - > > Key: TINKERPOP-1358 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1358 > Project: TinkerPop > Issue Type: Test > Components: hadoop >Affects Versions: 3.2.0-incubating > Environment: Linux > No spark, hadoop installed, configured, or running. > No spark, hadoop env vars set. >Reporter: Robert Dale >Assignee: Marko A. Rodriguez > Fix For: 3.2.1 > > Attachments: console.txt > > > cd spark-gremlin; mvn clean install > Most tests fail with: > java.net.BindException: Cannot assign requested address: Service > 'sparkDriver' failed after 16 retries! > Eventually leads to resource starvation: OutOfMemoryError: unable to create > new native thread. Presumably because exceptions are not caught and > SparkContexts closed. > If tests require external server, perhaps they would be best served as > integration tests. Otherwise, there's some undocumented special sauce > missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (TINKERPOP-1358) spark-gremlin tests require special setup
[ https://issues.apache.org/jira/browse/TINKERPOP-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette reopened TINKERPOP-1358: - > spark-gremlin tests require special setup > - > > Key: TINKERPOP-1358 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1358 > Project: TinkerPop > Issue Type: Test > Components: hadoop >Affects Versions: 3.2.0-incubating > Environment: Linux > No spark, hadoop installed, configured, or running. > No spark, hadoop env vars set. >Reporter: Robert Dale >Assignee: Marko A. Rodriguez > Attachments: console.txt > > > cd spark-gremlin; mvn clean install > Most tests fail with: > java.net.BindException: Cannot assign requested address: Service > 'sparkDriver' failed after 16 retries! > Eventually leads to resource starvation: OutOfMemoryError: unable to create > new native thread. Presumably because exceptions are not caught and > SparkContexts closed. > If tests require external server, perhaps they would be best served as > integration tests. Otherwise, there's some undocumented special sauce > missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1358) spark-gremlin tests require special setup
[ https://issues.apache.org/jira/browse/TINKERPOP-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1358. --- Resolution: Not A Problem > spark-gremlin tests require special setup > - > > Key: TINKERPOP-1358 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1358 > Project: TinkerPop > Issue Type: Test > Components: hadoop >Affects Versions: 3.2.0-incubating > Environment: Linux > No spark, hadoop installed, configured, or running. > No spark, hadoop env vars set. >Reporter: Robert Dale >Assignee: Marko A. Rodriguez > Attachments: console.txt > > > cd spark-gremlin; mvn clean install > Most tests fail with: > java.net.BindException: Cannot assign requested address: Service > 'sparkDriver' failed after 16 retries! > Eventually leads to resource starvation: OutOfMemoryError: unable to create > new native thread. Presumably because exceptions are not caught and > SparkContexts closed. > If tests require external server, perhaps they would be best served as > integration tests. Otherwise, there's some undocumented special sauce > missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1007) Gremlin at the Movies Tutorial (SQL-Style in Gremlin)
[
https://issues.apache.org/jira/browse/TINKERPOP-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1007:
Fix Version/s: (was: 3.1.4)
Release 3.1.4 is for bugs only at this point as per discussion on the mailing
list.
> Gremlin at the Movies Tutorial (SQL-Style in Gremlin)
> -
>
> Key: TINKERPOP-1007
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1007
> Project: TinkerPop
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Jeremy Hanna
>
> We need more tutorials. [~spmallette]'s "Getting Started" tutorial is great,
> but (as acknowledged by Russell Jurney) we now need to meet the needs of
> intermediate users as well.
> I think we should do another "30 Minute" tutorial called "Gremlin at the
> Movies" and use the MovieLens dataset.
> http://grouplens.org/datasets/movielens/ (seems we can legally do this --
> http://files.grouplens.org/datasets/movielens/ml-1m-README.txt).
> In this tutorial we provide a {{gryo}} file and the user will learn:
> * Reducing barriers like {{count}}, {{max}}, {{sum}}, etc.
> * {{select}} and its use with {{by}}-projections.
> * {{match}} and its use with {{where}}, {{select}}, etc.
> I think we present the queries in a very "SQL fashion" so people see that
> Gremlin can be written using the popular/known SQL constructs of select,
> where, group, by, etc.
> Thus, "graph data" but "table feel."
> Get information from:
> http://www.slideshare.net/slidarko/the-gremlin-traversal-language?related=1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1342) Allow setting scriptEvaluationTimeout in driver
[ https://issues.apache.org/jira/browse/TINKERPOP-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1342: Fix Version/s: (was: 3.1.4) 3.2.2 Release 3.1.4 is for bugs only at this point as per discussion on the mailing list. > Allow setting scriptEvaluationTimeout in driver > --- > > Key: TINKERPOP-1342 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1342 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Affects Versions: 3.1.2-incubating >Reporter: stephen mallette >Assignee: stephen mallette > Fix For: 3.2.2 > > > Allow this setting to be applied in the driver somehow so as to give the user > the ability to override the server setting in the request. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TINKERPOP-980) Add a service script or daemon mode in the distribution
[ https://issues.apache.org/jira/browse/TINKERPOP-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-980: --- Fix Version/s: (was: 3.1.4) Release 3.1.4 is for bugs only at this point as per discussion on the mailing list. > Add a service script or daemon mode in the distribution > --- > > Key: TINKERPOP-980 > URL: https://issues.apache.org/jira/browse/TINKERPOP-980 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.0.2-incubating >Reporter: Jeremy Hanna >Assignee: Dylan Millikin >Priority: Minor > > Based on this discussion, it looks like there was an example from [~dkuppitz] > on how to create a gremlin server service on linux: > https://groups.google.com/forum/#!msg/gremlin-users/uA48IQ3YJcw/4KnUKIS8HI4J > Here is a link to the gist for the service: > https://gist.github.com/dkuppitz/20bda51e3465a612cd9b > I think it would be great to include this or a way to daemonize the server > into the tinkerpop distribution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1179) AppVeyor Windows build is not stable
[
https://issues.apache.org/jira/browse/TINKERPOP-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15385718#comment-15385718
]
stephen mallette commented on TINKERPOP-1179:
-
[~velobr] i noticed that appveyor seems to have been turned off by apache (i'm
just guessing as they had control of the account). i like the idea of a
"windows build" for TinkerPop as it might encourage windows folks to contribute
and eliminate some mailing list questions when the build fails on that OS,
however this issue really doesn't affect me so i'm not actively working on it.
i'm not sure if this issue still interests you as it's been open a while
without too much new additional activity, but if it does could you please let
me know your thoughts on it when you get a moment?
> AppVeyor Windows build is not stable
> -
>
> Key: TINKERPOP-1179
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1179
> Project: TinkerPop
> Issue Type: Bug
> Components: build-release
>Affects Versions: 3.1.1-incubating
>Reporter: stephen mallette
>
> Since we merged in the working branch of appveyor there have been very few
> stable builds. That lack of stability makes it look like all of our PRs are
> "red" when they really aren't as Travis is successful.
> I've temporarily modified appveyor.yml to just do a {{mvn clean validate}}
> until it can be proven that the appveyor build is stable. There are
> currently several fail points that seem to recur, but I can't say for sure
> that these are all the errors:
> 1. ProfileTest
> {code}
> ProfileTest$Traversals>ProfileTest.g_V_sideEffectXThread_sleepX10XX_sideEffectXThread_sleepX5XX_profile:173
> Duration should be at least the length of the sleep (59ms): 51
> {code}
> This timed test has always given some problems here and there, but i don't
> think we've seen it as a problem in months given the last set of tweaks
> performed to it. We could mark this test as "non-deterministic" and it would
> be ignored for the standard build..not sure if that's the right way to go.
> 2. Archetypes modules won't compile
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-archetype-plugin:2.4:integration-test
> (default) on project gremlin-archetype-tinkergraph:
> [ERROR] Archetype IT 'standard' failed: Cannot run additions goals.
> [ERROR] -> [Help 1]
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-archety
> {code}
> 3. Weirdness with GroupSideEffectStepV3D0Test:
> {code}
> [ERROR]
> /C:/projects/incubator-tinkerpop/gremlin-core/src/test/java/org/apache/tinkerpop/gremlin/process/traversal/step/sideEffect/GroupSideEffectStepV3D0Test.java:[37,8]
> class GroupSideEffectStepV3d0Test is public, should be declared in a file
> named GroupSideEffectStepV3d0Test.java
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1381) improve test coverage of graphs with random ids
[ https://issues.apache.org/jira/browse/TINKERPOP-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1381: Issue Type: Improvement (was: Test) > improve test coverage of graphs with random ids > --- > > Key: TINKERPOP-1381 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1381 > Project: TinkerPop > Issue Type: Improvement > Components: test-suite >Affects Versions: 3.2.1 >Reporter: Jason Plurad > > https://issues.apache.org/jira/browse/TINKERPOP-1379 exposed some issues with > the test suite where some tests were passing because the input graph has > user-assigned ids in a specific, repeatable order. Many graph systems do not > allow user-assigned ids and end up with random ids assigned to elements. This > difference in behavior can cause the TinkerPop suite to pass cleanly against > TinkerGraph, but fail intermittently against other graphs (Titan, Sqlg). > https://issues.apache.org/jira/browse/TINKERPOP-1365 is perhaps related to > this, with respect to finding ways to increase coverage on the graph > configuration permutations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TINKERPOP-1373) Default gremlinPool to number of cores
stephen mallette created TINKERPOP-1373:
---
Summary: Default gremlinPool to number of cores
Key: TINKERPOP-1373
URL: https://issues.apache.org/jira/browse/TINKERPOP-1373
Project: TinkerPop
Issue Type: Improvement
Components: server
Affects Versions: 3.2.0-incubating
Reporter: stephen mallette
Assignee: stephen mallette
Fix For: 3.2.1
There doesn't seem to be a ton of benefit for setting the {{gremlinPool}} to
something greater than the number of cores. This is a better default setting
than is currently provided. Implement so as to make it that a {{gremlinPool}}
of zero will use {{runtime.availableProcessors()}}. Update documentation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1359) Exception thrown when calling subgraph() on Neo4jGraph
[
https://issues.apache.org/jira/browse/TINKERPOP-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1359:
Fix Version/s: 3.1.3
> Exception thrown when calling subgraph() on Neo4jGraph
> --
>
> Key: TINKERPOP-1359
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1359
> Project: TinkerPop
> Issue Type: Bug
> Components: neo4j
>Affects Versions: 3.1.2-incubating
>Reporter: Francesco Vivoli
> Fix For: 3.1.3
>
>
> It seems calling subgraph() on a Neo4j database triggers an
> UnsupportedOperationException
> This has been tested on gremlin-console-3.2.0-incubating.
> Steps to reproduce
> -
> {code}
> graph = Neo4jGraph.open('/tmp/test')
> g = graph.traversal()
> graph.cypher('create (p:Player {pid:1, site:10})')
> graph.cypher('create (p:Player {pid:2, site:10})')
> graph.cypher('create (p:Player {pid:3, site:10})')
> graph.cypher('match (p:Player {pid:3}), (p2:Player {pid:2}) merge (p)-[:AKA
> {t:100}]-(p2)')
> sg = g.V(2).outE().subgraph('sg').cap('sg').next()
> {code}
> Expected behaviour: subgraph is created
> Actual behaviour: the following exception is thrown
> {code}
> java.lang.UnsupportedOperationException: Properties on a vertex property is
> not supported
> at
> org.apache.tinkerpop.gremlin.structure.VertexProperty$Exceptions.metaPropertiesNotSupported(VertexProperty.java:103)
> at
> org.apache.tinkerpop.gremlin.neo4j.structure.trait.NoMultiNoMetaNeo4jTrait.getProperties(NoMultiNoMetaNeo4jTrait.java:146)
> at
> org.apache.tinkerpop.gremlin.neo4j.structure.Neo4jVertexProperty.properties(Neo4jVertexProperty.java:97)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep.lambda$getOrCreate$2(SubgraphStep.java:102)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep$$Lambda$64/777687292.accept(Unknown
> Source)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep.getOrCreate(SubgraphStep.java:100)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep.addEdgeToSubgraph(SubgraphStep.java:111)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep.sideEffect(SubgraphStep.java:64)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SideEffectStep.processNextStart(SideEffectStep.java:39)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:140)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.hasNext(ExpandableStepIterator.java:42)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processAllStarts(SupplyingBarrierStep.java:83)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processNextStart(SupplyingBarrierStep.java:70)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:126)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:37)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.next(DefaultTraversal.java:156)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1359) Exception thrown when calling subgraph() on Neo4jGraph
[
https://issues.apache.org/jira/browse/TINKERPOP-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1359:
Component/s: neo4j
> Exception thrown when calling subgraph() on Neo4jGraph
> --
>
> Key: TINKERPOP-1359
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1359
> Project: TinkerPop
> Issue Type: Bug
> Components: neo4j
>Affects Versions: 3.1.2-incubating
>Reporter: Francesco Vivoli
> Fix For: 3.1.3
>
>
> It seems calling subgraph() on a Neo4j database triggers an
> UnsupportedOperationException
> This has been tested on gremlin-console-3.2.0-incubating.
> Steps to reproduce
> -
> {code}
> graph = Neo4jGraph.open('/tmp/test')
> g = graph.traversal()
> graph.cypher('create (p:Player {pid:1, site:10})')
> graph.cypher('create (p:Player {pid:2, site:10})')
> graph.cypher('create (p:Player {pid:3, site:10})')
> graph.cypher('match (p:Player {pid:3}), (p2:Player {pid:2}) merge (p)-[:AKA
> {t:100}]-(p2)')
> sg = g.V(2).outE().subgraph('sg').cap('sg').next()
> {code}
> Expected behaviour: subgraph is created
> Actual behaviour: the following exception is thrown
> {code}
> java.lang.UnsupportedOperationException: Properties on a vertex property is
> not supported
> at
> org.apache.tinkerpop.gremlin.structure.VertexProperty$Exceptions.metaPropertiesNotSupported(VertexProperty.java:103)
> at
> org.apache.tinkerpop.gremlin.neo4j.structure.trait.NoMultiNoMetaNeo4jTrait.getProperties(NoMultiNoMetaNeo4jTrait.java:146)
> at
> org.apache.tinkerpop.gremlin.neo4j.structure.Neo4jVertexProperty.properties(Neo4jVertexProperty.java:97)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep.lambda$getOrCreate$2(SubgraphStep.java:102)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep$$Lambda$64/777687292.accept(Unknown
> Source)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep.getOrCreate(SubgraphStep.java:100)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep.addEdgeToSubgraph(SubgraphStep.java:111)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep.sideEffect(SubgraphStep.java:64)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SideEffectStep.processNextStart(SideEffectStep.java:39)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:140)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.hasNext(ExpandableStepIterator.java:42)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processAllStarts(SupplyingBarrierStep.java:83)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processNextStart(SupplyingBarrierStep.java:70)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:126)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:37)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.next(DefaultTraversal.java:156)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1359) Exception thrown when calling subgraph() on Neo4jGraph
[
https://issues.apache.org/jira/browse/TINKERPOP-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1359:
Affects Version/s: 3.1.2-incubating
> Exception thrown when calling subgraph() on Neo4jGraph
> --
>
> Key: TINKERPOP-1359
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1359
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.1.2-incubating
>Reporter: Francesco Vivoli
>
> It seems calling subgraph() on a Neo4j database triggers an
> UnsupportedOperationException
> This has been tested on gremlin-console-3.2.0-incubating.
> Steps to reproduce
> -
> {code}
> graph = Neo4jGraph.open('/tmp/test')
> g = graph.traversal()
> graph.cypher('create (p:Player {pid:1, site:10})')
> graph.cypher('create (p:Player {pid:2, site:10})')
> graph.cypher('create (p:Player {pid:3, site:10})')
> graph.cypher('match (p:Player {pid:3}), (p2:Player {pid:2}) merge (p)-[:AKA
> {t:100}]-(p2)')
> sg = g.V(2).outE().subgraph('sg').cap('sg').next()
> {code}
> Expected behaviour: subgraph is created
> Actual behaviour: the following exception is thrown
> {code}
> java.lang.UnsupportedOperationException: Properties on a vertex property is
> not supported
> at
> org.apache.tinkerpop.gremlin.structure.VertexProperty$Exceptions.metaPropertiesNotSupported(VertexProperty.java:103)
> at
> org.apache.tinkerpop.gremlin.neo4j.structure.trait.NoMultiNoMetaNeo4jTrait.getProperties(NoMultiNoMetaNeo4jTrait.java:146)
> at
> org.apache.tinkerpop.gremlin.neo4j.structure.Neo4jVertexProperty.properties(Neo4jVertexProperty.java:97)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep.lambda$getOrCreate$2(SubgraphStep.java:102)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep$$Lambda$64/777687292.accept(Unknown
> Source)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep.getOrCreate(SubgraphStep.java:100)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep.addEdgeToSubgraph(SubgraphStep.java:111)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep.sideEffect(SubgraphStep.java:64)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SideEffectStep.processNextStart(SideEffectStep.java:39)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:140)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.hasNext(ExpandableStepIterator.java:42)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processAllStarts(SupplyingBarrierStep.java:83)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processNextStart(SupplyingBarrierStep.java:70)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:126)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:37)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.next(DefaultTraversal.java:156)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1338) Bump to Groovy 2.4.7
[ https://issues.apache.org/jira/browse/TINKERPOP-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1338. --- Resolution: Done Assignee: stephen mallette > Bump to Groovy 2.4.7 > > > Key: TINKERPOP-1338 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1338 > Project: TinkerPop > Issue Type: Improvement > Components: groovy >Affects Versions: 3.2.0-incubating >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Minor > Fix For: 3.2.1 > > > Provides a number of bug fixes: > http://groovy-lang.org/changelogs/changelog-2.4.7.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-906) Install plugin always fails after first unresolved dependency
[
https://issues.apache.org/jira/browse/TINKERPOP-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15368209#comment-15368209
]
stephen mallette commented on TINKERPOP-906:
[~pluradj] any word on this one? we're on groovy 2.4.7 on master at this
point
> Install plugin always fails after first unresolved dependency
> -
>
> Key: TINKERPOP-906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-906
> Project: TinkerPop
> Issue Type: Bug
> Components: groovy
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>Assignee: Jason Plurad
>
> Original issue: The {{DependencyGrabberTest}} currently require ordered
> execution based on the name of the test. In some environments this seems to
> cause the tests to fail (as they may execute out of order). Generally
> speaking though it seems it would be best if the tests didn't have
> dependencies on each other in order to pass.
> Actual issue: It turns out that there is a bug in Groovy Grapes. When there
> is a failed call to {{Grape.resolve()}}, {{GrapeIvy.resolve()}} hangs onto a
> reference to the IvyGrabRecord for the failed dependency. When subsequent
> {{resolve()}} calls are made, those failed records are still there, so it
> will continue to fail from that point on. This explains why the ordering was
> important in the TinkerPop test case.
> {noformat}
> \,,,/
> (o o)
> -oOOo-(3)-oOOo-
> plugin activated: tinkerpop.server
> plugin activated: tinkerpop.utilities
> plugin activated: tinkerpop.tinkergraph
> gremlin> :install bogus bogus 1.0
> ==>Error grabbing Grapes -- [unresolved dependency: bogus#bogus;1.0: not
> found]
> gremlin> :install org.apache.tinkerpop hadoop-gremlin 3.0.1-incubating
> ==>Error grabbing Grapes -- [unresolved dependency: bogus#bogus;1.0: not
> found]
> {noformat}
> When Groovy 2.4.6 ships with the fix for GROOVY-7649, the {{@Ignore}} in the
> test case can be removed if TinkerPop bumps up to the new Groovy version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1359) Exception thrown when calling subgraph() on Neo4jGraph
[
https://issues.apache.org/jira/browse/TINKERPOP-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15368439#comment-15368439
]
stephen mallette commented on TINKERPOP-1359:
-
This was resolved with:
https://github.com/apache/tinkerpop/commit/c90fc1e1a1520bc3ac9872681fafb1173dd038bb
{code}
gremlin> graph = Neo4jGraph.open('/tmp/test')
==>neo4jgraph[Community [/tmp/test]]
gremlin> g = graph.traversal()
==>graphtraversalsource[neo4jgraph[Community [/tmp/test]], standard]
gremlin> g.V()
gremlin> graph.cypher('create (p:Player {pid:1, site:10})')
gremlin> graph.cypher('create (p:Player {pid:2, site:10})')
gremlin> graph.cypher('create (p:Player {pid:3, site:10})')
gremlin> graph.cypher('match (p:Player {pid:3}), (p2:Player {pid:2}) merge
(p)-[:AKA {t:100}]-(p2)')
gremlin> sg = g.V(2).outE().subgraph('sg').cap('sg').next()
==>tinkergraph[vertices:2 edges:1]
{code}
It will be fixed for 3.1.3 and 3.2.1 - thanks for taking the time to produce
clear reproduction steps and for developing this ticket.
> Exception thrown when calling subgraph() on Neo4jGraph
> --
>
> Key: TINKERPOP-1359
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1359
> Project: TinkerPop
> Issue Type: Bug
> Components: neo4j
>Affects Versions: 3.1.2-incubating
>Reporter: Francesco Vivoli
> Fix For: 3.1.3, 3.2.1
>
>
> It seems calling subgraph() on a Neo4j database triggers an
> UnsupportedOperationException
> This has been tested on gremlin-console-3.2.0-incubating.
> Steps to reproduce
> -
> {code}
> graph = Neo4jGraph.open('/tmp/test')
> g = graph.traversal()
> graph.cypher('create (p:Player {pid:1, site:10})')
> graph.cypher('create (p:Player {pid:2, site:10})')
> graph.cypher('create (p:Player {pid:3, site:10})')
> graph.cypher('match (p:Player {pid:3}), (p2:Player {pid:2}) merge (p)-[:AKA
> {t:100}]-(p2)')
> sg = g.V(2).outE().subgraph('sg').cap('sg').next()
> {code}
> Expected behaviour: subgraph is created
> Actual behaviour: the following exception is thrown
> {code}
> java.lang.UnsupportedOperationException: Properties on a vertex property is
> not supported
> at
> org.apache.tinkerpop.gremlin.structure.VertexProperty$Exceptions.metaPropertiesNotSupported(VertexProperty.java:103)
> at
> org.apache.tinkerpop.gremlin.neo4j.structure.trait.NoMultiNoMetaNeo4jTrait.getProperties(NoMultiNoMetaNeo4jTrait.java:146)
> at
> org.apache.tinkerpop.gremlin.neo4j.structure.Neo4jVertexProperty.properties(Neo4jVertexProperty.java:97)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep.lambda$getOrCreate$2(SubgraphStep.java:102)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep$$Lambda$64/777687292.accept(Unknown
> Source)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep.getOrCreate(SubgraphStep.java:100)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep.addEdgeToSubgraph(SubgraphStep.java:111)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SubgraphStep.sideEffect(SubgraphStep.java:64)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SideEffectStep.processNextStart(SideEffectStep.java:39)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:140)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.hasNext(ExpandableStepIterator.java:42)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processAllStarts(SupplyingBarrierStep.java:83)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.SupplyingBarrierStep.processNextStart(SupplyingBarrierStep.java:70)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:126)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:37)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.next(DefaultTraversal.java:156)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TINKERPOP-1361) Better extract logic for invalid binding keys
stephen mallette created TINKERPOP-1361: --- Summary: Better extract logic for invalid binding keys Key: TINKERPOP-1361 URL: https://issues.apache.org/jira/browse/TINKERPOP-1361 Project: TinkerPop Issue Type: Improvement Components: server Affects Versions: 3.1.2-incubating Reporter: stephen mallette Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1396) Traversal Induced Values Recipe
[ https://issues.apache.org/jira/browse/TINKERPOP-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1396. --- Resolution: Done completed on https://github.com/apache/tinkerpop/pull/371 > Traversal Induced Values Recipe > --- > > Key: TINKERPOP-1396 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1396 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Affects Versions: 3.2.1 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Minor > Fix For: 3.2.2 > > > Develop a recipe for "traversal induced values" - those traversal that use > data from the traversal itself to parameterize other later steps in that same > traversal. This is a commonly asked question on the mailing list. > If there's a better name for this topic, I'm open to hearing what that might > be. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1402) Impossible for graph implementations to provide a class resolver for Gryo IO
[
https://issues.apache.org/jira/browse/TINKERPOP-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1402:
Affects Version/s: 3.2.1
Issue Type: Improvement (was: Bug)
> Impossible for graph implementations to provide a class resolver for Gryo IO
>
>
> Key: TINKERPOP-1402
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1402
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.2.1
>Reporter: Bryn Cooke
>Priority: Critical
>
> As far as I can tell there is no way for a graph implementation to specify a
> classresolver for the following code:
> {noformat}g.io(IoCore.gryo()).writer().create(){noformat}
> The problem is that inside the graph implementation we need to be able to do
> this:
> {noformat}
> public I io(final Io.Builder builder) {
> Io io =
> builder.graph(this).registry(MyRegistry.INSTANCE).classResolver(MyClassReolver.INSTANCE).create();
> {noformat}
> but only supplying a registry is supported.
> Other solutions could be to design GryoIo for extension so that it can be
> wrapped or to change the signature of Graph#io to:
> {noformat}
> public default Io io(final Io.Builder builder)
> {noformat}
> I would probably go for the signature change, so the graph is responsible for
> deciding the implementation that is returned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1402) Impossible for graph implementations to provide a class resolver for Gryo IO
[
https://issues.apache.org/jira/browse/TINKERPOP-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413474#comment-15413474
]
stephen mallette commented on TINKERPOP-1402:
-
I'm hesitant to introduce a breaking change to the structure API, but I see the
problem (i'm also not sure I see how changing the signature helps - a graph
would get one type of {{Builder}} and then just sorta throw it away for
whatever {{Io}} instance it feels like returning? maybe i'm missing the point).
The {{classResolver}} is something newer that didn't really have a place in the
{{Io.Builder}} interface, especially since it's specific to Gryo and really
doesn't have a similar concept anywhere else.
I'm wondering if a quieter way to handle it would be to add another method to
{{Io.Builder}}:
{code}
public Builder onMapper(final UnaryOperator
mapper);
{code}
Of course, that makes the point of the {{registry}} method a bit useless as
then you could just assign the {{IoRegistry}} in the {{UnaryOperator}}. Maybe
the {{IoRegistry}} could somehow have some function in allowing a graph to
register a {{ClassResolver}} there in a general way?
> Impossible for graph implementations to provide a class resolver for Gryo IO
>
>
> Key: TINKERPOP-1402
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1402
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.2.1
>Reporter: Bryn Cooke
>Priority: Critical
>
> As far as I can tell there is no way for a graph implementation to specify a
> classresolver for the following code:
> {noformat}g.io(IoCore.gryo()).writer().create(){noformat}
> The problem is that inside the graph implementation we need to be able to do
> this:
> {noformat}
> public I io(final Io.Builder builder) {
> Io io =
> builder.graph(this).registry(MyRegistry.INSTANCE).classResolver(MyClassReolver.INSTANCE).create();
> {noformat}
> but only supplying a registry is supported.
> Other solutions could be to design GryoIo for extension so that it can be
> wrapped or to change the signature of Graph#io to:
> {noformat}
> public default Io io(final Io.Builder builder)
> {noformat}
> I would probably go for the signature change, so the graph is responsible for
> deciding the implementation that is returned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1402) Impossible for graph implementations to provide a class resolver for Gryo IO
[
https://issues.apache.org/jira/browse/TINKERPOP-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413598#comment-15413598
]
stephen mallette commented on TINKERPOP-1402:
-
OK - I'd like to think on it for today but if I don't think of anything better
I'll suggest deprecation of {{registry}} on the mailing list in favor of
{{onMapper}} (or a better name) and see if anyone has any issues.
> Impossible for graph implementations to provide a class resolver for Gryo IO
>
>
> Key: TINKERPOP-1402
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1402
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.2.1
>Reporter: Bryn Cooke
>Priority: Critical
>
> As far as I can tell there is no way for a graph implementation to specify a
> classresolver for the following code:
> {noformat}g.io(IoCore.gryo()).writer().create(){noformat}
> The problem is that inside the graph implementation we need to be able to do
> this:
> {noformat}
> public I io(final Io.Builder builder) {
> Io io =
> builder.graph(this).registry(MyRegistry.INSTANCE).classResolver(MyClassReolver.INSTANCE).create();
> {noformat}
> but only supplying a registry is supported.
> Other solutions could be to design GryoIo for extension so that it can be
> wrapped or to change the signature of Graph#io to:
> {noformat}
> public default Io io(final Io.Builder builder)
> {noformat}
> I would probably go for the signature change, so the graph is responsible for
> deciding the implementation that is returned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1350) Server locks when submitting parallel requests on session
[
https://issues.apache.org/jira/browse/TINKERPOP-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1350.
---
Resolution: Fixed
> Server locks when submitting parallel requests on session
> -
>
> Key: TINKERPOP-1350
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1350
> Project: TinkerPop
> Issue Type: Bug
> Components: server
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.1.4, 3.2.2
>
>
> This really is only a problem when there is some form of long blocking script
> submitted and only on a session when done in parallel, like:
> {code}
> final ResultSet first = client.submit(
> "Object mon1 = 'mon1';\n" +
> "synchronized (mon1) {\n" +
> "mon1.wait();\n" +
> "} ");
> final ResultSet second = client.submit(
> "Object mon2 = 'mon2';\n" +
> "synchronized (mon2) {\n" +
> "mon2.wait();\n" +
> "}");
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1389) Support Spark 2.0.0
[ https://issues.apache.org/jira/browse/TINKERPOP-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1389: Fix Version/s: 3.3.0 > Support Spark 2.0.0 > --- > > Key: TINKERPOP-1389 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1389 > Project: TinkerPop > Issue Type: Improvement > Components: hadoop >Affects Versions: 3.2.1 >Reporter: Chen Xin Yu > Fix For: 3.3.0 > > > Spark 2.0.0 was released: > http://spark.apache.org/news/spark-2-0-0-released.html > There are lots of improvement and changes compared to 1.6.1, we should better > bump to it for TinkerPop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1401) Support Spark 2.0
[ https://issues.apache.org/jira/browse/TINKERPOP-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1401. --- Resolution: Duplicate Assignee: stephen mallette Fix Version/s: (was: 3.3.0) > Support Spark 2.0 > - > > Key: TINKERPOP-1401 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1401 > Project: TinkerPop > Issue Type: Improvement > Components: hadoop, process >Affects Versions: 3.2.1 >Reporter: Marko A. Rodriguez >Assignee: stephen mallette > > Support the latest major version of Spark -- 2.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1350) Server locks when submitting parallel requests on session
[
https://issues.apache.org/jira/browse/TINKERPOP-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1350:
Fix Version/s: (was: 3.2.1)
(was: 3.1.3)
3.2.2
3.1.4
> Server locks when submitting parallel requests on session
> -
>
> Key: TINKERPOP-1350
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1350
> Project: TinkerPop
> Issue Type: Bug
> Components: server
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.1.4, 3.2.2
>
>
> This really is only a problem when there is some form of long blocking script
> submitted and only on a session when done in parallel, like:
> {code}
> final ResultSet first = client.submit(
> "Object mon1 = 'mon1';\n" +
> "synchronized (mon1) {\n" +
> "mon1.wait();\n" +
> "} ");
> final ResultSet second = client.submit(
> "Object mon2 = 'mon2';\n" +
> "synchronized (mon2) {\n" +
> "mon2.wait();\n" +
> "}");
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (TINKERPOP-1350) Server locks when submitting parallel requests on session
[
https://issues.apache.org/jira/browse/TINKERPOP-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette reopened TINKERPOP-1350:
-
This one didn't appear to be quite fixed. Additional testing showed that it was
fixed only because the test assumed two parallel requests when the problem
actually showed when the number of parallel requests was greater than the
number of threads in the gremlin server worker pool.
> Server locks when submitting parallel requests on session
> -
>
> Key: TINKERPOP-1350
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1350
> Project: TinkerPop
> Issue Type: Bug
> Components: server
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.1.3, 3.2.1
>
>
> This really is only a problem when there is some form of long blocking script
> submitted and only on a session when done in parallel, like:
> {code}
> final ResultSet first = client.submit(
> "Object mon1 = 'mon1';\n" +
> "synchronized (mon1) {\n" +
> "mon1.wait();\n" +
> "} ");
> final ResultSet second = client.submit(
> "Object mon2 = 'mon2';\n" +
> "synchronized (mon2) {\n" +
> "mon2.wait();\n" +
> "}");
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1391) issue with where filter
[
https://issues.apache.org/jira/browse/TINKERPOP-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15399612#comment-15399612
]
stephen mallette commented on TINKERPOP-1391:
-
[~arikc] i'd assumed that this also failed in 3.1.3 - did you confirm that it
works on 3.1.3 before changing the affected version to 3.2.1? if not, we should
fix on the 3.1.x line.
> issue with where filter
> ---
>
> Key: TINKERPOP-1391
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1391
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.1
>Reporter: Arik Cohen
>Assignee: Daniel Kuppitz
>
> Graph g = TinkerGraph.open();
> g.addVertex(T.label,"GROUP","name","Acme");
>
> List list = g.traversal()
>.V()
>.hasLabel("GROUP")
>
> .where(__.outE().hasLabel("PART_OF").count().is(0))
>.toList();
>
> Assert.assertEquals(1, list.size()); // actual size is 0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1091) Get KryoSerializer to work natively.
[
https://issues.apache.org/jira/browse/TINKERPOP-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356851#comment-15356851
]
stephen mallette commented on TINKERPOP-1091:
-
[~okram] can we close this one now based on the gryo work that dan did?
> Get KryoSerializer to work natively.
>
>
> Key: TINKERPOP-1091
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1091
> Project: TinkerPop
> Issue Type: Improvement
> Components: hadoop
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
> Labels: breaking
> Fix For: 3.2.1
>
>
> Right now, if you use SparkServer (cluster mode) then you need to have
> {{GryoSerializer}} on all the machines in the cluster. That is,
> {{SparkContext.addJar()}} does NOT work for {{spark.serializer}}. This is
> really lame.
> I know we want to get make {{GryoSerializer}} able to work more generally
> ([~dalaro]). Lets see if we can't get {{KryoSerializer}} with custom added
> TinkerPop3 classes to work. This way, we don't have to copy jars to machines
> and can rely on {{loadJars()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1349) RepeatUnrollStrategy should unroll loops while maintaining equivalent semantics.
[
https://issues.apache.org/jira/browse/TINKERPOP-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1349:
Fix Version/s: (was: 3.2.0-incubating)
3.2.1
> RepeatUnrollStrategy should unroll loops while maintaining equivalent
> semantics.
>
>
> Key: TINKERPOP-1349
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1349
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.1
>
>
> Create {{RepeatUnrollStrategy}} that will unroll patterns such as:
> {code}
> repeat(out()).times(3)
> // ->
> out().barrier().out().barrier().out().barrier()
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1345) Unrolling of collection for ids
[
https://issues.apache.org/jira/browse/TINKERPOP-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1345:
Affects Version/s: 3.2.0-incubating
Component/s: process
> Unrolling of collection for ids
> ---
>
> Key: TINKERPOP-1345
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1345
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Matthias Broecheler
>
> In GraphStep, TinkerPop does this:
> {code}
> this.ids = (ids.length == 1 && ids[0] instanceof Collection) ? ((Collection)
> ids[0]).toArray(new Object[((Collection) ids[0]).size()]) : ids;
> {code}
> which means that collections are automatically unrolled when there is only
> one element. This breaks TP implementations that use collections to represent
> ids, for instance, because their id representation has multiple components
> (like a primary key in an RDMBS).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1354) Include all static enum imports in request validation for bindings
[
https://issues.apache.org/jira/browse/TINKERPOP-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1354:
Labels: breaking (was: )
> Include all static enum imports in request validation for bindings
> --
>
> Key: TINKERPOP-1354
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1354
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Labels: breaking
> Fix For: 3.1.3, 3.2.1
>
>
> Gremlin Server validates the bindings of incoming requests and returns an
> error for any reserved terms. The list of reserved terms only includes {{T}}
> but should also include others like {{Order}} and {{Scope}} so that users
> don't inadvertently override them with a request binding. When that happens
> Gremlin Server throws a not so easy to understand error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1351) Number of connections going beyond the pool max size
[
https://issues.apache.org/jira/browse/TINKERPOP-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357888#comment-15357888
]
stephen mallette commented on TINKERPOP-1351:
-
I'm going to add your change on the TINKERPOP-1352 branch so that we can have
one pull request to represent all these bug fixes related to the connection
pool. It would be great if you could test that branch out if you get a chance.
You can see the PR here:
https://github.com/apache/tinkerpop/pull/352
Running tests over these changes now and should be pushing shortly.
> Number of connections going beyond the pool max size
>
>
> Key: TINKERPOP-1351
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1351
> Project: TinkerPop
> Issue Type: Bug
> Components: driver
>Affects Versions: 3.1.2-incubating
> Environment: RESTful web service using gremlin driver to send request
> to a Gremlin Server
>Reporter: Ramzi Oueslati
>Assignee: stephen mallette
> Fix For: 3.1.3, 3.2.1
>
>
> When the gremlin driver is used with an important number of concurrent
> requests, sockets are opened far beyond the max pool size.
> At some point, the connections are destroyed, the pool is empty and then the
> borrowConnection process goes through :
> {code:java}
> if (connections.isEmpty()) {
> logger.debug("Tried to borrow connection but the pool was empty
> for {} - scheduling pool creation and waiting for connection", host);
> for (int i = 0; i < minPoolSize; i++) {
> scheduledForCreation.incrementAndGet();
> newConnection();
> }
> return waitForConnection(timeout, unit);
> }
> {code}
> If many connections are borrowed at the same time then this code will
> schedule as many connections for creation.
> I added a check :
> {code:java}
> for (int i = 0; i < minPoolSize; i++) {
> if (scheduledForCreation.get() < minPoolSize) {
> scheduledForCreation.incrementAndGet();
> logger.debug("borrowConnection: [inc]
> scheduledForCreation=" + scheduledForCreation.get());
> newConnection();
> }
> }
> {code}
> It seems to solve the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1351) Number of connections going beyond the pool max size
[
https://issues.apache.org/jira/browse/TINKERPOP-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1351:
Summary: Number of connections going beyond the pool max size (was: Nb of
connections going beyond the pool max size)
> Number of connections going beyond the pool max size
>
>
> Key: TINKERPOP-1351
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1351
> Project: TinkerPop
> Issue Type: Bug
> Components: driver
>Affects Versions: 3.1.2-incubating
> Environment: RESTful web service using gremlin driver to send request
> to a Gremlin Server
>Reporter: Ramzi Oueslati
>Assignee: stephen mallette
> Fix For: 3.1.3, 3.2.1
>
>
> When the gremlin driver is used with an important number of concurrent
> requests, sockets are opened far beyond the max pool size.
> At some point, the connections are destroyed, the pool is empty and then the
> borrowConnection process goes through :
> {code:java}
> if (connections.isEmpty()) {
> logger.debug("Tried to borrow connection but the pool was empty
> for {} - scheduling pool creation and waiting for connection", host);
> for (int i = 0; i < minPoolSize; i++) {
> scheduledForCreation.incrementAndGet();
> newConnection();
> }
> return waitForConnection(timeout, unit);
> }
> {code}
> If many connections are borrowed at the same time then this code will
> schedule as many connections for creation.
> I added a check :
> {code:java}
> for (int i = 0; i < minPoolSize; i++) {
> if (scheduledForCreation.get() < minPoolSize) {
> scheduledForCreation.incrementAndGet();
> logger.debug("borrowConnection: [inc]
> scheduledForCreation=" + scheduledForCreation.get());
> newConnection();
> }
> }
> {code}
> It seems to solve the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1351) Nb of connections going beyond the pool max size
[
https://issues.apache.org/jira/browse/TINKERPOP-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1351:
Affects Version/s: (was: 3.2.0-incubating)
3.1.2-incubating
> Nb of connections going beyond the pool max size
>
>
> Key: TINKERPOP-1351
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1351
> Project: TinkerPop
> Issue Type: Bug
> Components: driver
>Affects Versions: 3.1.2-incubating
> Environment: RESTful web service using gremlin driver to send request
> to a Gremlin Server
>Reporter: Ramzi Oueslati
> Fix For: 3.1.3, 3.2.1
>
>
> When the gremlin driver is used with an important number of concurrent
> requests, sockets are opened far beyond the max pool size.
> At some point, the connections are destroyed, the pool is empty and then the
> borrowConnection process goes through :
> {code:java}
> if (connections.isEmpty()) {
> logger.debug("Tried to borrow connection but the pool was empty
> for {} - scheduling pool creation and waiting for connection", host);
> for (int i = 0; i < minPoolSize; i++) {
> scheduledForCreation.incrementAndGet();
> newConnection();
> }
> return waitForConnection(timeout, unit);
> }
> {code}
> If many connections are borrowed at the same time then this code will
> schedule as many connections for creation.
> I added a check :
> {code:java}
> for (int i = 0; i < minPoolSize; i++) {
> if (scheduledForCreation.get() < minPoolSize) {
> scheduledForCreation.incrementAndGet();
> logger.debug("borrowConnection: [inc]
> scheduledForCreation=" + scheduledForCreation.get());
> newConnection();
> }
> }
> {code}
> It seems to solve the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1351) Nb of connections going beyond the pool max size
[
https://issues.apache.org/jira/browse/TINKERPOP-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1351:
Fix Version/s: 3.2.1
3.1.3
> Nb of connections going beyond the pool max size
>
>
> Key: TINKERPOP-1351
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1351
> Project: TinkerPop
> Issue Type: Bug
> Components: driver
>Affects Versions: 3.1.2-incubating
> Environment: RESTful web service using gremlin driver to send request
> to a Gremlin Server
>Reporter: Ramzi Oueslati
> Fix For: 3.1.3, 3.2.1
>
>
> When the gremlin driver is used with an important number of concurrent
> requests, sockets are opened far beyond the max pool size.
> At some point, the connections are destroyed, the pool is empty and then the
> borrowConnection process goes through :
> {code:java}
> if (connections.isEmpty()) {
> logger.debug("Tried to borrow connection but the pool was empty
> for {} - scheduling pool creation and waiting for connection", host);
> for (int i = 0; i < minPoolSize; i++) {
> scheduledForCreation.incrementAndGet();
> newConnection();
> }
> return waitForConnection(timeout, unit);
> }
> {code}
> If many connections are borrowed at the same time then this code will
> schedule as many connections for creation.
> I added a check :
> {code:java}
> for (int i = 0; i < minPoolSize; i++) {
> if (scheduledForCreation.get() < minPoolSize) {
> scheduledForCreation.incrementAndGet();
> logger.debug("borrowConnection: [inc]
> scheduledForCreation=" + scheduledForCreation.get());
> newConnection();
> }
> }
> {code}
> It seems to solve the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-786) Patterns for DSL Development
[ https://issues.apache.org/jira/browse/TINKERPOP-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-786: --- Component/s: (was: process) documentation Perhaps we need a tutorial written on this topic at this point as it sounds like the pattern is decided. I'm going to switch the type on this issue to "documentation" and here's some recent discussion on the mailing list for ways DSLs can be implemented: https://groups.google.com/d/msg/gremlin-users/FO3bcXHWTrg/6H64dHrUFgAJ > Patterns for DSL Development > > > Key: TINKERPOP-786 > URL: https://issues.apache.org/jira/browse/TINKERPOP-786 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Affects Versions: 3.0.2-incubating >Reporter: stephen mallette >Assignee: Marko A. Rodriguez > Fix For: 3.2.1 > > > Develop and document the patterns for custom DSLs. The method previously > described and under consideration at 3.0.0 seems a bit cumbersome to deal > with. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1348) TraversalInterruptionTest success dependent on iteration order
[ https://issues.apache.org/jira/browse/TINKERPOP-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1348. --- Resolution: Fixed > TraversalInterruptionTest success dependent on iteration order > -- > > Key: TINKERPOP-1348 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1348 > Project: TinkerPop > Issue Type: Bug > Components: test-suite >Affects Versions: 3.2.0-incubating >Reporter: Bryn Cooke >Assignee: stephen mallette >Priority: Minor > Fix For: 3.2.1 > > > If the first element encountered does not fulfil the second part of the > iteration it will encounter the sleep before the iteration started check. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TINKERPOP-1407) Default serializers for Gremlin Server
stephen mallette created TINKERPOP-1407: --- Summary: Default serializers for Gremlin Server Key: TINKERPOP-1407 URL: https://issues.apache.org/jira/browse/TINKERPOP-1407 Project: TinkerPop Issue Type: Improvement Components: server Affects Versions: 3.2.1 Reporter: stephen mallette Priority: Minor If no serializers are configured then Gremlin Server is basically inoperable. It probably shouldn't work that way. Would be better if some default serializers were configured in that case - maybe gryo and the base graphson. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TINKERPOP-1408) Remove Deprecated Io.Builder.registry()
stephen mallette created TINKERPOP-1408: --- Summary: Remove Deprecated Io.Builder.registry() Key: TINKERPOP-1408 URL: https://issues.apache.org/jira/browse/TINKERPOP-1408 Project: TinkerPop Issue Type: Improvement Components: io Affects Versions: 3.2.1 Reporter: stephen mallette Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1409) Make the "null" return in the gremlin console into something more understandable
[ https://issues.apache.org/jira/browse/TINKERPOP-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1409: Affects Version/s: 3.2.1 Component/s: console It is a bit tucked away in the documentation. Perhaps we could add some detail to the console tutorial on this topic. I'm not sure what else we can do about "null" as a return. Past discussions haven't really turned up anything better that made sense, not to mention the madness we would place on existing users who are used to seeing that output. > Make the "null" return in the gremlin console into something more > understandable > > > Key: TINKERPOP-1409 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1409 > Project: TinkerPop > Issue Type: Improvement > Components: console >Affects Versions: 3.2.1 >Reporter: Jeremy Hanna > > A common question among new users is what is with the "null" return String in > the console when there is a successful execution. An explanation is in the > docs now (see note at bottom of > http://tinkerpop.apache.org/docs/current/reference/#_mutating_the_graph > section) but it would be nice to avoid it or make it more immediately > understandable for new users. > It's not a huge deal, but often comes up as a question from new users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TINKERPOP-989) Default documentation should be reference/index.html
[ https://issues.apache.org/jira/browse/TINKERPOP-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-989. -- Resolution: Done Assignee: stephen mallette Fix Version/s: 3.2.2 3.1.4 > Default documentation should be reference/index.html > > > Key: TINKERPOP-989 > URL: https://issues.apache.org/jira/browse/TINKERPOP-989 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Affects Versions: 3.1.0-incubating >Reporter: Marko A. Rodriguez >Assignee: stephen mallette >Priority: Minor > Fix For: 3.1.4, 3.2.2 > > > Now that we put the docs into folders, the base URL is a directory structure: > http://tinkerpop.incubator.apache.org/docs/3.1.1-SNAPSHOT/ ... should we > have this default to reference/index.html? I think so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TINKERPOP-1411) VertexProgramStrategy has a hardcode check for RemoteStrategy
stephen mallette created TINKERPOP-1411:
---
Summary: VertexProgramStrategy has a hardcode check for
RemoteStrategy
Key: TINKERPOP-1411
URL: https://issues.apache.org/jira/browse/TINKERPOP-1411
Project: TinkerPop
Issue Type: Improvement
Components: process
Affects Versions: 3.2.1
Reporter: stephen mallette
Priority: Minor
In the {{apply()}} method of {{VertexProgramStrategy}} there is a hardcoded
check for {{RemoteStrategy}}. That hardcoding gives {{VertexProgramStrategy}} a
bit more knowledge about other strategies than it should have. Would be better
to generalize that in some way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1044) ResponseMessage should contain server-side exception name.
[ https://issues.apache.org/jira/browse/TINKERPOP-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15848359#comment-15848359 ] stephen mallette commented on TINKERPOP-1044: - This one remains open at the pull request related to this change only added a change for REST. There is a larger body of work related to the gremlin server protocol and the error responses. > ResponseMessage should contain server-side exception name. > -- > > Key: TINKERPOP-1044 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1044 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.1.0-incubating >Reporter: Bob Briody >Priority: Minor > > When an exception occurs during execution by gremlin server, the > ResponseMessage currently contains the Exception message, but it would also > be helpful to include the Exception class name. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TINKERPOP-1624) Add JanusGraph to the list of Graph systems on landing page?
[ https://issues.apache.org/jira/browse/TINKERPOP-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1624. --- Resolution: Invalid This is better discussed directly on the dev list. I started a thread. here: https://lists.apache.org/thread.html/246807a067c2ef05d82c1bf38ac53dea1138f89ed0a76f298df9cd84@%3Cdev.tinkerpop.apache.org%3E JanusGraph may also wish to be added to the providers page: http://tinkerpop.apache.org/providers.html#data-system-providers If that's something that you'd like to see happen as well, perhaps you could coordinate that on the dev list once the provider index issue is settled > Add JanusGraph to the list of Graph systems on landing page? > > > Key: TINKERPOP-1624 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1624 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Reporter: Alexander Patrikalakis >Priority: Minor > > A new graph system appeared; ok to add to list? > https://github.com/JanusGraph/janusgraph > http://janusgraph.org -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (TINKERPOP-1624) Add JanusGraph to the list of Graph systems on landing page?
[ https://issues.apache.org/jira/browse/TINKERPOP-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1624: Priority: Minor (was: Trivial) Issue Type: Improvement (was: Task) > Add JanusGraph to the list of Graph systems on landing page? > > > Key: TINKERPOP-1624 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1624 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Reporter: Alexander Patrikalakis >Priority: Minor > > A new graph system appeared; ok to add to list? > https://github.com/JanusGraph/janusgraph > http://janusgraph.org -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1410) mvn install -Dmaven.test.skip=true doesn't work on a clean machine
[
https://issues.apache.org/jira/browse/TINKERPOP-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856625#comment-15856625
]
stephen mallette commented on TINKERPOP-1410:
-
I don't know why you would get that if you already ran {{mvn clean install}}
successfully.
> mvn install -Dmaven.test.skip=true doesn't work on a clean machine
> --
>
> Key: TINKERPOP-1410
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1410
> Project: TinkerPop
> Issue Type: Bug
> Components: build-release
>Affects Versions: 3.2.1
>Reporter: Bryn Cooke
>
> {noformat}mvn install -Dmaven.test.skip=true{noformat}
> gives
> {noformat}
> Failed to execute goal on project spark-gremlin: Could not resolve
> dependencies for project
> org.apache.tinkerpop:spark-gremlin:jar:3.2.2-SNAPSHOT: Could not find
> artifact org.apache.tinkerpop:hadoop-gremlin:jar:tests:3.2.2-SNAPSHOT in
> apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1]
> [ERROR] {noformat}
> The reason for this is that skipping tests also skips creating the test jar
> artefact for hadoop-gremlin.
> https://issues.apache.org/jira/browse/MJAR-138
> Really the prefferred way for creating test jars is to have them as a
> separate project:
> https://maven.apache.org/plugins/maven-jar-plugin/examples/create-test-jar.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (TINKERPOP-1621) Remove deprecated GremlnPlugin and related infrastructure
stephen mallette created TINKERPOP-1621:
---
Summary: Remove deprecated GremlnPlugin and related infrastructure
Key: TINKERPOP-1621
URL: https://issues.apache.org/jira/browse/TINKERPOP-1621
Project: TinkerPop
Issue Type: Improvement
Components: groovy
Affects Versions: 3.2.3
Reporter: stephen mallette
{{GremlinPlugin}} in gremlin-groovy and related infrastructure/implementations
was deprecated in 3.2.4 and replaced by a system in gremlin-core. With the
removal of gremlin-groovy-test in TINKERPOP-1612 a fair bit of related code had
to be removed which makes the old {{GremlinPlugin}} code even less useful and
essentially dead.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (TINKERPOP-1623) How to use gremlin Stored in the mysql database
[ https://issues.apache.org/jira/browse/TINKERPOP-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1623: Issue Type: Improvement (was: Wish) > How to use gremlin Stored in the mysql database > --- > > Key: TINKERPOP-1623 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1623 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.2.3 >Reporter: liup > Fix For: 3.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TINKERPOP-1623) How to use gremlin Stored in the mysql database
[ https://issues.apache.org/jira/browse/TINKERPOP-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1623. --- Resolution: Invalid Fix Version/s: (was: 3.3.0) I'm not sure what you're asking, but if you want to use Gremlin over a MySQL database then you might want to look at this project: http://umlg.org/sqlg.html In the future, please use our mailing list for asking questions: https://groups.google.com/forum/#!forum/gremlin-users We only use JIRA to track specific implementation tasks and bugs.. > How to use gremlin Stored in the mysql database > --- > > Key: TINKERPOP-1623 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1623 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.2.3 >Reporter: liup > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TINKERPOP-1611) Groovy Security Issue: Remote execution of untrusted code, DoS
[
https://issues.apache.org/jira/browse/TINKERPOP-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1611.
---
Resolution: Duplicate
Thanks james but already done for TinkerPop 3.1.x and up
> Groovy Security Issue: Remote execution of untrusted code, DoS
> ---
>
> Key: TINKERPOP-1611
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1611
> Project: TinkerPop
> Issue Type: Bug
> Components: groovy
>Affects Versions: 3.2.3
>Reporter: James Thornton
>Priority: Critical
> Labels: security
>
> Severity: Important
> Vendor: The Apache Software Foundation
> Versions Affected:
> * Unsupported Codehaus versions of Groovy from 1.7.0 to 2.4.3
> * Apache Groovy 2.4.4 to 2.4.7
> * Fixed in version 2.4.8
> Impact:
> Remote execution of untrusted code, DoS
> Description:
> When an application with Groovy on classpath uses standard
> Java serialization mechanisms, e.g. to communicate between servers
> or to store local data, it is possible for an attacker to bake a special
> serialized object that will execute code directly when deserialized.
> All applications which rely on serialization and do not isolate the
> code which deserializes objects are subject to this vulnerability.
> This is similar to CVE-2015-3253 but this exploit involves extra
> wrapping of objects and catching of exceptions which are now safe
> guarded against.
> Mitigation:
> Users of Groovy relying on (de)serialization with the affected versions
> should apply one of the following mitigations:
> * Isolate the code doing the (de)serialization
> * Upgrade to Apache Groovy 2.4.8 or later
> * Users of older versions of Groovy can apply the following patch to the
> `MethodClosure` class
> (`src/main/org/codehaus/groovy/runtime/MethodClosure.java`):
> ```
> public class MethodClosure extends Closure {
> +private void readObject(java.io.ObjectInputStream stream) throws
> IOException, ClassNotFoundException {
> +if (ALLOW_RESOLVE) {
> +stream.defaultReadObject();
> +}
> +throw new UnsupportedOperationException();
> +}
> ```
> Credit:
> This vulnerability was discovered by:
> * Sam Thomas of Pentest Limited working with Trend Micro's Zero Day
> Initiative
> History:
> * 2016-09-20 Original advisory
> * 2017-01-12 Updated information on affected versions
> References:
> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6814
> * http://groovy-lang.org/security.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TINKERPOP-1610) Deprecate gremlin-groovy-test provider based tests
[ https://issues.apache.org/jira/browse/TINKERPOP-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1610. --- Resolution: Done Fix Version/s: 3.2.4 > Deprecate gremlin-groovy-test provider based tests > -- > > Key: TINKERPOP-1610 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1610 > Project: TinkerPop > Issue Type: Improvement > Components: groovy >Affects Versions: 3.2.3 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Minor > Fix For: 3.2.4 > > > Given TINKERPOP-1515 and the revised method for testing GLVs we no longer > need to require graph providers to test against the groovy environment. Those > tests can be deprecated for 3.2.4 and then removed in a later version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
