You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Lahiru Sandaruwan <la...@wso2.com> on 2014/01/08 18:58:43 UTC
Avoid burdening IaaS if there is an error while activating the instances
Hi all,
Currently if an instance is not joined after a timeout, we will terminate
the instance and it will be removed from the pending state.
Then the Autoscaler will decide to spawn more instances according to the
rules, to cover terminated instances.
If there is an error which blocks sending member activate event( in the
cartridge, network or at any other place), system will be terminating and
starting instances continuously, which is an utter waste of resources.
So I suggest following scenario,
We keep a count of unactivated instances per cluster. If this count exceeds
a limit( say 3 - should be configurable), we will increase waiting time on
the next instance activation. May be we keep increasing.
We can reset the count when ever a member activation received.
Wdyt?
Thanks.
Sent from my mobile.
Re: Avoid burdening IaaS if there is an error while activating the instances
Posted by Lahiru Sandaruwan <la...@wso2.com>.
On Thu, Jan 9, 2014 at 10:56 AM, Nirmal Fernando <ni...@gmail.com>wrote:
> Again the same issue right? We keep starting and terminating instances
> (it's just an increase of time).
>
Yes, even that saves a lot of stuff :)
Also absolute +1 for alerting. We can use already existing CEP to alert.
If we have the alerting system, actually we can STOP keep starting and
termination thing and wait until sys admin to fix it. Then he let the
system know that things are normal.
>
>
>
> On Thu, Jan 9, 2014 at 10:53 AM, Lahiru Sandaruwan <la...@wso2.com>wrote:
>
>> Hi Nirmal,
>>
>>
>> On Thu, Jan 9, 2014 at 10:25 AM, Nirmal Fernando <ni...@gmail.com>wrote:
>>
>>> Hi Lahiru,
>>>
>>> I'm sorry, but I don't get your point here and also I don't understand
>>> how the proposed solution would solve this problem
>>>
>>
>> mmm, Any specific point that you are not clear?
>>
>> Basically it solves the problem of recursively starting and terminating
>> instances if there is a long running issue.
>>
>>
>>
>>
>>> (what if there's an error and that made member activation event to not
>>> sent ever).
>>>
>>>
>> If this happens only for one instance(Not sending member activation event
>> for ever), it will only wait the given timeout(say 5 mins). So there is no
>> issue.
>>
>> If this happens to consecutive instances(say 3), we can say that there is
>> some long running issue. So we will wait more than the initial delay after
>> 3 consecutive failures...
>>
>> And this is continuing, we can keep increasing the wait up to a ceiling...
>>
>> Thanks.
>>
>>
>>
>>
>>> I wonder whether we need to be concerned on this kind of issues.
>>>
>>>
>>> On Thu, Jan 9, 2014 at 10:00 AM, Isuru Haththotuwa <is...@wso2.com>wrote:
>>>
>>>> +1. We can make the waiting time x2 each time, but there should be a
>>>> ceiling value as well.
>>>>
>>>>
>>>> On Wed, Jan 8, 2014 at 11:28 PM, Lahiru Sandaruwan <la...@wso2.com>wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Currently if an instance is not joined after a timeout, we will
>>>>> terminate the instance and it will be removed from the pending state.
>>>>> Then the Autoscaler will decide to spawn more instances according to
>>>>> the rules, to cover terminated instances.
>>>>> If there is an error which blocks sending member activate event( in
>>>>> the cartridge, network or at any other place), system will be terminating
>>>>> and starting instances continuously, which is an utter waste of resources.
>>>>>
>>>>> So I suggest following scenario,
>>>>>
>>>>> We keep a count of unactivated instances per cluster. If this count
>>>>> exceeds a limit( say 3 - should be configurable), we will increase waiting
>>>>> time on the next instance activation. May be we keep increasing.
>>>>> We can reset the count when ever a member activation received.
>>>>>
>>>>> Wdyt?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Sent from my mobile.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thanks and Regards,
>>>>
>>>> Isuru H.
>>>> Software Engineer, WSO2 Inc.
>>>> +94 716 358 048* <http://wso2.com/>*
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> Nirmal
>>>
>>> Nirmal Fernando.
>>> PPMC Member & Committer of Apache Stratos,
>>> Senior Software Engineer, WSO2 Inc.
>>>
>>> Blog: http://nirmalfdo.blogspot.com/
>>>
>>
>>
>>
>> --
>> --
>> Lahiru Sandaruwan
>> Software Engineer,
>> Platform Technologies,
>> WSO2 Inc., http://wso2.com
>> lean.enterprise.middleware
>>
>> email: lahirus@wso2.com cell: (+94) 773 325 954
>> blog: http://lahiruwrites.blogspot.com/
>> twitter: http://twitter.com/lahirus
>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>
>>
>
>
> --
> Best Regards,
> Nirmal
>
> Nirmal Fernando.
> PPMC Member & Committer of Apache Stratos,
> Senior Software Engineer, WSO2 Inc.
>
> Blog: http://nirmalfdo.blogspot.com/
>
--
--
Lahiru Sandaruwan
Software Engineer,
Platform Technologies,
WSO2 Inc., http://wso2.com
lean.enterprise.middleware
email: lahirus@wso2.com cell: (+94) 773 325 954
blog: http://lahiruwrites.blogspot.com/
twitter: http://twitter.com/lahirus
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
Re: Avoid burdening IaaS if there is an error while activating the instances
Posted by Nirmal Fernando <ni...@gmail.com>.
Again the same issue right? We keep starting and terminating instances
(it's just an increase of time).
On Thu, Jan 9, 2014 at 10:53 AM, Lahiru Sandaruwan <la...@wso2.com> wrote:
> Hi Nirmal,
>
>
> On Thu, Jan 9, 2014 at 10:25 AM, Nirmal Fernando <ni...@gmail.com>wrote:
>
>> Hi Lahiru,
>>
>> I'm sorry, but I don't get your point here and also I don't understand
>> how the proposed solution would solve this problem
>>
>
> mmm, Any specific point that you are not clear?
>
> Basically it solves the problem of recursively starting and terminating
> instances if there is a long running issue.
>
>
>
>
>> (what if there's an error and that made member activation event to not
>> sent ever).
>>
>>
> If this happens only for one instance(Not sending member activation event
> for ever), it will only wait the given timeout(say 5 mins). So there is no
> issue.
>
> If this happens to consecutive instances(say 3), we can say that there is
> some long running issue. So we will wait more than the initial delay after
> 3 consecutive failures...
>
> And this is continuing, we can keep increasing the wait up to a ceiling...
>
> Thanks.
>
>
>
>
>> I wonder whether we need to be concerned on this kind of issues.
>>
>>
>> On Thu, Jan 9, 2014 at 10:00 AM, Isuru Haththotuwa <is...@wso2.com>wrote:
>>
>>> +1. We can make the waiting time x2 each time, but there should be a
>>> ceiling value as well.
>>>
>>>
>>> On Wed, Jan 8, 2014 at 11:28 PM, Lahiru Sandaruwan <la...@wso2.com>wrote:
>>>
>>>> Hi all,
>>>>
>>>> Currently if an instance is not joined after a timeout, we will
>>>> terminate the instance and it will be removed from the pending state.
>>>> Then the Autoscaler will decide to spawn more instances according to
>>>> the rules, to cover terminated instances.
>>>> If there is an error which blocks sending member activate event( in the
>>>> cartridge, network or at any other place), system will be terminating and
>>>> starting instances continuously, which is an utter waste of resources.
>>>>
>>>> So I suggest following scenario,
>>>>
>>>> We keep a count of unactivated instances per cluster. If this count
>>>> exceeds a limit( say 3 - should be configurable), we will increase waiting
>>>> time on the next instance activation. May be we keep increasing.
>>>> We can reset the count when ever a member activation received.
>>>>
>>>> Wdyt?
>>>>
>>>> Thanks.
>>>>
>>>> Sent from my mobile.
>>>>
>>>
>>>
>>>
>>> --
>>> Thanks and Regards,
>>>
>>> Isuru H.
>>> Software Engineer, WSO2 Inc.
>>> +94 716 358 048* <http://wso2.com/>*
>>>
>>>
>>>
>>
>>
>> --
>> Best Regards,
>> Nirmal
>>
>> Nirmal Fernando.
>> PPMC Member & Committer of Apache Stratos,
>> Senior Software Engineer, WSO2 Inc.
>>
>> Blog: http://nirmalfdo.blogspot.com/
>>
>
>
>
> --
> --
> Lahiru Sandaruwan
> Software Engineer,
> Platform Technologies,
> WSO2 Inc., http://wso2.com
> lean.enterprise.middleware
>
> email: lahirus@wso2.com cell: (+94) 773 325 954
> blog: http://lahiruwrites.blogspot.com/
> twitter: http://twitter.com/lahirus
> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>
--
Best Regards,
Nirmal
Nirmal Fernando.
PPMC Member & Committer of Apache Stratos,
Senior Software Engineer, WSO2 Inc.
Blog: http://nirmalfdo.blogspot.com/
Re: Avoid burdening IaaS if there is an error while activating the instances
Posted by Lahiru Sandaruwan <la...@wso2.com>.
Hi Nirmal,
On Thu, Jan 9, 2014 at 10:25 AM, Nirmal Fernando <ni...@gmail.com>wrote:
> Hi Lahiru,
>
> I'm sorry, but I don't get your point here and also I don't understand how
> the proposed solution would solve this problem
>
mmm, Any specific point that you are not clear?
Basically it solves the problem of recursively starting and terminating
instances if there is a long running issue.
> (what if there's an error and that made member activation event to not
> sent ever).
>
>
If this happens only for one instance(Not sending member activation event
for ever), it will only wait the given timeout(say 5 mins). So there is no
issue.
If this happens to consecutive instances(say 3), we can say that there is
some long running issue. So we will wait more than the initial delay after
3 consecutive failures...
And this is continuing, we can keep increasing the wait up to a ceiling...
Thanks.
> I wonder whether we need to be concerned on this kind of issues.
>
>
> On Thu, Jan 9, 2014 at 10:00 AM, Isuru Haththotuwa <is...@wso2.com>wrote:
>
>> +1. We can make the waiting time x2 each time, but there should be a
>> ceiling value as well.
>>
>>
>> On Wed, Jan 8, 2014 at 11:28 PM, Lahiru Sandaruwan <la...@wso2.com>wrote:
>>
>>> Hi all,
>>>
>>> Currently if an instance is not joined after a timeout, we will
>>> terminate the instance and it will be removed from the pending state.
>>> Then the Autoscaler will decide to spawn more instances according to the
>>> rules, to cover terminated instances.
>>> If there is an error which blocks sending member activate event( in the
>>> cartridge, network or at any other place), system will be terminating and
>>> starting instances continuously, which is an utter waste of resources.
>>>
>>> So I suggest following scenario,
>>>
>>> We keep a count of unactivated instances per cluster. If this count
>>> exceeds a limit( say 3 - should be configurable), we will increase waiting
>>> time on the next instance activation. May be we keep increasing.
>>> We can reset the count when ever a member activation received.
>>>
>>> Wdyt?
>>>
>>> Thanks.
>>>
>>> Sent from my mobile.
>>>
>>
>>
>>
>> --
>> Thanks and Regards,
>>
>> Isuru H.
>> Software Engineer, WSO2 Inc.
>> +94 716 358 048* <http://wso2.com/>*
>>
>>
>>
>
>
> --
> Best Regards,
> Nirmal
>
> Nirmal Fernando.
> PPMC Member & Committer of Apache Stratos,
> Senior Software Engineer, WSO2 Inc.
>
> Blog: http://nirmalfdo.blogspot.com/
>
--
--
Lahiru Sandaruwan
Software Engineer,
Platform Technologies,
WSO2 Inc., http://wso2.com
lean.enterprise.middleware
email: lahirus@wso2.com cell: (+94) 773 325 954
blog: http://lahiruwrites.blogspot.com/
twitter: http://twitter.com/lahirus
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
Re: Avoid burdening IaaS if there is an error while activating the instances
Posted by Nirmal Fernando <ni...@gmail.com>.
The other concern is what would a user do upon an alert? Is that of a
user's control? May be asking to send a mail to system admins? IMO this is
some issue with the stratos and may be what should we do is to alert the
system admins (dev-ops etc.).
On Thu, Jan 9, 2014 at 10:50 AM, Nirmal Fernando <ni...@gmail.com>wrote:
> Yes, may be in the subscription UI, we could add an alert. But, we should
> come up with a design on how to get it to there.
>
>
> On Thu, Jan 9, 2014 at 10:36 AM, Isuru Haththotuwa <is...@wso2.com>wrote:
>
>> On Thu, Jan 9, 2014 at 10:25 AM, Nirmal Fernando <ni...@gmail.com>wrote:
>>
>>> Hi Lahiru,
>>>
>>> I'm sorry, but I don't get your point here and also I don't understand
>>> how the proposed solution would solve this problem (what if there's an
>>> error and that made member activation event to not sent ever).
>>>
>>> I wonder whether we need to be concerned on this kind of issues.
>>>
>>
>> I agree that this is an optimization. But if there is an error, IMHO it
>> is better to notify the user (maybe printing a log statement) that the
>> activation is not received continuously for the last n number of instances
>> spawned, without keep on terminating and re-spawning.
>>
>>>
>>>
>>> On Thu, Jan 9, 2014 at 10:00 AM, Isuru Haththotuwa <is...@wso2.com>wrote:
>>>
>>>> +1. We can make the waiting time x2 each time, but there should be a
>>>> ceiling value as well.
>>>>
>>>>
>>>> On Wed, Jan 8, 2014 at 11:28 PM, Lahiru Sandaruwan <la...@wso2.com>wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Currently if an instance is not joined after a timeout, we will
>>>>> terminate the instance and it will be removed from the pending state.
>>>>> Then the Autoscaler will decide to spawn more instances according to
>>>>> the rules, to cover terminated instances.
>>>>> If there is an error which blocks sending member activate event( in
>>>>> the cartridge, network or at any other place), system will be terminating
>>>>> and starting instances continuously, which is an utter waste of resources.
>>>>>
>>>>> So I suggest following scenario,
>>>>>
>>>>> We keep a count of unactivated instances per cluster. If this count
>>>>> exceeds a limit( say 3 - should be configurable), we will increase waiting
>>>>> time on the next instance activation. May be we keep increasing.
>>>>> We can reset the count when ever a member activation received.
>>>>>
>>>>> Wdyt?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Sent from my mobile.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thanks and Regards,
>>>>
>>>> Isuru H.
>>>> Software Engineer, WSO2 Inc.
>>>> +94 716 358 048* <http://wso2.com/>*
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> Nirmal
>>>
>>> Nirmal Fernando.
>>> PPMC Member & Committer of Apache Stratos,
>>> Senior Software Engineer, WSO2 Inc.
>>>
>>> Blog: http://nirmalfdo.blogspot.com/
>>>
>>
>>
>>
>> --
>> Thanks and Regards,
>>
>> Isuru H.
>> Software Engineer, WSO2 Inc.
>> +94 716 358 048* <http://wso2.com/>*
>>
>>
>>
>
>
> --
> Best Regards,
> Nirmal
>
> Nirmal Fernando.
> PPMC Member & Committer of Apache Stratos,
> Senior Software Engineer, WSO2 Inc.
>
> Blog: http://nirmalfdo.blogspot.com/
>
--
Best Regards,
Nirmal
Nirmal Fernando.
PPMC Member & Committer of Apache Stratos,
Senior Software Engineer, WSO2 Inc.
Blog: http://nirmalfdo.blogspot.com/
Re: Avoid burdening IaaS if there is an error while activating the instances
Posted by Nirmal Fernando <ni...@gmail.com>.
Yes, may be in the subscription UI, we could add an alert. But, we should
come up with a design on how to get it to there.
On Thu, Jan 9, 2014 at 10:36 AM, Isuru Haththotuwa <is...@wso2.com> wrote:
> On Thu, Jan 9, 2014 at 10:25 AM, Nirmal Fernando <ni...@gmail.com>wrote:
>
>> Hi Lahiru,
>>
>> I'm sorry, but I don't get your point here and also I don't understand
>> how the proposed solution would solve this problem (what if there's an
>> error and that made member activation event to not sent ever).
>>
>> I wonder whether we need to be concerned on this kind of issues.
>>
>
> I agree that this is an optimization. But if there is an error, IMHO it is
> better to notify the user (maybe printing a log statement) that the
> activation is not received continuously for the last n number of instances
> spawned, without keep on terminating and re-spawning.
>
>>
>>
>> On Thu, Jan 9, 2014 at 10:00 AM, Isuru Haththotuwa <is...@wso2.com>wrote:
>>
>>> +1. We can make the waiting time x2 each time, but there should be a
>>> ceiling value as well.
>>>
>>>
>>> On Wed, Jan 8, 2014 at 11:28 PM, Lahiru Sandaruwan <la...@wso2.com>wrote:
>>>
>>>> Hi all,
>>>>
>>>> Currently if an instance is not joined after a timeout, we will
>>>> terminate the instance and it will be removed from the pending state.
>>>> Then the Autoscaler will decide to spawn more instances according to
>>>> the rules, to cover terminated instances.
>>>> If there is an error which blocks sending member activate event( in the
>>>> cartridge, network or at any other place), system will be terminating and
>>>> starting instances continuously, which is an utter waste of resources.
>>>>
>>>> So I suggest following scenario,
>>>>
>>>> We keep a count of unactivated instances per cluster. If this count
>>>> exceeds a limit( say 3 - should be configurable), we will increase waiting
>>>> time on the next instance activation. May be we keep increasing.
>>>> We can reset the count when ever a member activation received.
>>>>
>>>> Wdyt?
>>>>
>>>> Thanks.
>>>>
>>>> Sent from my mobile.
>>>>
>>>
>>>
>>>
>>> --
>>> Thanks and Regards,
>>>
>>> Isuru H.
>>> Software Engineer, WSO2 Inc.
>>> +94 716 358 048* <http://wso2.com/>*
>>>
>>>
>>>
>>
>>
>> --
>> Best Regards,
>> Nirmal
>>
>> Nirmal Fernando.
>> PPMC Member & Committer of Apache Stratos,
>> Senior Software Engineer, WSO2 Inc.
>>
>> Blog: http://nirmalfdo.blogspot.com/
>>
>
>
>
> --
> Thanks and Regards,
>
> Isuru H.
> Software Engineer, WSO2 Inc.
> +94 716 358 048* <http://wso2.com/>*
>
>
>
--
Best Regards,
Nirmal
Nirmal Fernando.
PPMC Member & Committer of Apache Stratos,
Senior Software Engineer, WSO2 Inc.
Blog: http://nirmalfdo.blogspot.com/
Re: Avoid burdening IaaS if there is an error while activating the instances
Posted by Isuru Haththotuwa <is...@wso2.com>.
On Thu, Jan 9, 2014 at 10:25 AM, Nirmal Fernando <ni...@gmail.com>wrote:
> Hi Lahiru,
>
> I'm sorry, but I don't get your point here and also I don't understand how
> the proposed solution would solve this problem (what if there's an error
> and that made member activation event to not sent ever).
>
> I wonder whether we need to be concerned on this kind of issues.
>
I agree that this is an optimization. But if there is an error, IMHO it is
better to notify the user (maybe printing a log statement) that the
activation is not received continuously for the last n number of instances
spawned, without keep on terminating and re-spawning.
>
>
> On Thu, Jan 9, 2014 at 10:00 AM, Isuru Haththotuwa <is...@wso2.com>wrote:
>
>> +1. We can make the waiting time x2 each time, but there should be a
>> ceiling value as well.
>>
>>
>> On Wed, Jan 8, 2014 at 11:28 PM, Lahiru Sandaruwan <la...@wso2.com>wrote:
>>
>>> Hi all,
>>>
>>> Currently if an instance is not joined after a timeout, we will
>>> terminate the instance and it will be removed from the pending state.
>>> Then the Autoscaler will decide to spawn more instances according to the
>>> rules, to cover terminated instances.
>>> If there is an error which blocks sending member activate event( in the
>>> cartridge, network or at any other place), system will be terminating and
>>> starting instances continuously, which is an utter waste of resources.
>>>
>>> So I suggest following scenario,
>>>
>>> We keep a count of unactivated instances per cluster. If this count
>>> exceeds a limit( say 3 - should be configurable), we will increase waiting
>>> time on the next instance activation. May be we keep increasing.
>>> We can reset the count when ever a member activation received.
>>>
>>> Wdyt?
>>>
>>> Thanks.
>>>
>>> Sent from my mobile.
>>>
>>
>>
>>
>> --
>> Thanks and Regards,
>>
>> Isuru H.
>> Software Engineer, WSO2 Inc.
>> +94 716 358 048* <http://wso2.com/>*
>>
>>
>>
>
>
> --
> Best Regards,
> Nirmal
>
> Nirmal Fernando.
> PPMC Member & Committer of Apache Stratos,
> Senior Software Engineer, WSO2 Inc.
>
> Blog: http://nirmalfdo.blogspot.com/
>
--
Thanks and Regards,
Isuru H.
Software Engineer, WSO2 Inc.
+94 716 358 048* <http://wso2.com/>*
Re: Avoid burdening IaaS if there is an error while activating the instances
Posted by Nirmal Fernando <ni...@gmail.com>.
Hi Lahiru,
I'm sorry, but I don't get your point here and also I don't understand how
the proposed solution would solve this problem (what if there's an error
and that made member activation event to not sent ever).
I wonder whether we need to be concerned on this kind of issues.
On Thu, Jan 9, 2014 at 10:00 AM, Isuru Haththotuwa <is...@wso2.com> wrote:
> +1. We can make the waiting time x2 each time, but there should be a
> ceiling value as well.
>
>
> On Wed, Jan 8, 2014 at 11:28 PM, Lahiru Sandaruwan <la...@wso2.com>wrote:
>
>> Hi all,
>>
>> Currently if an instance is not joined after a timeout, we will terminate
>> the instance and it will be removed from the pending state.
>> Then the Autoscaler will decide to spawn more instances according to the
>> rules, to cover terminated instances.
>> If there is an error which blocks sending member activate event( in the
>> cartridge, network or at any other place), system will be terminating and
>> starting instances continuously, which is an utter waste of resources.
>>
>> So I suggest following scenario,
>>
>> We keep a count of unactivated instances per cluster. If this count
>> exceeds a limit( say 3 - should be configurable), we will increase waiting
>> time on the next instance activation. May be we keep increasing.
>> We can reset the count when ever a member activation received.
>>
>> Wdyt?
>>
>> Thanks.
>>
>> Sent from my mobile.
>>
>
>
>
> --
> Thanks and Regards,
>
> Isuru H.
> Software Engineer, WSO2 Inc.
> +94 716 358 048* <http://wso2.com/>*
>
>
>
--
Best Regards,
Nirmal
Nirmal Fernando.
PPMC Member & Committer of Apache Stratos,
Senior Software Engineer, WSO2 Inc.
Blog: http://nirmalfdo.blogspot.com/
Re: Avoid burdening IaaS if there is an error while activating the instances
Posted by Isuru Haththotuwa <is...@wso2.com>.
+1. We can make the waiting time x2 each time, but there should be a
ceiling value as well.
On Wed, Jan 8, 2014 at 11:28 PM, Lahiru Sandaruwan <la...@wso2.com> wrote:
> Hi all,
>
> Currently if an instance is not joined after a timeout, we will terminate
> the instance and it will be removed from the pending state.
> Then the Autoscaler will decide to spawn more instances according to the
> rules, to cover terminated instances.
> If there is an error which blocks sending member activate event( in the
> cartridge, network or at any other place), system will be terminating and
> starting instances continuously, which is an utter waste of resources.
>
> So I suggest following scenario,
>
> We keep a count of unactivated instances per cluster. If this count
> exceeds a limit( say 3 - should be configurable), we will increase waiting
> time on the next instance activation. May be we keep increasing.
> We can reset the count when ever a member activation received.
>
> Wdyt?
>
> Thanks.
>
> Sent from my mobile.
>
--
Thanks and Regards,
Isuru H.
Software Engineer, WSO2 Inc.
+94 716 358 048* <http://wso2.com/>*