stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vanson Lim <v...@cisco.com>
Subject Re: Stratos 4.1.0 - tracebacks seen when issuing application undeploy/remove
Date Fri, 10 Apr 2015 03:04:00 GMT
On 4/9/15, 11:30 AM, Udara Liyanage wrote:
> Hi,
>
> I added some more validations to API calls to let the API call pass only resources are
in accepted states.
>
> Add Application
> If an application with the same id does not exist
>
> Remove Application
> An application with the given id should exist
> Application should be in  CREATED state
>
> DEPLOY Application
> An application with the given id should exist
> Application should be in  CREATED state
>
> Undeploy Application
> An application with the given id should exist
> Application should be in  Deployed state
>
> I tried reproducing the below mentioned error message, but could not. However analyzing
the code, it seems that CEP tries to send faulty 
> event to the members which does not exist in the topology. I guess this will not impact
the functionality of the system
> TID: [0] [STRATOS] [2015-04-09 02:27:45,631] ERROR {org.apache.stratos.cep.extension.FaultHandlingWindowProcessor}
-  Failed to publish 
> member fault event. Member having [member-id] cisco-sample-vm.cisco-sample-vm.cisco-sample-vm.domain88eddc38-ad4a-4ff7-843c-b9dbc1603bab

> does not exist in topology

I am not seeing it anymore but I still have some issues.   The system is definitely more well
behaved after pulling in your most recent 
changes, but I am still able to get the system into an unresponsive state.     if I invoke
application undeploy too soon after an 
application deploy I am able to get the system into a state where I can still deploy an application,
but there is some inconsistency where 
the deployed application won't launch VMs and won't undeploy.

Do you have any more suggestions on what I can do?  I currently poll that the application
is in DEPLOYED state before attempt to undeploy, 
but it doesn't make a difference.    Changing the delay (between deploy and undeploy) from
10 to 30 seconds improves things such that the 
system is still works, but I see a few orphaned instances (which I suspect might be a variant
of the jcloud issues we still in Stratos-1293.

I've attached another log.


-Vanson

>
> On Thu, Apr 9, 2015 at 10:24 AM, Shavindri Dissanayake <shavindri@wso2.com <mailto:shavindri@wso2.com>>
wrote:
>
>     Thank you Udara!
>
>     Thanks & Regards
>     Shavindri Dissanayake
>     Technical Writer
>     LinkedIn Profile <https://www.linkedin.com/profile/view?id=112227277&trk=nav_responsive_tab_profile>
>     Mob: 0779966739 <tel:0779966739>
>
>     WSO2 Inc.
>     lean.enterprise.middleware
>
>     On Thu, Apr 9, 2015 at 10:04 AM, Udara Liyanage <udara@wso2.com <mailto:udara@wso2.com>>
wrote:
>
>
>         ​Hi Shavi,
>
>         CLI and UI does not include this yet, but should.
>
>
>
>
>
> -- 
>
> Udara Liyanage
> Software Engineer
> WSO2, Inc.: http://wso2.com <http://wso2.com/>
> lean. enterprise. middleware
>
> web: http://udaraliyanage.wordpress.com
> phone: +94 71 443 6897


Mime
View raw message