0

I am currently create a Pipe as shown in line 2 below. 

Pipe pipe = Gremlin.compile("_().out('knows').name");

After it has been created I am caching it so that it can be re-used with different graphs below

Graph graph = TinkerGraphFactory.createTinkerGraph();
pipe.setStarts(new SingleIterator<Vertex>(graph.getVertex(1)));
for(Object name : pipe) 
{
  System.out.println((String) name);
}

I am wondering if this is alright? I ask because the javadoc of AbstractPipe says

public void reset()
Description copied from interface: Pipe
A pipe may maintain state. Reset is used to remove state. The general use case for reset() is to reuse a pipe in another computation without having to create a new Pipe object. An implementation of this method should be recursive whereby the starts (if a Pipe) should have this method called on it.
Specified by:
reset in interface Pipe<S,E>
stephen mallette
  • 45,298
  • 5
  • 67
  • 135
Aravind Yarram
  • 78,777
  • 46
  • 231
  • 327

1 Answers1

1

I've never trusted reset despite what the javadocs say on the matter, however this test seems to work:

gremlin> pipe = _().out('knows').name;null              
==>null
gremlin> pipe.setStarts(new SingleIterator<Vertex>(g.getVertex(1)));    
==>null
gremlin> pipe
==>vadas
==>josh
gremlin> pipe
gremlin> pipe.setStarts(new SingleIterator<Vertex>(g.getVertex(1)));
==>null
gremlin> pipe                                                       
==>vadas
==>josh

Calling setStarts seems to properly reset the iterator within the pipe, but reset on its own doesn't seem to have much effect:

gremlin> pipe.setStarts(new SingleIterator<Vertex>(g.getVertex(1)));
==>null
gremlin> pipe                                                       
==>vadas
==>josh
gremlin> pipe.reset()
==>null
gremlin> pipe
gremlin>

All that said, I'm not sure caching the Pipeline is saving you all that much. Pipeline creation is pretty cheap and Gremlin.compile() itself caches the script after compilation so future calls to "recreate" that pipeline should be considerably faster than the first call to compile.

stephen mallette
  • 45,298
  • 5
  • 67
  • 135
  • We did concurrency testing with caching Pipes and found that they are indeed not thread-safe. We were getting intermittent FastNoSuchElementException's. We are seeing them even after calling reset after their use. So it is better to update JavaDoc to mention that Pipe implementations aren't thread-safe. This post also helps: http://stackoverflow.com/questions/13151141/gremlin-when-storing-a-gremlingroovypipeline-and-calling-count-on-it – Aravind Yarram Jul 04 '15 at 00:30
  • We have run another test. Creating Pipes every time, borught down the errors considerably. However, I am still seeing this exception 50 times in million requests. Do you suggest any approach to debug this? The reason i ask is because this exception doesn't capture stacktrace or root cause – Aravind Yarram Jul 08 '15 at 16:25
  • what is the exception? – stephen mallette Jul 08 '15 at 16:51
  • com.tinkerpop.pipes.util.FastNoSuchElementException with no stacktrace...it is occuring intermittently. This doesn't have stacktrace associated with it based on http://www.tinkerpop.com/docs/javadocs/pipes/2.3.0/com/tinkerpop/pipes/util/FastNoSuchElementException.html – Aravind Yarram Jul 08 '15 at 17:58
  • if you are getting `FastNoSuchElementException` and you are creating the pipes fresh every time, my guess is that you have something wrong with the query or incorrect expectations about your data. can you individually validate the 50 failures in some way to be sure they actually return data? – stephen mallette Jul 08 '15 at 18:28
  • The remaining issues were due to wrongly written gremlin. Thx. I wonder why the stacktrace is supressed in this exception. – Aravind Yarram Jul 16 '15 at 12:01
  • Glad it's working. As I understand it, that's the trade-off with `FastNoSuchElementException` - it avoid filling the stacktrace which is kinda slow. So you get your exception faster but at the cost of debug problems. of course, i've come to know that exception as simply meaning one of two things: "I wrote my Gremlin wrong" or "There's something in my data that's amiss". That approach to exception handling is still in TP3, but with the profiling capabilities of TP3, I have a feeling it might be easier to debug when such problems arise. – stephen mallette Jul 16 '15 at 12:07