[jira] [Created] (TINKERPOP-1830) Race condition in Tinkergraph index creation
Michael Pollmeier created TINKERPOP-1830: Summary: Race condition in Tinkergraph index creation Key: TINKERPOP-1830 URL: https://issues.apache.org/jira/browse/TINKERPOP-1830 Project: TinkerPop Issue Type: Bug Components: tinkergraph Affects Versions: 3.2.6, 3.3.0 Reporter: Michael Pollmeier Priority: Minor Fix For: 3.2.7, 3.3.1 My colleage Fabian Yamaguchi discovered a race condition in tinkergraph's index creation. He fixed it by simply replacing `parallelStream` with `stream`. Quoting his analysis: > So, reading the code, you see that this.put is called in parallel, but that > method seems to contain a race as get is called on the index, checked for > null, and a subsequent write is performed. It still seems like using stream > here fixes the problem we've been seeing, and the performance hit is not > significant. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1822) Repeat should depth first search
[ https://issues.apache.org/jira/browse/TINKERPOP-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16227421#comment-16227421 ] Michael Pollmeier commented on TINKERPOP-1822: -- Since all other steps are DFS by default (for OLTP at least), I think this should really be the new default. If there are reasons to keep the default BFS, it should be well documented, together with notes how to make it DFS. See also https://stackoverflow.com/questions/47013872/tinkerpop-gremlin-depth-first-search-order/47030551 > Repeat should depth first search > > > Key: TINKERPOP-1822 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1822 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.3.0, 3.2.6 >Reporter: Robert Dale > > Perhaps optionally. > See also: > * https://groups.google.com/forum/#!topic/gremlin-users/gLSLxH_K-wE > * https://github.com/apache/tinkerpop/pull/715 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[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&focusedCommentId=15455906#comment-15455906
]
Michael Pollmeier commented on TINKERPOP-1230:
--
Thanks for your thoughts Stephen. Dropping additional libs into DSE sounds
doable yet dangerous. If I did so, would I be able to call my code though?
I'd need some plugin system, e.g. to define an endpoint that's being exposed
that then calls my code. If I read the OpProcessor interface right then this
could do it for websocket? Is there a similar way for http?
> 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
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Fix For: 3.2.2
>
>
> 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-1230) Serialising lambdas for RemoteGraph
[
https://issues.apache.org/jira/browse/TINKERPOP-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15449827#comment-15449827
]
Michael Pollmeier commented on TINKERPOP-1230:
--
Sorry for mixing up the versions of documentation. The 'lambda' solution is
sending code as strings over the wire, that's not quite what I had in mind. It
doesn't really matter for dynamic languages, but if used with a statically
compiled language like Scala or Java you lose all the help from the compiler /
IDE.
I see what you're saying re my lambda serialisation project - not ideal.
Another option would be to allow to extend gremlin-server with some endpoints
and additional libraries - the current plugin system is not powerful enough for
that task, is it?
One of the things I'm trying to figure out is how I can use Gremlin-Scala with
DSE graph. I'm having a hard time to see how that could work, since DSE is
closed source and doesn't really allow to extend it with additional libraries.
But since DSE doesn't have a remote protocol (unlike Titan) and I can't really
send remote queries to the integrated Gremlin Server (at least not without
losing all the help from the compiler), I don't currently see a way to
integrate with it. If this is not the right place to discuss such matters, just
let me know - maybe chat is better?
> 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
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Fix For: 3.2.2
>
>
> 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-1230) Serialising lambdas for RemoteGraph
[
https://issues.apache.org/jira/browse/TINKERPOP-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15446628#comment-15446628
]
Michael Pollmeier commented on TINKERPOP-1230:
--
[~spmallette] hmm, really? 1278 is mainly about generating groovy strings from
other languages if I read it right? And the tutorial
(http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/)
states "Lambdas are not supported". Can you clarify please?
> 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
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Fix For: 3.2.2
>
>
> 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)
