Re: TP4 Processors now support both push- and pull-based semantics.

[bryncooke]

On 2019/04/24 12:19:54, Marko Rodriguez  wrote: 
> Hello,
> 
> > I think it would be better to either expose Flowable on the API (or Flow if 
> > you don't want to be tied in to RxJava)
> 
> We definitely don’t want to expose anything “provider specific.” Especially 
> at the Processor interface level. I note your Flow API reference in 
> java.concurrent and have noticed that RxJava mimics many java.concurrent 
> classes (Subscriber, Subscription, etc.). I will dig deeper.
> 
> > 1. Using Consumer will break the Rx chain. This is undesirable as it will 
> > prevent backpressure and cancellation from working properly.
> 
> Understood about breaking the chain.
> 
> > 2. The Scheduler to run the traversal on can be set. For instance, in the 
> > case where only certain threads are allowed to perform IO once the user has 
> > the Flowable they can call subscribeOn before subscribe.
> > 3. Backpressure strategy can be set, such as dropping results on buffer 
> > overflow.
> > 4. Buffer size can be set.
> 
> Hm. Here are my thoughts on the matter.
> 
> RxJava is just one of many Processors that will interact with TP4. If we 
> start exposing backpressure strategies, buffer sizes, etc. at the Processor 
> API level, then we expect other providers to have those concepts. Does Spark 
> support backpressure? Does Hadoop? Does Pipes? ...
> 
> I believe such provider-specific parameterization should happen via 
> language-agnostic configuration. For instance:
> 
> g = g.withProcessor(RxJavaProcessor.class, Map.of(“rxjava.backpressure”, 
> “drop”, “rxjava.bufferSize”, 2000))
> g.V().out().blah()
> 
> Unlike TP3, TP4 users will never interact with our Java API. They will never 
> have a reference to a Processor instance. They only talk to the TP4 VM via 
> Bytecode. However, with that said, systems that will integrate the TP4 VM 
> (e.g. database vendors, data server systems, etc.) will have to handle 
> Processor traverser results in some way (i.e. within Java). Thus, if they are 
> a Reactive architecture, then they will want to be able to Flow, but we need 
> to make sure that java.concurrent Flow semantics doesn't go too far in 
> demanding “unreasonable” behaviors from other Processor implementations. (I 
> need to study the java.concurrent Flow API)
> 
> Thus, I see it like this:
> 
>   1. RxJava specific configuration is not available at the Process API 
> level (only via configuration).
>   2. Drop Consumer and expose java.concurrent Flow in Processor so the 
> chain isn’t broken for systems integrating the TP4 VM.
>   - predicated on java.concurrent Flow having reasonable 
> expectations of non-reactive sources (i.e. processors).
> 
> Does this make sense to you?
> 
> ———
> 
> Stephen said you made a comment regarding ParallelRxJava as not being 
> necessary. If this is a true statement, can you explain your thoughts on 
> ParallelRxJava. My assumptions regarding serial vs. parallel:
> 
>   1. For TP4 VM vendors in a highly concurrent, multi-user environment, 
> multi-threading individual queries is bad.
>   2. For TP4 VM vendors in a lowly concurrent, limited-user environment, 
> multi-threading a single query is good.
>   - also related to the workload — e.g. ParallelRxJava for an AI 
> system where one query at a time is happening over lots of data.
> 
> Thank you for your feedback,
> Marko.
> 
> http://rredux.com 
> 
> 
> 
> 
> > On Apr 24, 2019, at 3:41 AM, brynco...@gmail.com wrote:
> > 
> > 
> > 
> > On 2019/04/23 13:07:09, Marko Rodriguez  > > wrote: 
> >> Hi,
> >> 
> >> Stephen and Bryn were looking over my RxJava implementation the other day 
> >> and Bryn, with his British accent, was like [I paraphrase]:
> >> 
> >>“Whoa dawg! Bro should like totally not be blocking to fill an 
> >> iterator. Gnar gnar for surezies.”
> >> 
> >> Prior to now, Processor implemented Iterator, where for RxJava, 
> >> when you do next()/hasNext() if there were no results in the queue and the 
> >> flowable was still running, then the iterator while()-blocks waiting for a 
> >> result or for the flowable to terminate.
> >> 
> >> This morning I decided to redo the Processor interface (and respective 
> >> implementations) and it is much nicer now. We have two “execute” methods:
> >> 
> >> IteratorProcessor.iterator(Iterator starts)
> >> void Processor.subscribe(Iterator starts, Consumer 
> >> consumer)
> >> 
> >> A processor can only be executed using one of the methods above. Thus, 
> >> depending on context and the underlying processor, the VM determines 
> >> whether to use pull-based or push-based semantics. Pretty neat, eh?
> >> 
> >>
> >> https://github.com/apache/tinkerpop/blob/tp4/java/machine/machine-core/src/main/java/org/apache/tinkerpop/machine/processor/Processor.java
> >>  
> >> 

Re: TP4 Processors now support both push- and pull-based semantics.

[bryncooke]

On 2019/04/23 13:07:09, Marko Rodriguez  wrote: 
> Hi,
> 
> Stephen and Bryn were looking over my RxJava implementation the other day and 
> Bryn, with his British accent, was like [I paraphrase]:
> 
>   “Whoa dawg! Bro should like totally not be blocking to fill an 
> iterator. Gnar gnar for surezies.”
> 
> Prior to now, Processor implemented Iterator, where for RxJava, 
> when you do next()/hasNext() if there were no results in the queue and the 
> flowable was still running, then the iterator while()-blocks waiting for a 
> result or for the flowable to terminate.
> 
> This morning I decided to redo the Processor interface (and respective 
> implementations) and it is much nicer now. We have two “execute” methods:
> 
> Iterator   Processor.iterator(Iterator starts)
> void Processor.subscribe(Iterator starts, Consumer 
> consumer)
> 
> A processor can only be executed using one of the methods above. Thus, 
> depending on context and the underlying processor, the VM determines whether 
> to use pull-based or push-based semantics. Pretty neat, eh?
> 
>   
> https://github.com/apache/tinkerpop/blob/tp4/java/machine/machine-core/src/main/java/org/apache/tinkerpop/machine/processor/Processor.java
>  
> 
> 
> Check out how I do Pipes:
> 
>   
> https://github.com/apache/tinkerpop/blob/tp4/java/machine/processor/pipes/src/main/java/org/apache/tinkerpop/machine/processor/pipes/Pipes.java#L113-L126
>  
> 
> 
> Pipes is inherently pull-based. However, to simulate push-based semantics, I 
> Thread().start() the iterator.hasNext()/next() and just consume.accept() the 
> results. Thus, as desired, subscribe() returns immediately.
> 
> Next, here is my RxJava implementation.
> 
>   
> https://github.com/apache/tinkerpop/blob/tp4/java/machine/processor/rxjava/src/main/java/org/apache/tinkerpop/machine/processor/rxjava/SerialRxJava.java#L59-L65
>  
> 
>   
> https://github.com/apache/tinkerpop/blob/tp4/java/machine/processor/rxjava/src/main/java/org/apache/tinkerpop/machine/processor/rxjava/AbstractRxJava.java#L66-L86
>  
> 
> 
> You can see how I turn a push-based subscription into a pull-based iteration 
> using the good ‘ol while()-block :).
> 
>   
> https://github.com/apache/tinkerpop/blob/tp4/java/machine/processor/rxjava/src/main/java/org/apache/tinkerpop/machine/processor/rxjava/AbstractRxJava.java#L98-L102
>  
> 
> 
> ——
> 
> What I need to do next is to redo the RxJava execution planner such that 
> nested traversals (e.g. map(out( are subscription-based with the parent 
> flowable. I don’t quite know how I will do it — but I believe I will have to 
> write custom Publisher/Subscriber objects for use with Flowable.compose() 
> such that onNext() and onComplete() will be called accordingly within the 
> consumer.accept(). It will be tricky as I’m not too good with low-level 
> RxJava, but thems the breaks.
> 
> Please note that my push-based conceptual skills are not the sharpest so if 
> anyone has any recommendations, please advise.
> 
> Take care,
> Marko.
> 
> http://rredux.com 
> 
> 
> 
> 
> 

Hi Marko,

I think it would be better to either expose Flowable on the API (or Flow if you 
don't want to be tied in to RxJava)

void Processor.subscribe(Iterator starts, Consumer 
consumer)
Changes to:
Flowable Processor.flowable(Iterator starts)

There are a few of reasons to do this:
1. Using Consumer will break the Rx chain. This is undesirable as it will 
prevent backpressure and cancellation from working properly.
2. The Scheduler to run the traversal on can be set. For instance, in the case 
where only certain threads are allowed to perform IO once the user has the 
Flowable they can call subscribeOn before subscribe.
3. Backpressure strategy can be set, such as dropping results on buffer 
overflow.
4. Buffer size can be set.

Hope this helps,

Bryn

Re: [DISCUSS] ReferenceStrategy

[bryncooke]

On 2018/10/22 18:21:13, Stephen Mallette  wrote: 
> https://issues.apache.org/jira/browse/TINKERPOP-2075
> 
> On Mon, Oct 8, 2018 at 1:37 PM Stephen Mallette 
> wrote:
> 
> > > I'd like to propose 2a. Update Gremlin Server and TinkerGraph to behave
> > in the desired way, this would set the tone for all Graph implementations
> > to eventually adopt this consistent behaviour.
> >
> > a little scary, but i see your point. if we went that far then i guess we
> > would also do neo4j. i will say that this change will be on the same order
> > of effort as 1 because it will break a lot of tests in the test suite. in
> > that sense, i'm not sure we're ready for that much change along 3.4.0. i'd
> > propose that we consider "2a" only after we get "2" into place. Then we can
> > determine how much damage 1 would do. Maybe it's not as bad as I think. An
> > interesting side-effect of 1 is that it makes our Java test suite tests
> > become more in line with the GLV tests - they would be roughly 1 to 1 match
> > in assertions after all this.
> >
> >
> > On Fri, Oct 5, 2018 at 11:21 AM brynco...@gmail.com 
> > wrote:
> >
> >>
> >>
> >> On 2018/10/03 17:06:16, Stephen Mallette  wrote:
> >> > We currently have this situation where users get a fair bit of
> >> > inconsistency around the contents of graph elements depending on a
> >> matrix
> >> > of different usage options that we offer - here's just a few "options"
> >> as
> >> > examples:
> >> >
> >> > 1. Use embedded graph mode in OLTP and you likely get the implementation
> >> > version of a Vertex/Edge with accessible properties (e.g. TinkerVertex,
> >> > Neo4jVertex, etc)
> >> > 2. Use embedded graph mode in OLAP and you get ReferenceVertex/Edge
> >> with no
> >> > properties
> >> > 3. Use bytecode based requests with Gremlin Server and you get
> >> > ReferenceVertex/Edge with no properties
> >> > 4. Use script based requests with Gremlin Server and you get
> >> > DetachedVertex/Edge with properties
> >> >
> >> > All this chaos developed out of a healthy evolution of our view of "how
> >> > Gremlin should work and how it fits in the graph community." As I've
> >> > lamented before and I'll lament again, that if we'd foreseen "bytecode",
> >> > then a lot of things would have been more unified.
> >> >
> >> > Anyway, irrespective of how we got here, I think this matrix of choices
> >> > ends up making things quite confusing for users.
> >> >
> >> > To unify and simplify in 3.4.0, I think we could introduce a
> >> > ReferenceStrategy which would coerce graph elements to the "Reference".
> >> > Then we have some choices:
> >> >
> >> > 1. In the most extreme case, it could be installed as a default
> >> strategy.
> >> > All graphs was return the same stuff in whatever situation it was used.
> >> > Obviously, that breaks just about every test in existence and probably
> >> half
> >> > of the code on the planet that uses TinkerPop - everyone ready to not
> >> get
> >> > amazon packages delivered on time anymore over this? But, we're
> >> consistent!
> >> > :)
> >> > 2. We install it as a default strategy in graphs in Gremlin Server.
> >> Still a
> >> > breaking change but at least Gremlin Server is completely consistent.
> >> Users
> >> > can uninstall the strategy if they don't like it and stuff will work as
> >> it
> >> > always did.
> >> > 3. We simply supply ReferenceStrategy as an option and let users
> >> install it
> >> > for themselves to help bring greater consistency to their installations.
> >> >
> >> > I think we should consider option 2. Unless someone has other options to
> >> > consider, it seems like the easiest starting point for this that will
> >> > actually have an impact. There could be devils lying in wait in the
> >> > details, but I thought I'd feel folks on a bit on the general idea.
> >> >
> >> > Thanks,
> >> >
> >> > Stephen
> >> >
> >>
> >>
> >> The thing that worries me is that to go for option 2 still leaves
> >> TinkerGraph behaving in a way that is not consistent over the wire.
> >>
> >> The first thing that many users will do is fire up gremlin console and
> >> create a TinkerGraph without Gremlin Server. This immediately give them a
> >> false impression that properties on elements are available.
> >>
> >> I'd like to propose 2a. Update Gremlin Server and TinkerGraph to behave
> >> in the desired way, this would set the tone for all Graph implementations
> >> to eventually adopt this consistent behaviour.
> >>
> >> Bryn
> >>
> >
> 
Just for completeness is it an option to support detached elements for GLVs? 

If GLVs did support detached elements then this would significantly reduce the 
impact of this change for users as this would mostly align with what they have 
now.

OptionsStrategy improvements

[bryncooke]

Hi,

I recently saw the new OptionsStrategy feature added in 
https://issues.apache.org/jira/browse/TINKERPOP-2053, and was wondering it it 
would be possible to add dedicated support for this at the traversal level.

Using a strategy is fine, and I can see that it fits well with the existing 
infrastructure. However from the user point of view it is extremely verbose:

g.withStrategies(OptionsStrategy.build().with("specialLimit", 
1).withOption("specialLimit2", 1000).create()).V();

vs something like:

g.with("specialLimit", 1).with("specialLimit2", 1000).V()

Would it be possible to introduce something like the above syntax to implicitly 
add and configure the OptionsStrategy?

I think it would make this new feature much more compelling. I can see lots of 
uses for supplying traversal level options going forward.

Many thanks,

Bryn

Re: [DISCUSS] ReferenceStrategy

[bryncooke]

On 2018/10/03 17:06:16, Stephen Mallette  wrote: 
> We currently have this situation where users get a fair bit of
> inconsistency around the contents of graph elements depending on a matrix
> of different usage options that we offer - here's just a few "options" as
> examples:
> 
> 1. Use embedded graph mode in OLTP and you likely get the implementation
> version of a Vertex/Edge with accessible properties (e.g. TinkerVertex,
> Neo4jVertex, etc)
> 2. Use embedded graph mode in OLAP and you get ReferenceVertex/Edge with no
> properties
> 3. Use bytecode based requests with Gremlin Server and you get
> ReferenceVertex/Edge with no properties
> 4. Use script based requests with Gremlin Server and you get
> DetachedVertex/Edge with properties
> 
> All this chaos developed out of a healthy evolution of our view of "how
> Gremlin should work and how it fits in the graph community." As I've
> lamented before and I'll lament again, that if we'd foreseen "bytecode",
> then a lot of things would have been more unified.
> 
> Anyway, irrespective of how we got here, I think this matrix of choices
> ends up making things quite confusing for users.
> 
> To unify and simplify in 3.4.0, I think we could introduce a
> ReferenceStrategy which would coerce graph elements to the "Reference".
> Then we have some choices:
> 
> 1. In the most extreme case, it could be installed as a default strategy.
> All graphs was return the same stuff in whatever situation it was used.
> Obviously, that breaks just about every test in existence and probably half
> of the code on the planet that uses TinkerPop - everyone ready to not get
> amazon packages delivered on time anymore over this? But, we're consistent!
> :)
> 2. We install it as a default strategy in graphs in Gremlin Server. Still a
> breaking change but at least Gremlin Server is completely consistent. Users
> can uninstall the strategy if they don't like it and stuff will work as it
> always did.
> 3. We simply supply ReferenceStrategy as an option and let users install it
> for themselves to help bring greater consistency to their installations.
> 
> I think we should consider option 2. Unless someone has other options to
> consider, it seems like the easiest starting point for this that will
> actually have an impact. There could be devils lying in wait in the
> details, but I thought I'd feel folks on a bit on the general idea.
> 
> Thanks,
> 
> Stephen
> 


The thing that worries me is that to go for option 2 still leaves TinkerGraph 
behaving in a way that is not consistent over the wire.

The first thing that many users will do is fire up gremlin console and create a 
TinkerGraph without Gremlin Server. This immediately give them a false 
impression that properties on elements are available.

I'd like to propose 2a. Update Gremlin Server and TinkerGraph to behave in the 
desired way, this would set the tone for all Graph implementations to 
eventually adopt this consistent behaviour.

Bryn 

[GitHub] tinkerpop issue #812: TINKERPOP-1911 Refactored JavaTranslator

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/812
  
+1 (Non binding)


---

[GitHub] tinkerpop issue #755: TINKERPOP-1834: Consider iterate() as a first class st...

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/755
  
This looks great. +1 (non binding)


---

[GitHub] tinkerpop issue #748: TINKERPOP-1834: Consider iterate() as a first class st...

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/748
  
Would a cap step with no side effect keys be a better fit here rather than 
filter?
It would remove the need for a 'false' traversal.


---

[GitHub] tinkerpop issue #641: TINKERPOP-1703: Make DsegEdgeOtherVertexStep non-final

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/641
  
Can we rename the PR?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #590: TINKERPOP-1664 StarVertexProperty will check meta-prop...

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/590
  
I've reworked for tp31. Also I check null values on array parameters.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop pull request #590: TINKERPOP-1664 StarVertexProperty will check me...

[BrynCooke]

GitHub user BrynCooke opened a pull request:

https://github.com/apache/tinkerpop/pull/590

TINKERPOP-1664 StarVertexProperty will check meta-properties are valid.

StarVertexProperty will check meta-properties are valid.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/BrynCooke/incubator-tinkerpop TINKERPOP-1664

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/590.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #590


commit 0b05c937ee0b0f9025bd4faf8c101ee3d49a3d62
Author: BrynCooke <brynco...@gmail.com>
Date:   2017-04-03T11:19:54Z

TINKERPOP-1664
StarVertexProperty will check meta-properties are valid.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #567: TINKERPOP-1644 Improve script compilation syncronisati...

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/567
  
1. ManagedConcurrentValueMap is not a map. I don't really know why we use 
this. but computeIfAbsent is not present on this class.
2. Guava LoadingCache and MoreExecutors.directExecutor() is the correct way 
of solving this problem. It allows soft values and does all the syncronisation 
stuff for us. Is there a reason why guava is not used by Tinkerpop?

If we want avoid guava we need to have a striped lock on script, and to 
create our own direct executor.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #567: TINKERPOP-1644 Improve script compilation syncronisati...

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/567
  
I like the idea of using a Future.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop pull request #567: TINKERPOP-1644 Improve script compilation syncr...

[BrynCooke]

GitHub user BrynCooke opened a pull request:

https://github.com/apache/tinkerpop/pull/567

TINKERPOP-1644 Improve script compilation syncronisation

Script compilation is synchronised.
Script compilation times are placed in to logs.
Failed scripts will not be recompiled.
Scripts that take over 5 seconds to compile are logged as a warning.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/BrynCooke/incubator-tinkerpop TINKERPOP-1644

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/567.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #567


commit ca229694dc036210ad9e7ae2fc32134720b48d1b
Author: BrynCooke <brynco...@gmail.com>
Date:   2017-03-02T19:07:28Z

TINKERPOP-1644 Improve script compilation syncronisation
Script compilation is synchronised.
Script compilation times are placed in to logs.
Failed scripts will not be recompiled.
Scripts that take over 5 seconds to compile are logged as a warning.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop pull request #470: TINKERPOP-887 Conversion of FastNoSuchElementEx...

[BrynCooke]

Github user BrynCooke closed the pull request at:

https://github.com/apache/tinkerpop/pull/470


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #470: TINKERPOP-887 Conversion of FastNoSuchElementException...

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Great thanks



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #470: TINKERPOP-887 Conversion of FastNoSuchElementException...

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Retargeting at tp32. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #470: TINKERPOP-887 Conversion of FastNoSuchElementException...

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Yes, that's it.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #470: TINKERPOP-887 Conversion of FastNoSuchElementException...

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Exactly. It's currently a huge pain to figure out where things have gone 
wrong. Without this patch I have to divide and conquer my code every time I hit 
a FastNoSuchElementException.

There is no cost to a try/catch block. The construction of the regular 
NoSuchElementException is expensive, but should only be thrown on the top level 
traversal.

I actually found no significant difference between branches in terms of 
performance.

Mine
```
gremlin> graph = TinkerGraph.open()
==>tinkergraph[vertices:0 edges:0]
gremlin> graph.io(gryo()).readGraph('data/grateful-dead.kryo')
==>null
gremlin> h = graph.traversal()
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin> g = graph.traversal().withoutStrategies(LazyBarrierStrategy.class)
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin> clock(100){ h.V().out().out().out().toSet() }
==>3.33155785
gremlin> clock(20){ g.V().out().out().out().toSet() }
==>520.272772449
gremlin> clock(20){ g.V().out().flatMap(out()).flatMap(out()).toSet() }
==>903.525418999
gremlin> clock(100){ g.V().repeat(out()).times(3).toSet() }
==>1.83920066
gremlin> clock(100){ h.V().count() }
==>0.0069826
gremlin> 
```

Master
```
gremlin> graph = TinkerGraph.open()
==>tinkergraph[vertices:0 edges:0]
gremlin> graph.io(gryo()).readGraph('data/grateful-dead.kryo')
==>null
gremlin> h = graph.traversal()
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin> g = graph.traversal().withoutStrategies(LazyBarrierStrategy.class)
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin> clock(100){ h.V().out().out().out().toSet() }
==>3.59260972
gremlin> clock(20){ g.V().out().out().out().toSet() }
==>519.7500263
gremlin> clock(20){ g.V().out().flatMap(out()).flatMap(out()).toSet() }
==>907.32923195
gremlin> clock(100){ g.V().repeat(out()).times(3).toSet() }
==>1.76869779
gremlin> clock(100){ h.V().count() }
==>0.0069853699
gremlin> 
```



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #470: TINKERPOP-887 Conversion of FastNoSuchElementException...

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
@dkuppitz I've updated the changelog and upgrade docs. Please could you 
take a look?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #470: TINKERPOP-887 Conversion of FastNoSuchElementException...

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
The lambda traversal will throw a regular NoSuchElementException is it is 
unparented.
However, won't this will only happen once? The exception will bubble up and 
out of the top level traversal?

If they did this
```
g.V().blah().map{ x -> 
  try {
__.inject(x).will().not().have().anything().next()
return "foo";
  }
  catch(NoSuchElementException e) {
return "bar";
  }
}
```
instead of

```
g.V().blah().map{ x -> 
  if(__.inject(x).will().not().have().anything().hasNext()) {
return "foo";
  }
  else {
return "bar";
  }
}
```
Then they would have a problem.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #470: TINKERPOP-887 Conversion of FastNoSuchElementException...

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
retest this please


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #470: TINKERPOP-887 Conversion of FastNoSuchElementException...

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
@okram I have changed the approach entirely to avoid adding an extra 
strategy.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop pull request #470: TINKERPOP-887 ExceptionHandlerStrategy

[BrynCooke]

GitHub user BrynCooke opened a pull request:

https://github.com/apache/tinkerpop/pull/470

TINKERPOP-887 ExceptionHandlerStrategy

Added exception handler strategy to convert FastNoSuchElementExceptions in 
to regular NoSuchElementExceptions when exiting a traversal.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/BrynCooke/incubator-tinkerpop TINKERPOP-887

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/470.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #470


commit 4b80bcd2f12b905a927d61e257c2d4b00f76f609
Author: BrynCooke <brynco...@gmail.com>
Date:   2016-10-28T19:04:10Z

TINKERPOP-887 Added exception handler strategy to convert 
FastNoSuchElementExceptions in to regular NoSuchElementExceptions when exiting 
a traversal.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #355: TINKERPOP-1355 Design HasContainer for extension

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/355
  
Also the conversion of the collection to an array is dangerous. Who knows 
what the collection is actually backed by? It should use an iterator and get 
the first element if it exists.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop pull request #355: TINKERPOP-1355 Design HasContainer for extensio...

[BrynCooke]

GitHub user BrynCooke opened a pull request:

https://github.com/apache/tinkerpop/pull/355

TINKERPOP-1355 Design HasContainer for extension



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/BrynCooke/incubator-tinkerpop TINKERPOP-1355

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/355.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #355


commit ca8a4f9fb8a9bc1d69aa10870d75076b8fa906b5
Author: Bryn Cooke <brynco...@gmail.com>
Date:   2016-07-04T08:29:40Z

TINKERPOP-1355 Design HasContainer for extension




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #347: Force startedIterating before sleep

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/347
  
@dkuppitz Yes you are right, I've tweaked the PR.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop pull request #347: Force startedIterating before sleep

[BrynCooke]

GitHub user BrynCooke opened a pull request:

https://github.com/apache/tinkerpop/pull/347

Force startedIterating before sleep



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/BrynCooke/incubator-tinkerpop TINKERPOP-1348

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/347.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #347


commit 65d166683f5ab19324180c651a0ae4389eca6b96
Author: Bryn Cooke <brynco...@gmail.com>
Date:   2016-06-27T21:14:37Z

Force startedIterating before sleep




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---