It is like this. That's happened due to nested group with several
members.That's application deployment and un-deployement happen without of
a considerable wait time.
So if we have duplicate MemberActivateEvent , it can be triggered in any
occasion during the life cycle of the application. So if t
Hi Gayan,
What additional threads? And where do they get created?
Clearly, it should not be published twice, but I still don't understand
what exactly goes wrong if it is published again.
Thanks.
On Mon, Oct 12, 2015 at 11:51 PM, Gayan Gunarathne wrote:
>
> On Mon, Oct 12, 2015 at 9:59 PM, Ak
On Mon, Oct 12, 2015 at 9:59 PM, Akila Ravihansa Perera
wrote:
> Hi Thanuja,
>
> Thanks for the update. It seems Stratos Jenkins build has returned to
> normal with your last commit [1]. So could this duplicate call to
> sendMemberActivatedEvent()
> method have been the culprit all this time?
>
Hi Akila,
Whenever a member status changes, we are calculating the status of the
cluster instance using ClusterStatusProcessorChain where it has processors
for active, terminated, inactive and etc. The first processor which
calculates the status will send the Topology event with cluster status
cha
Hi Reka,
Yes, I meant we don't register any receivers for MemberActivated event in
TopologyHandler. Could you explain what happens in this piece of code in
ClusterStatusProcessorChain?
"root.process(type, clusterId, instanceId);"
Thanks.
On Mon, Oct 12, 2015 at 10:19 PM, Reka Thirunavukkarasu
Hi Akila/Thanuja,
On Mon, Oct 12, 2015 at 9:59 PM, Akila Ravihansa Perera
wrote:
> Hi Thanuja,
>
> Thanks for the update. It seems Stratos Jenkins build has returned to
> normal with your last commit [1]. So could this duplicate call to
> sendMemberActivatedEvent()
> method have been the culpri
Hi Thanuja,
Thanks for the update. It seems Stratos Jenkins build has returned to
normal with your last commit [1]. So could this duplicate call to
sendMemberActivatedEvent()
method have been the culprit all this time?
@Reka: Autoscaler is listening to MemberActivated event and executing this
log
Hi All,
I did several builds with latest changes. Each local build triggered
successfully with no test failures. But there are RuntimeExceptions.
I tried following scenarios
1. Reverted metering service changes as in commit [1] - build success
2. Build stratos 4.1.x branch with latest commit [2] -
Seems even application is terminated, some of the group monitors are still
running. Mostly in the nested group scenario. Those group monitors looking
for the application monitor that didn't exist at that time.So I think we
need to recheck the logic of group monitor termination logic in the
applicat
This is occurring frequently even in local build. I think this is a blocker
for 4.1.4 release.
On Fri, Oct 9, 2015 at 9:20 PM, Imesh Gunaratne wrote:
> Thanks Reka! It is important to identify the root cause of this issue. I'm
> also looking in.
>
> On Thu, Oct 8, 2015 at 6:13 PM, Reka Thirunavu
Thanks Reka! It is important to identify the root cause of this issue. I'm
also looking in.
On Thu, Oct 8, 2015 at 6:13 PM, Reka Thirunavukkarasu wrote:
> Hi
>
> After going through the logs of integration, please find the break down as
> below. For my-group6-group-tom2-group-startup-order-test,
Hi
After going through the logs of integration, please find the break down as
below. For my-group6-group-tom2-group-startup-order-test, it seems that the
Adder got triggered twice or somehow monitor creation got triggered twice
which cause the memory to inconsistent state. Hence the particular
Gro
Hi Akila
On Thu, Oct 8, 2015 at 2:51 PM, Akila Ravihansa Perera
wrote:
> Hi Thanuja,
>
> I was referring to the build fail in [1]. Please see line starting from:
>
> 2015-10-02 07:28:32 INFO
> {org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader}:70 -
> [2015-10-02 07:28:32,834]
Hi Thanuja,
I was referring to the build fail in [1]. Please see line starting from:
2015-10-02 07:28:32 INFO
{org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader}:70 -
[2015-10-02 07:28:32,834] ERROR
{org.apache.stratos.autoscaler.rule.RuleTasksDelegator} - Cannot terminate
ins
Hi All,
NPE is not thrown by drool files. I reverted the changes in drool file
which we did for metering service locally and ran the integration test. I'm
getting NPE in same place at GroupMonitor (line - 163) as follows:
2015-10-08 13:42:28 INFO
{org.apache.stratos.integration.tests.applicatio
Hi Akila,
On Wed, Oct 7, 2015 at 7:08 PM, Akila Ravihansa Perera
wrote:
> Hi Reka,
>
> Could you please explain the fix that you are planning to do?
>
I have added only Null check to the places where Application Monitor was
invoked. It is required as in the force undeployment, we are removing al
Hi Reka,
Could you please explain the fix that you are planning to do?
While going through the GroupMonitor class, few issues were found related
to the logic in handling Thread Executors. The problem is when an
application is undeployed, execution jobs are never stopped from Thread
Executor servi
Hi Imesh,
On Wed, Oct 7, 2015 at 7:27 AM, Reka Thirunavukkarasu wrote:
> Hi Imesh,
>
> On Wed, Oct 7, 2015 at 5:46 AM, Imesh Gunaratne wrote:
>
>> GroupMonitor:
>>
>> ApplicationMonitor applicationMonitor =
>> AutoscalerContext.getInstance().
>> getAppMonitor(a
Hi Imesh,
On Wed, Oct 7, 2015 at 5:46 AM, Imesh Gunaratne wrote:
> GroupMonitor:
>
> ApplicationMonitor applicationMonitor =
> AutoscalerContext.getInstance().
> getAppMonitor(appId);
>
> [161] //When the application is getting un-deployed, need to avoid
> [162]
GroupMonitor:
ApplicationMonitor applicationMonitor =
AutoscalerContext.getInstance().
getAppMonitor(appId);
[161] //When the application is getting un-deployed, need to avoid
[162] // checking the minimum count sanctification
[163] if (!applicationMonitor.isTerm
Hi Akila,
On Wed, Oct 7, 2015 at 1:09 AM, Akila Ravihansa Perera
wrote:
> Hi Thanuja,
>
> Thanks for the update.
>
> In both of those cases, did you observe any build failures? If so, what
> are the tests that failed?
>
For the complete stratos build, following test cases are failing with NPE
Hi Thanuja,
Thanks for the update.
In both of those cases, did you observe any build failures? If so, what are
the tests that failed?
I noticed the same behavior as you have explained. When I check the log
file
in /test-integration/target//repository/logs/wso2carbon.log, I
didn't see any NPE's r
Hi,
It seems integration tests are failing intermittently regardless of NPE's
thrown from Drool files. I've added more debug logs to troubleshoot the
issue. I've set the default log level in AS and CC packages to DEBUG in
integration tests. This will help us to identify the root causes of
integrat
Hi Akila,
I'll check this and let you know.
Thanks.
On Tue, Oct 6, 2015 at 12:31 PM, Akila Ravihansa Perera
wrote:
> Hi Thanuja,
>
> I noticed that integration tests are failing in stratos-4.1.x branch due
> to an issue in Drools files. It seems there have been couple of
> modifications done f
Hi Thanuja,
I noticed that integration tests are failing in stratos-4.1.x branch due to
an issue in Drools files. It seems there have been couple of modifications
done for Drools files with new metering dashboard feature. Perhaps it is
incompatible with autoscaler APIs. Could you look into that pl
25 matches
Mail list logo
