Re: localOrShuffleGrouping load balanced tuple distribution

2016-02-16 Thread Bobby Evans
We are working on way to try to improve this by having the grouping be aware of the load downstream and try to route tuples locally unless it is overloaded and then send them remotely.  - Bobby On Tuesday, February 16, 2016 8:27 AM, Nathan Leung wrote: My guess is

Re: localOrShuffleGrouping load balanced tuple distribution

2016-02-16 Thread Nathan Leung
My guess is this only happens because you have one executor per worker so nothing is local to the spout anyways. If your component has number of executors less than your number of workers it's often better to use shuffle grouping. In your two worker example, half the tuples would stay local

Re: localOrShuffleGrouping load balanced tuple distribution

2016-02-16 Thread Spico Florin
Hi, Nathan! Thank you for your answer. You are right: the only bolts that are used will be the ones located nearby the spout. The other two will be unused. If we increase the number of workers to 5, then it will behave as shuffleGrouping (distributing evenly among the bolts). I got it!

Fwd: localOrShuffleGrouping load balanced tuple distribution

2016-02-15 Thread Spico Florin
Hello! Suppose that I have the following scenario 1. One spout 2. One bolt with hintParallelism set to 4 3. Bolt connected with the spout with localOrShuffleGrouping 4. 2 slots available 5. We use the the default schedulder (round-robin) Give the above scenario, the distribution over the

localOrShuffleGrouping load balanced tuple distribution

2016-02-15 Thread Spico Florin
Hello! Suppose that I have the following scenario 1. One spout 2. One bolt with hintParallelism set to 4 3. Bolt connected with the spout with localOrShuffleGrouping 4. 2 slots available 5. We use the the default schedulder (round-robin) Give the above scenario, the distribution over the