As per the offline discussion with Imesh and Lahiru, we have decided to
have three partition selection algorithms.
1. Round-Robin : Always next partition will be selected, this is will
not ensure that instances are equally distributed to partitions.
2. Weighted-Round-Robin : It will distr
On Wed, Mar 4, 2015 at 11:21 AM, Rajkumar Rajaratnam
wrote:
> As per the offline discussion with Imesh and Lahiru, we have decided to
> have three partition selection algorithms.
>
+1. We can rename current one to 'Weighted RR'
Thanks.
>
>- Round-Robin : The next partition will be selected
Sorry for the previous mail. Accidentally hit the send button :(
As per the offline discussion with Imesh and Lahiru, we have decided to
have three partition selection algorithms.
1. Round-Robin : Always next partition will be selected, this is will
not ensure that instances are equally dis
As per the offline discussion with Imesh and Lahiru, we have decided to
have three partition selection algorithms.
- Round-Robin : The next partition will be selected
On Wed, Mar 4, 2015 at 11:14 AM, Gayan Gunarathne wrote:
> Yeah IMO also we need to keep track of the selected index no of t
Yeah IMO also we need to keep track of the selected index no of the
partition.I think we may need to persist the selected index to get the RR
algorithm works correctly.
IMO in the scale up we will increment the selected index up to max index no
while in scale down it will decrease the selected ind
Hi Reka,
On Wed, Mar 4, 2015 at 1:03 AM, Reka Thirunavukkarasu wrote:
> I think that there is small issue in applying the same RR logic for scale
> up and scale down. if it sclaes up, then
>
> p1 -1, p2-1, p3-1, p1-2, p2-2
>
> Then, if we are to continuously scale down, then which partition will
Hi guys,
Interesting discussion. I think we can live with 2 algorithms. Because user
might be confused if we introduced a variations with small changes to RR
and user might not need to fine tune the algorithms that much.
On Wed, Mar 4, 2015 at 1:03 AM, Reka Thirunavukkarasu wrote:
> I think th
I think that there is small issue in applying the same RR logic for scale
up and scale down. if it sclaes up, then
p1 -1, p2-1, p3-1, p1-2, p2-2
Then, if we are to continuously scale down, then which partition will we
choose next? Will it be p3? In that way, it won't be equally
distributed..In or
That's a good point Raj. Yah..We need to think about scale down as
well..Will think a bit and update, if i get any points..
Thanks,
Reka
On Tue, Mar 3, 2015 at 11:59 AM, Rajkumar Rajaratnam
wrote:
> Hi Reka,
>
> There is small issue in the way you suggested above. If you consider scale
> down s
What I meant in the previous reply is the following scenario.
For eg:
p1, p2 , p3
If the iteration goes as below:
selectedIndex = -1
since all the partitions has 0 instances, choose the first partition as the
selectedIndex = 1
p1 - 1selectedIndex = 1
p2 - 1 selectedIndex = 2
p3 - 1s
Hi Reka,
There is small issue in the way you suggested above. If you consider scale
down scenario, you can't actually say p2 will have min number instances. It
can be p1, if scale down happened from p1. So if we restart the stratos, RR
will select p1 as next partition right? This is not a pure RR
Hi Raj,
I don't think that we will need another algorithm. If we implement RR in
the way that i explained, then it will even make sure to distribute the
members equally.
For eg:
p1, p2 , p3
If the iteration goes as below:
selectedIndex = -1
since all the partitions has 0 instances, choose the
So I guess we have three algorithms :)
1. one-after-another (It will go to next partition only if the current
partition is full)
2. round-robin (if we implement as Reka explained above. It will always
select the next partition)
3. name-should-be-decided (this will work as Lahiru explained above. I
I think that if the selectedIndex is initial value as -1, then RR should
traverse through all the partitions and find out who has the minimum
instances and choose that partition as the selectedIndex in the first
iteration(may be we can exc). Then from the second iteration onwards, it
can increase t
I have now fixed both getNextScaleDownPartitionContext and
getNextScaleUpPartitionContext implementation of Round-Robin.
Thanks.
On Tue, Mar 3, 2015 at 11:23 PM, Lahiru Sandaruwan wrote:
>
>
> On Tue, Mar 3, 2015 at 11:15 PM, Rajkumar Rajaratnam
> wrote:
>
>> Problem is lowestInstanceCount is
On Tue, Mar 3, 2015 at 11:15 PM, Rajkumar Rajaratnam
wrote:
> Problem is lowestInstanceCount is initially taking 0. Instead it should
> take the non terminated member count of 1st partition.
>
> To Fix,
>
> int selectedIndex = 0;
> int lowestInstanceCount =
> partitionContexts[0].
Problem is lowestInstanceCount is initially taking 0. Instead it should
take the non terminated member count of 1st partition.
To Fix,
int selectedIndex = 0;
int lowestInstanceCount =
partitionContexts[0].getNonTerminatedMemberCount();
wdyt?
Thanks.
On Tue, Mar 3, 2015 at 10:57
Hi Lahiru,
Actually, current logic is not working as your example. This logic only
uses the first partition. This will never use any other partitions. See my
comments within the following code.
public PartitionContext
getNextScaleUpPartitionContext(PartitionContext[] partitionContexts) {
Hi Raj,
Earlier in 4.0.0 release, we have been using the partition index. If that
to be worked correctly we should persist the index for each cluster.
IMO there is a better way to execute the round-robin method as follows,
The intention of round robin algorithm is to distribute the members in th
Hi Devs,
It seems to me that there is a bug in round-robin implementation of
partition algorithm.
https://github.com/apache/stratos/blob/0b7734f4c9f1444d064fec93bf9ac59a5883faf2/components/org.apache.stratos.autoscaler/src/main/java/org/apache/stratos/autoscaler/algorithm/RoundRobin.java#L43-L64
20 matches
Mail list logo
