You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Stephen Mallette <sp...@gmail.com> on 2016/12/28 13:27:52 UTC

[DISCUSS] Bring back CloseableIterable

In TinkerPop 2.x we had a CloseableIterable class which allowed graphs like
Sparksee and OrientDB to release server resources. Luca recently brought up
this topic on the gremlin-users mailing list:

https://groups.google.com/d/msg/gremlin-users/lHepXl_Nle4/n3QeYqmNCwAJ

Is there any way to implement this without having something like
CloseableIterable? Traversal already implements AutoCloseable which could
call close() to the underlying iterator. We use close() for remoting
Traversals at this point. There is nothing analogous for a standard
traversal instance.

Thoughts?

Re: [DISCUSS] Bring back CloseableIterable

Posted by Stephen Mallette <sp...@gmail.com>.
Since there hasn't been any objections since i posted this about a week
ago, I think we can assume consensus on getting CloseableIterator into
TinkerPop. I just created this issue in JIRA with more details -
specifically I outline how we could go about adding CloseableIterator to
the Structure API:

https://issues.apache.org/jira/browse/TINKERPOP-1589



On Thu, Dec 29, 2016 at 9:37 AM, Luca Garulli <l....@gmail.com> wrote:

> An automatic close after a timeout it could be nice to have, but it could
> make the behaviour unpredictable.
>
> I'd definitely prefer the iterators implement the AutoCloseable interface,
> so this makes the code more clean and allow the user to close() a result
> when it's not needed anymore.
>
> On 28 December 2016 at 17:12, Paul Jackson <be...@gmail.com> wrote:
>
> > +1
> >
> > The obvious/preferred route (for me), since the vertices() and edges()
> > methods in org.apache.tinkerpop.gremlin.structure.Graph return Iterator,
> > is to have them return an interface that extends Iterator and
> > AutoCloseable. If you create a new interface in 3.x for this, it would
> > probably be CloseableIterator rather than the CloseableIterable of 2.x.
> >
> > Alternative (messy) could make Graph responsible for this. Have it
> > register each iterator and close it after period of inactivity exceeds a
> > timeout, or if the Graph itself is closed. That's all I got.
> >
> > -Paul
> >
> >
> > On 2016-12-28 08:27 (-0500), Stephen Mallette <sp...@gmail.com>
> > wrote:
> > > In TinkerPop 2.x we had a CloseableIterable class which allowed graphs
> > like
> > > Sparksee and OrientDB to release server resources. Luca recently
> brought
> > up
> > > this topic on the gremlin-users mailing list:
> > >
> > > https://groups.google.com/d/msg/gremlin-users/lHepXl_Nle4/n3QeYqmNCwAJ
> > >
> > > Is there any way to implement this without having something like
> > > CloseableIterable? Traversal already implements AutoCloseable which
> could
> > > call close() to the underlying iterator. We use close() for remoting
> > > Traversals at this point. There is nothing analogous for a standard
> > > traversal instance.
> > >
> > > Thoughts?
> > >
> >
>

Re: [DISCUSS] Bring back CloseableIterable

Posted by Luca Garulli <l....@gmail.com>.
An automatic close after a timeout it could be nice to have, but it could
make the behaviour unpredictable.

I'd definitely prefer the iterators implement the AutoCloseable interface,
so this makes the code more clean and allow the user to close() a result
when it's not needed anymore.

On 28 December 2016 at 17:12, Paul Jackson <be...@gmail.com> wrote:

> +1
>
> The obvious/preferred route (for me), since the vertices() and edges()
> methods in org.apache.tinkerpop.gremlin.structure.Graph return Iterator,
> is to have them return an interface that extends Iterator and
> AutoCloseable. If you create a new interface in 3.x for this, it would
> probably be CloseableIterator rather than the CloseableIterable of 2.x.
>
> Alternative (messy) could make Graph responsible for this. Have it
> register each iterator and close it after period of inactivity exceeds a
> timeout, or if the Graph itself is closed. That's all I got.
>
> -Paul
>
>
> On 2016-12-28 08:27 (-0500), Stephen Mallette <sp...@gmail.com>
> wrote:
> > In TinkerPop 2.x we had a CloseableIterable class which allowed graphs
> like
> > Sparksee and OrientDB to release server resources. Luca recently brought
> up
> > this topic on the gremlin-users mailing list:
> >
> > https://groups.google.com/d/msg/gremlin-users/lHepXl_Nle4/n3QeYqmNCwAJ
> >
> > Is there any way to implement this without having something like
> > CloseableIterable? Traversal already implements AutoCloseable which could
> > call close() to the underlying iterator. We use close() for remoting
> > Traversals at this point. There is nothing analogous for a standard
> > traversal instance.
> >
> > Thoughts?
> >
>

Re: [DISCUSS] Bring back CloseableIterable

Posted by Paul Jackson <be...@gmail.com>.
+1

The obvious/preferred route (for me), since the vertices() and edges() methods in org.apache.tinkerpop.gremlin.structure.Graph return Iterator, is to have them return an interface that extends Iterator and AutoCloseable. If you create a new interface in 3.x for this, it would probably be CloseableIterator rather than the CloseableIterable of 2.x.

Alternative (messy) could make Graph responsible for this. Have it register each iterator and close it after period of inactivity exceeds a timeout, or if the Graph itself is closed. That's all I got.

-Paul


On 2016-12-28 08:27 (-0500), Stephen Mallette <sp...@gmail.com> wrote: 
> In TinkerPop 2.x we had a CloseableIterable class which allowed graphs like
> Sparksee and OrientDB to release server resources. Luca recently brought up
> this topic on the gremlin-users mailing list:
> 
> https://groups.google.com/d/msg/gremlin-users/lHepXl_Nle4/n3QeYqmNCwAJ
> 
> Is there any way to implement this without having something like
> CloseableIterable? Traversal already implements AutoCloseable which could
> call close() to the underlying iterator. We use close() for remoting
> Traversals at this point. There is nothing analogous for a standard
> traversal instance.
> 
> Thoughts?
>