Hi,
I think a problem with this is that it requires every step implementation to
have this construct in it -- though many steps simply extend the base
FlatMapStep, MapStep, FilterStep, etc. However, not all and thus, this requires
all providers to know what this about and write their code accordingly.
A few questions:
1. In OLAP, where there can be multiple threads how does this work?
2. In Giraph/Spark, how does this effect job execution and failure
responses?
3. When we move into threaded OLTP, how will this be triggered/effected?
4. This doesn't work for "infinite loop" lambdas or "hung databases."
I know this is the oldest ticket in the books and a million solutions have been
proposed, but it would be nice if this didn't require specialized code in all
the steps. We are bound to "forget."
Thanks,
Marko.
http://markorodriguez.com
On Apr 18, 2016, at 8:56 AM, Stephen Mallette <[email protected]> wrote:
> Do you mean:
>
> if (Thread.currentThread().isInterrupted()) throw new
> TraversalInterruptedException();
>
> If so, Thread.interrupted() basically does that under the covers
>
> On Mon, Apr 18, 2016 at 10:51 AM, Ted Wilmes <[email protected]> wrote:
>
>> Yeah, looks like benchmark-wise it's a wash, which is good. I wasn't aware
>> of the difference between the static interrupted() and non-static
>> isInterrupted(). I was wondering if in this case it should be
>> isInterrupted(), but I think how you did it is good because it'll be
>> evaluated within the traversal thread regardless.
>>
>> --Ted
>>
>> On Mon, Apr 18, 2016 at 6:11 AM, Stephen Mallette <[email protected]>
>> wrote:
>>
>>> A while back, I brought up the issue of being able to interrupt
>> traversals:
>>>
>>>
>>>
>> https://pony-poc.apache.org/thread.html/e6477fc9c58d37a5bdcb5938a0eaa285456ad15aa39e16446290e2ff@1444993523@%3Cdev.tinkerpop.apache.org%3E
>>> https://issues.apache.org/jira/browse/TINKERPOP-946
>>>
>>> As a quick refresher, making Traversal respect Thread.interrupted() is
>>> important as you otherwise can quite easily lock up applications like
>>> Gremlin Server with a few poorly conceived or errant queries. We'd left
>>> that last thread with liking the idea, but there were concerns about the
>>> complexity of the changes and performance hits.
>>>
>>> Given that we now have gremlin-benchmark, I decided to see what the
>>> performance hit would be for making this change. I took a rough stab at
>> it
>>> introducing Thread.interrupted() in all steps where it seemed to make
>> sense
>>> to do so and then ran the benchmark before and after the change.
>>>
>>> https://gist.github.com/spmallette/ed21267f2e7e17bb3fbd5a8d1a568d2b
>>>
>>> I'm not seeing a whole lot of difference between supporting this feature
>>> and not supporting this feature. Here's the branch I implemented this in
>>> in case you want to look around:
>>>
>>> https://github.com/apache/incubator-tinkerpop/tree/TINKERPOP-946
>>>
>>> I'm not sure that my changes are completely bulletproof at this point,
>> but
>>> I'm reasonably sure that these changes would handle a good majority of
>>> calls for thread interruption. I expect to re-target my branch at tp31
>>> (currently from master so that i could use the benchmark suite) if this
>>> becomes a pull request.
>>>
>>> Any thoughts on the benchmark, the implementation, etc?
>>>
>>
