"It's not clear to me if the problem exists in HSQLDB, the test, or tail
step"
This had nothing to do with the TailStep bug. That one is resolved for
the most part.
For the rest, where the problem is, is itself part of the problem.
Thread.interrupt() has rather weak semantics having many differen
Trying to summarize the concerns I think I'm hearing:
1. cancelling the gremlin job
2. cancelling the task in the backend database, this implies handling
at minimum:
a. commit state: interruptable
b: rollback state: probably not interruptable
3. responding to the client, returning the thread
S
Ok, np, its not serious, Postgres is the important one for me anyhow and
it is behaving. I'll investigate how to tell Postgres to cancel the
query. Just stopping the traversal is not quite good enough as every now
and again we have queries on Postgres that persist even if the java
thread dies.
Than
> For every traversal that starts it notifies the caller via the reference
object about the traversal.
that's the tricky bit. you'd have to have some global tracking of spawned
traversals to know that and it would have to be bound to the Thread that
started it I guess. That information isn't going
Well no, the problem is Thread.interrupted() is not reliable. Does not
really matter who the caller is, GremlinServer or other.
Just about every 3rd party library I can see might reset the flag
meaning that the check will randomly return false or true. Something as
trivial as a logger might even re
thanks for all that pieter. the primary reason for traversal interruption
in the first place was so that gremlin server would have a chance to kill
traversals that were running too long. Without a solution to that problem,
I'm not sure what to do here. just tossing ideas around - could we still
che
I just did a global Intellij search in the Sqlg project.
HSQLDB has 13 catch (InterruptedException e) clauses. All of them
swallows the exception and none resets the interrupt flag.
Postgresql jdbc driver has 3 catch (InterruptedException e) clauses. 2
swallows the exception without resetting the
I don't recall all the issues with doing traversal interruption with a
flag. I suppose it could work in the same way that thread interruption
works now. I will say that I'm hesitant to say that we should change this
on the basis of this being a problem general to databases as we've only
seen in so
The current interrupt implementation is failing on Sqlg's HSQLDB
implementation.
The reason for this is that HSQLDB itself relies on Thread.interrupt()
for its own internal logic. When TinkerPop interrupts the thread it
thinks it has to do with its own logic and as a result the interrupt
flag is re
