i probably should have added in my last post that AutoCloseable.close() would already be our blocking method, no?. You're trying to add an async type method to Graph, no?
Future closeAsync() On Tue, Oct 6, 2015 at 10:05 AM, Bryn Cooke <[email protected]> wrote: > > >> a Future makes sense though that would be a separate method right? >> AutoCloseable.close() doesn't return Future. >> > > Perhaps the new method could be called 'join' and it blocks until the > graph is fully closed. > I'm taking inspiration from embedded jetty. > > > > > On Tue, Oct 6, 2015 at 9:15 AM, Bryn Cooke <[email protected]> wrote: >> >> Hi, >>> >>> I'm not sure what the answer is here, >>> >>> What I am sure of is that the goal of close should be a graceful >>> shutdown. >>> Once a resource is closed then it should not accept new requests. >>> Descendant resources may or may not continue to be operational, for >>> instance you may allow ongoing transactions to complete but that is >>> implementation dependent. >>> >>> The question is after calling close when how can you be sure that all >>> descendant resources are finished before returning to the user? Only by >>> keeping references to all spawned resources can you tell. >>> >>> Perhaps Graph.close() should return a Future. That way you can block >>> until >>> the graph is actually closed. >>> >>> Bryn >>> >>> >>> >>> >>> >>> On 05/10/15 20:56, Stephen Mallette wrote: >>> >>> There are two tickets in JIRA that relate to the semantics of closing and >>>> releasing resources in the Graph hierarchy: >>>> >>>> + Graph >>>> + TraversalSource >>>> + TraversalStrategy >>>> + GraphTraversal >>>> + Transaction >>>> >>>> https://issues.apache.org/jira/browse/TINKERPOP3-789 >>>> https://issues.apache.org/jira/browse/TINKERPOP3-790 >>>> >>>> There's been some discussion on them already. I bring this to >>>> everyone's >>>> attention as the change could have wide repercussions depending on the >>>> direction it goes. The short of the matter is that currently: >>>> >>>> 1. Graph implements AutoCloseable, but we don't enforce the notion of >>>> close() itself in the test suite. >>>> 2. TraversalSource should likely implement AutoCloseable as there are >>>> sometimes resources that need to be released when a TraversalSource is >>>> no >>>> longer in use. >>>> 3. Transaction implements AutoCloseable but it applies in the context of >>>> how a Transaction will behave when Graph.close() is called. >>>> >>>> Where is this all going? Matt Frantz summarized the thought points >>>> nicely >>>> in this comment: >>>> >>>> >>>> >>>> https://issues.apache.org/jira/browse/TINKERPOP3-790?focusedCommentId=14710389&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14710389 >>>> >>>> Basically, there's two options Matt identified: >>>> >>>> 1. Making it so that Graph.close() would release resources and >>>> effectively >>>> close() all things it spawned is one approach, but I''m not sure how >>>> straightforward/practical to implement that is. I suspect it will >>>> complicate Graph implementations as well. >>>> 2. The alternative is that the things in this hierarchy can have their >>>> own >>>> expensive resources which can be independently closed. I think that >>>> this >>>> approach more closely fits with the code as we have it now and won't >>>> unduly >>>> burden implementers. TinkerPop Developers will have to know when to >>>> call >>>> close() (e.g. if a TraversalStrategy has expensive resources and the >>>> user >>>> assumes that a call to TraversalSource.close() will release those >>>> resources, then they might be wrong - depends on the approach we decide >>>> on). >>>> >>>> When I first created 790, i had the second option in mind, but since >>>> Matt >>>> brought wrote that comment, i figured it was worth thinking through as a >>>> whole. >>>> >>>> Once that is decided then we should figure out 789 which is how to >>>> enforce >>>> the semantics of close() (e.g. what does a Graph do when it's closed and >>>> someone calls graph.traversal()?). >>>> >>>> Thoughts? >>>> >>>> >>>> >
