Hi Isuru,
I rerun the scenario and it is working, will close the jira. One thing though,
after running the scenario I noticed the following exception in the logs:
TID: [0] [STRATOS] [2014-11-18 20:32:47,663] DEBUG
{org.apache.stratos.autoscaler.rule.RuleTasksDelegator} - Partition algorithm
is
TID: [0] [STRATOS] [2014-11-18 20:32:47,664] DEBUG
{org.apache.stratos.autoscaler.rule.RuleTasksDelegator} - Predicting the
value, [average]: 0.0 , [gradient]: 0.0 , [second derivative]: 0.0 , [time
intervals]: 1
TID: [0] [STRATOS] [2014-11-18 20:32:47,665] DEBUG
{org.apache.stratos.autoscaler.rule.RuleTasksDelegator} - Predicting the
value, [average]: 11.96632 , [gradient]: 2.782237E-4 , [second derivative]: 0.0
, [time intervals]: 1
TID: [0] [STRATOS] [2014-11-18 20:32:47,665] DEBUG
{org.apache.stratos.autoscaler.rule.RuleTasksDelegator} - Member ID :
c1xxx.cisco-sample-vm.domainbcd81915-5d08-4051-bbb9-ba7487dbc724 : Predicted
Memory Consumption : 11.966598510742188
TID: [0] [STRATOS] [2014-11-18 20:32:47,665] DEBUG
{org.apache.stratos.autoscaler.rule.RuleTasksDelegator} - Predicted memory
consumption : 11.966598510742188
TID: [0] [STRATOS] [2014-11-18 20:32:47,666] DEBUG
{org.apache.stratos.autoscaler.rule.RuleTasksDelegator} - Predicting the
value, [average]: 0.0 , [gradient]: 0.0 , [second derivative]: 0.0 , [time
intervals]: 1
TID: [0] [STRATOS] [2014-11-18 20:32:47,666] DEBUG
{org.apache.stratos.autoscaler.rule.RuleTasksDelegator} - Member ID :
c1xxx.cisco-sample-vm.domainbcd81915-5d08-4051-bbb9-ba7487dbc724 : Predicted
Load Average : 0.0
TID: [0] [STRATOS] [2014-11-18 20:32:47,666] DEBUG
{org.apache.stratos.autoscaler.rule.RuleTasksDelegator} - Predicted load
average : 0.0
TID: [0] [STRATOS] [2014-11-18 20:32:47,671] ERROR
{org.apache.stratos.autoscaler.monitor.cluster.VMServiceClusterMonitor} -
Cluster monitor: Monitor failed.VMServiceClusterMonitor
[clusterId=c1xxx.cisco-sample-vm.domain, lbReferenceType=null, hasPrimary=false
]
[Error: null]
[Near : {... $delegator.getNumberOfInstance ....}]
^
[Line: 1, Column: 1]
at
org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:435)
at
org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:143)
at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
at
org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
at
org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
at org.mvel2.MVEL.executeExpression(MVEL.java:942)
at
org.drools.base.dataproviders.MVELDataProvider.getResults(MVELDataProvider.java:111)
at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:150)
at
org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:196)
at
org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:71)
at
org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:333)
at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164)
at
org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:196)
….
Caused by: java.lang.IllegalArgumentException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1104)
at
org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:987)
at
org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:377)
... 116 more
From: [email protected] [mailto:[email protected]] On Behalf Of Isuru Haththotuwa
Sent: Tuesday, November 18, 2014 2:35 AM
To: dev
Subject: Re: [Grouping][testing] - jiras
Hi Martin,
Committed a fix for https://issues.apache.org/jira/browse/STRATOS-975. Can you
please confirm the fix and if so close the Jira ticket?
On Tue, Nov 18, 2014 at 8:11 AM, Martin Eppel (meppel)
<[email protected]<mailto:[email protected]>> wrote:
I run a couple of test scenarios and created the jiras below for the issues
encountered. Please note, that for the 974 I am not exactly sure if this is
really is an issue, or a onetime occurrence but it might be worthwhile to take
a look at the logs.
https://issues.apache.org/jira/browse/STRATOS-974
https://issues.apache.org/jira/browse/STRATOS-974
From: Martin Eppel (meppel)
Sent: Monday, November 17, 2014 12:13 PM
To: [email protected]<mailto:[email protected]>
Subject: RE: [Grouping] Issue with dependencies in nested grouping scenario
(termination)
Hi Reka,
It’s working. I’ll cont. testing other grouping scenarios
Thanks
Martin
From: Martin Eppel (meppel)
Sent: Monday, November 17, 2014 9:16 AM
To: [email protected]<mailto:[email protected]>
Subject: RE: [Grouping] Issue with dependencies in nested grouping scenario
(termination)
Ok,
Let you know how it goes,
Thanks
Martin
From: Reka Thirunavukkarasu [mailto:[email protected]]
Sent: Monday, November 17, 2014 4:38 AM
To: dev
Subject: Re: [Grouping] Issue with dependencies in nested grouping scenario
(termination)
Hi Martin,
I have fixed the issues found with current implementation and pushed the
changes. Can you take the pull and try out the same again?
This the result that i got from your definition.
1. Terminating "c1xxx" (deleting the VM through open stack UI) : member becomes
obsolete, VM is restarted – expected
2. terminating "c1alias51": Terminating VM "c1alias51" is restarted – as
expected
3. terminating "c1alias61": 1. Terminating cluster "c1alias61" and Termination
cluster "c1alias51" in parallel, 2. Restarted cluster "c1alias61", 3.
Restarted cluster "c1alias51"
4. terminating "c1alias71": 1. Terminating cluster "c1alias71", Termination
cluster "c1alias61" and Terminating cluster "c1alias51" in parallel, 2. Restart
cluster "c1alias71", 3. Restart cluster "c1alias61", 4. Restart cluster
"c1alias51"
If there is a start up dependent, then we will have to kill all the dependent
instances and bring them all again using start order. Please note that we have
achieved it by terminating the dependent clusters and recreate them again using
the startOrder.
I'm also in the process of testing for terminate-all case. Will update you on
that as well.
Thanks,
Reka
On Fri, Nov 14, 2014 at 5:42 PM, Reka Thirunavukkarasu
<[email protected]<mailto:[email protected]>> wrote:
Hi Martin,
I could get only the simple two dependent clusters working..When i tried with
your sample, i got few issues..I'm in the middle of testing the fix to make it
working..
I will do more testing on this and update you..
Thanks,
Reka
On Fri, Nov 14, 2014 at 10:55 AM, Reka Thirunavukkarasu
<[email protected]<mailto:[email protected]>> wrote:
Hi Martin,
I will try with your samples and update on how is it going..
Thanks,
Reka
On Fri, Nov 14, 2014 at 5:30 AM, Martin Eppel (meppel)
<[email protected]<mailto:[email protected]>> wrote:
Hi Reka, Isuru,
I was testing a scenario with nested groups:
“standalone” cartridge “cisco_sample_vm” (alias "c1xxx") - not defined in a
group, only in application
group7: has a cartridge “cisco_sample_vm” (alias "c1alias71") , no dependencies
group6: has a cartridge “cisco_sample_vm” ("c1alias61"), dependency on group7,
"terminationBehaviour": "terminate-dependents"
group5: has a cartridge “cisco_sample_vm” ("c1alias51"), dependency on group6,
"terminationBehaviour": "terminate-dependents"
startup works as expected : 1. "c1alias71", 2. "c1alias61", 3. "c1alias51”
Termination shows the following:
1. Terminating "c1xxx" (deleting the VM through open stack UI) : member becomes
obsolete, VM is restarted – expected
2. terminating "c1alias51": VM "c1alias51" is restarted – as expected
3. terminating "c1alias61": no change – expected result: 1. Termination of
"c1alias51", 2. Restart of "c1alias61",
4. terminating "c1alias71": no change – expected result: 1. Termination of
"c1alias61", 2. Termination of "c1alias51", 3. Restart of "c1alias71", 4.
Restart of "c1alias61", 5. Restart of "c1alias51"
I attached the group definitions, application definitions (I can provide logs
with debug enabled per request, didn’t want to send them to everyone on the
mailer)
Let me know I am wrong in my assumptions or the jsons are incorrect,
Thanks
Martin
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007<tel:%2B94776442007>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007<tel:%2B94776442007>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
--
<tel:%2B94776442007>
Thanks and Regards,
Isuru H.
<tel:%2B94776442007>
+94 716 358 048<tel:%2B94776442007>
