Безопасна ли реализация com.tinkerpop.pipes.Pipe для кеширования и последующего повторного использования в других экземплярах графа?

В настоящее время я создаю трубу, как показано в строке 2 ниже.

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

После того, как он был создан, я кэширую его, чтобы его можно было повторно использовать с разными графиками ниже.

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

Мне интересно, хорошо ли это? Я спрашиваю, потому что javadoc из AbstractPipe говорит

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>

person Aravind Yarram    schedule 03.07.2015    source источник


Ответы (1)


Я никогда не доверял reset, несмотря на то, что написано в javadocs по этому поводу, однако этот тест, похоже, работает:

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

Вызов setStarts, кажется, правильно сбрасывает итератор внутри канала, но reset сам по себе не имеет большого эффекта:

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

С учетом всего сказанного, я не уверен, что кеширование Pipeline так сильно вас спасает. Создание Pipeline довольно дешево, и Gremlin.compile() сам кэширует сценарий после компиляции, поэтому будущие вызовы для «воссоздания» этого конвейера должны быть значительно быстрее, чем первый вызов compile.

person stephen mallette    schedule 03.07.2015
comment
Мы провели тестирование параллелизма с кэширующими конвейерами и обнаружили, что они действительно не являются потокобезопасными. Мы получали прерывистые исключения FastNoSuchElementException. Мы видим их даже после вызова сброса после их использования. Поэтому лучше обновить JavaDoc, чтобы упомянуть, что реализации Pipe не являются потокобезопасными. Этот пост также помогает: stackoverflow.com/questions/13151141/ - person Aravind Yarram; 04.07.2015
comment
Мы провели еще один тест. Создавая трубы каждый раз, ошибки значительно сокращались. Тем не менее, я все еще вижу это исключение 50 раз в миллионах запросов. Вы предлагаете какой-либо подход к отладке этого? Причина, по которой я спрашиваю, заключается в том, что это исключение не захватывает трассировку стека или основную причину - person Aravind Yarram; 08.07.2015
comment
какое исключение? - person stephen mallette; 08.07.2015
comment
com.tinkerpop.pipes.util.FastNoSuchElementException без трассировки стека ... это происходит периодически. С ним не связана трассировка стека на основе tinkerpop.com/docs/javadocs/pipes/2.3.0/com/tinkerpop/pipes/ - person Aravind Yarram; 08.07.2015
comment
Если вы получаете FastNoSuchElementException и каждый раз создаете новые каналы, я предполагаю, что у вас что-то не так с запросом или неверные ожидания относительно ваших данных. Можете ли вы каким-то образом индивидуально проверить 50 сбоев, чтобы убедиться, что они действительно возвращают данные? - person stephen mallette; 08.07.2015
comment
Остальные проблемы возникли из-за неправильно написанного гремлина. Спасибо. Интересно, почему трассировка стека подавлена ​​в этом исключении. - person Aravind Yarram; 16.07.2015
comment
Рад, что он работает. Насколько я понимаю, это компромисс с FastNoSuchElementException - он избегает заполнения трассировки стека, что довольно медленно. Таким образом, вы получите свое исключение быстрее, но за счет проблем с отладкой. конечно, я узнал, что это исключение просто означает одно из двух: я неправильно написал свой Гремлин или что-то в моих данных не так. Такой подход к обработке исключений все еще присутствует в TP3, но с возможностями профилирования TP3, я чувствую, что может быть легче отлаживать, когда возникают такие проблемы. - person stephen mallette; 16.07.2015