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
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
