[
https://issues.apache.org/jira/browse/TINKERPOP-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633004#comment-15633004
]
ASF GitHub Bot commented on TINKERPOP-1490:
-------------------------------------------
Github user newkek commented on the issue:
https://github.com/apache/tinkerpop/pull/478
The issue with using a secondary thread pool that will start a new thread
for each Traversal execution would be more important when the Traversal is
backed by a RemoteConnection. Where each Traversal represents a "query" that is
sent to a server, if the driver behind the RemoteConnection is able to handle
tens of thousands of requests, the performance will still be limited to the
number of threads the async thread pool can handle simultaneously, and there
would be a big waste of CPU/Threads.
Ideally as @jorgebay suggests with the strategies more of the TinkerPop lib
would be changed to become fully async, where maybe synchronous methods would
only be blocking calls to the async execution method(s) (`next()` calls
`promise().get()`).
The thread pool is still needed at some point though, since executing
against a local TinkerGraph is currently done in the same thread, as a
sequential operation so Returning with a Future, and Continuing to process the
operation in the background has to be done in 2 separate threads simultaneously.
_just thinking out loud and I probably miss a lot of details_ There may be
a way to have a method `submitAsync()` on the `RemoteConnection` that returns a
Future of Traverser (instead of Traverser) that, associated with what @jorgebay
suggests for the Strategies and _some other changes_ would allow the
`promise()` call, when associated with a `RemoteConnection` not to create a new
thread each time by default and simply return the Future returned with
`RemoteConnection#submitAsync()`, and thus delegate the asynchronous execution
to the RemoteConnection
> Provider a Future based Traversal.async(Function<Traversal,V>) terminal step
> ----------------------------------------------------------------------------
>
> Key: TINKERPOP-1490
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1490
> Project: TinkerPop
> Issue Type: Improvement
> Components: language-variant, process
> Affects Versions: 3.2.2
> Reporter: Marko A. Rodriguez
>
> [~mbroecheler] had the idea of adding a {{Traversal.async()}} method. This is
> important for not only avoiding thread locking on a query in Gremlin, but
> also, it will allow single threaded language variants like Gremlin-JavaScript
> to use callbacks for processing query results.
> {code}
> Future<List<String>> result =
> g.V().out().values("name").async(Traversal::toList)
> {code}
> {code}
> Future<List<String>> result = g.V().out().name.async{it.toList()}
> {code}
> {code}
> g.V().out().values('name').async((err,names) => {
> // I don't know JavaScript, but ...
> return list(names);
> })
> {code}
> ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
