Yes we need to fix it. Should not call backend remove function if
application not in correct state for remove
On Wednesday, April 8, 2015, Udara Liyanage <ud...@wso2.com> wrote:
> Hi Lakmal,
>
> Application unemployment fails if application is not in DEPLOYED state.
> See the below error message in the logs. Yes as you mentioned we should
> Error/Invalid status should send as response if application in DEPLOYED
> (non removable) state.
>
> *Could not delete application: [application-id] cisco-sample-vm*
> *org.apache.stratos.autoscaler.exception.AutoScalerException: Application
> is in deployed state, please undeploy it before deleting: [application-id]
> cisco-sample-vm*
>
> On Wed, Apr 8, 2015 at 3:50 PM, Lakmal Warusawithana <lak...@wso2.com>
> wrote:
>
> Hi Udara
>
> Are we accepting remove call while application in un deployment process?
> If does that wrong. We should return error in remove API call if
> application not in created state IMO
>
>
> On Wednesday, April 8, 2015, Udara Liyanage <ud...@wso2.com> wrote:
>
> Hi Vanson,
>
> When I had a look at the logs attached. It seems that application removal
> is attempted immediately after the application undeployment(forceful). As I
> have already mentioned, even forceful undeployment takes a bit time since
> it invokes the graceful undeployment path. Inter component communication is
> done via event passing. Additionally forceful undeployment try once to
> terminate each instance. So you have to wait till undeployment finishes in
> order to remove the application.
>
> Yes, undeployment API call return just after it is invoked. But that does
> not implies undeployment is completed, it implies the undeployment job is
> accepted and will complete in future. You have to make another API call to
> get the status of the application and wait till it becomes CREATED to
> remove it.
>
> TID: [0] [STRATOS] [2015-04-08 02:19:57,979] INFO
> {org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl} -
> Forcefully undeploying the application cisco-sample-vm
> TID: [0] [STRATOS] [2015-04-08 02:19:58,727] ERROR
> {org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl} -
> Could not delete application: [application-id] cisco-sample-vm
>
>
>
> vm.cisco-sample-vm.domain8a869b76-0a7d-46af-8530-2ee4d23e5e3c
> TID: [0] [STRATOS] [2015-04-08 02:19:58,204] INFO
> {org.apache.stratos.cloud.controller.iaases.JcloudsIaas} - Starting to
> terminate member: [cartridge-type] cisco-sample-vm [member-id]
> cisco-sample-vm.cisco-sample-vm.cisco-sample-vm.domain8a869b76-0a7d-46af-8530-2ee4d23e5e3c
> TID: [0] [STRATOS] [2015-04-08 02:19:58,727] ERROR
> {org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl} -
> Could not delete application: [application-id] cisco-sample-vm.
>
> There is another exception in your log. I will have a loot at it and
> provide you an update.
>
> TID: [0] [STRATOS] [2015-04-08 02:20:45,074] ERROR
> {org.apache.stratos.cloud.controller.services.impl.InstanceCreator} -
> Could not start instance: [cartridge-type] cisco-sample-vm [cluster-id]
> cisco-sample-vm.cisco-sample-vm.cisco-sample-vm.domain
> java.lang.NullPointerException
> at
> org.apache.stratos.cloud.controller.services.impl.InstanceCreator.run(InstanceCreator.java:78)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
>
> On Wed, Apr 8, 2015 at 8:09 AM, Vanson Lim <v...@cisco.com> wrote:
>
> On 4/7/15, 1:04 AM, Udara Liyanage wrote:
>
> Hi Vanson,
>
> After analyzing the logs you have sent we could find the issue.
>
> 1) AS acquire logs for the cluster, after that
>
> *AS sends ClusterstatusTerminatedEvent
> *CC captures the above event and publish ClusterTerminatedEvent
> *AS act upon the ClusterTerminatedEvent event and remove the monitor and
> clusters.
> When clusters are removed, all the locks related to the cluster is also
> removed.
>
> If all above steps occurred before AS release the lock, the above
> mentioned error occurs since the lock is removed.
>
> Since the events are asynchronous, there is a chance that it might
> occur. We could reproduce it after adding a sleep before releasing the
> lock. We made a fix 8b4b615e96e855672d00cfa205b73725894385e6. Please take
> an update and see if the issue is appearing again.
>
>
> Udara,
>
> Still not having any luck with this. The rest API's are returning
> Success, but the wso2carbon.log file shows some errors. My test is running
> in a tight loops issuing a application:
> add/deploy/undeploy(force)/remove, Each time through the loop the
> instances is not being properly terminated so I am ending up with a lot of
> orphaned instances that stratos doesn't know about.
>
> wso2carbon.log attached.
>
> -Vanson
>
>
>
>
>
> On Tue, Apr 7, 2015 at 9:34 AM, Isuru Haththotuwa <isu...@apache.org>
> wrote:
>
> Hi Vanson,
>
> On Mon, Apr 6, 2015 at 11:38 PM, Vanson Lim <v...@cisco.com> wrote:
>
> On 4/4/15, 12:13 PM, Udara Liyanage wrote:
>
> Hi,
>
> I added forcefull undeployment which can be invoked as below.
> curl -X POST -H "Content-Type: application/json" -k -v -u admin:admin
> https://$
> {host_ip}:${host_port}/api/applications/${application_name}/undeploy?
> *force=true*
>
>
> Udara,
>
> I am not having any luck with the forceful delete api. I repeated try to
> run the following 4 steps:
>
> 1) add application
> 2) deploy application
> 3) undeploy application (force=true)
> 4) remove application
>
> Running steps 3 and 4 immediately after steps 1 & 2 seems to put stratos
> into a weird state, after which I can't can't reliably delete or add.
> Attached is the wso2carbon.log containing
> the traceback when I try steps 3&4 and see an error.
>
> This is a threading issue. I will also look in to this.
>
>
> -Vanson
>
> This is supposed to be executed when graceful undeployment does not
> complete successfully. This will try to terminate the instances once and
> send MemberTerminatedEvent regardless of termination process is successful
> or not. At the end Stratos should cleanup its internal memory and
> application should become CREATED. If stratos could not terminate instance,
> they should be manually terminated.
>
> Forceful termination can be invoked even without invoking graceful
> undeployment.
>
>
> On Tue, Mar 31, 2015 at 9:15 AM, Lakmal Warusawithana <lak...@wso2.com>
> wrote:
>
>
>
> On Mon, Mar 30, 2015 at 7:18 PM, Vanson Lim <v...@cisco.com> wrote:
>
> On 3/30/15, 9:18 AM, Lakmal Warusawithana wrote:
>
> IMO forceful un deploy is enough no need to have forceful delete. If un
> deployment success delete should work without any issues
>
>
> I agree, forceful undeploy should be enough. I assume this means that
> if I call undeploy (force=false) the first time and it doesn't work, I can
> call undeploy(force=true).
>
> In order for these api's to be robust, the create/deploy APIs should
> perform strict error checking and clean up of partial state when an
> exceptions are thrown. The code seems to do sufficient error checking but
> we keep encountering partial state left over when an exception is thrown.
>
> The undeploy force and/or delete APIs should ideally always cleanup even
> when detecting inconsistencies. We seem to be voting to handle this as a
> part of undeploy (force=true). I hope this means that an app MUST be
> cleanly transitioned back to "Created" state when we use (undeploy=force)
> and gracefully handle a subsequent deploy command.
>
>
> Yes, this is exactly what we need.
>
>
> -Vanson
>
>
>
>
>
> On Monday, March 30, 2015, Imesh Gunaratne <im...@apache.org> wrote:
>
> Thanks Vanson for pointing this scenario! Yes we would need to forcefully
> delete an application in certain scenarios.
>
> Udara: +1 For the suggestion!
>
> On Monday, March 30, 2015, Udara Liyanage <ud...@wso2.com> wrote:
>
> Hi,
>
> Sorry for the typo. We can add the flag as a query parameter.
>
> curl -X POST applications/single-cartridge-app/undeploy?*force=true*
>
> On Mon, Mar 30, 2015 at 10:04 AM, Udara Liyanage <ud...@wso2.com> wrote:
>
> Hi Imesh,
>
> How about the blow addition to the API?
>
> curl -X POST applications/single-cartridge-app/undeploy/*force=true*
>
> On Mon, Mar 30, 2015 at 9:48 AM, Udara Liyanage <ud...@wso2.com> wrote:
>
>
>
> On Sun, Mar 29, 2015 at 10:34 PM, Vanson Lim <v...@cisco.com> wrote:
>
> On 3/27/15, 5:57 PM, Vanson Lim wrote:
>
> On 3/27/15, 5:52 PM, Imesh Gunaratne wrote:
>
> Hi Vanson,
>
> I added a validation in Autoscaler to avoid applications being deleted
> while they are being undeployed in the background.
>
> Now the following error would be raised if this condition is met:
> "Application cannot be deleted, undeployment process is still in progress:
> [application-id] <application-id>".
>
> In addition I have implemented your suggestion to set the application
> status to CREATED once the application is completely undeployed. Now we can
> check from the API whether the application is undeployed properly. Please
> take a pull and verify.
>
>
>
>
> Took me a while to experiment with the failure cases.
>
> Some observations:
>
> 1) The change to check that the Application state changes to CREATED
> works. I am able to check that application status returns to Created before
> deleting.
>
> 2) Application delete throws tracebacks to the wso2carbon.log. IMO,
> this should only be informational rather then throw exceptions.
>
> I guess the reason for throwing an RuntimeException is to notify SM that
> an problem has occured while deleting the application. I will investigate
> firther.
>
>
> ie
>
> org.apache.stratos.autoscaler.exception.AutoScalerException: Application
> is in deployed state, please undeploy it before deleting: [application-id]
> cisco-sample-vm
> at
> org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl.deleteApplication(AutoscalerServiceImpl.java:411)
> 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.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:212)
> at
> org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver.invokeBusinessLogic(RPCInOnlyMessageReceiver.java:66)
> at
> org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:110)
> at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
> at
> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:172)
> at
> org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:146)
> at
> org.wso2.carbon.core.transports.CarbonServlet.doPost(CarbonServlet.java:231)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
> at
> org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61)
> at
> org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:128)
> at
> org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:68)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
> at
> org.wso2.carbon.tomcat.ext.servlet.DelegationServlet.service(DelegationServlet.java:68)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.wso2.carbon.tomcat.ext.filter.CharacterSetFilter.doFilter(CharacterSetFilter.java:61)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> at
> org.wso2.carbon.tomcat.ext.valves.CompositeValve.continueInvocation(CompositeValve.java:178)
> at
> org.wso2.carbon.tomcat.ext.valves.CarbonTomcatValve$1.invoke(CarbonTomcatValve.java:47)
> at
> org.wso2.carbon.webapp.mgt.TenantLazyLoaderValve.invoke(TenantLazyLoaderValve.java:56)
> at
> org.wso2.carbon.tomcat.ext.valves.TomcatValveContainer.invokeValves(TomcatValveContainer.java:47)
> at
> org.wso2.carbon.tomcat.ext.valves.CompositeValve.invoke(CompositeValve.java:141)
> at
> org.wso2.carbon.tomcat.ext.valves.CarbonStuckThreadDetectionValve.invoke(CarbonStuckThreadDetectionValve.java:156)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
> at
> org.wso2.carbon.tomcat.ext.valves.CarbonContextCreatorValve.invoke(CarbonContextCreatorValve.java:52)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1653)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> TID: [0] [STRATOS] [2015-03-28 00:17:52,952] ERROR
> {org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver} - Could not
> delete application: [application-id] cisco-sample-vm
> java.lang.RuntimeException: Could not delete application: [application-id]
> cisco-sample-vm
> at
> org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl.deleteApplication(AutoscalerServiceImpl.java:426)
> 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.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:212)
> at
> org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver.invokeBusinessLogic(RPCInOnlyMessageReceiver.java:66)
> at
> org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:110)
> at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
> at
> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:172)
> at
> org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:146)
> at
> org.wso2.carbon.core.transports.CarbonServlet.doPost(CarbonServlet.java:231)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
> at
> org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61)
> at
> org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:128)
> at
> org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:68)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
> at
> org.wso2.carbon.tomcat.ext.servlet.DelegationServlet.service(DelegationServlet.java:68)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.wso2.carbon.tomcat.ext.filter.CharacterSetFilter.doFilter(CharacterSetFilter.java:61)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> at
> org.wso2.carbon.tomcat.ext.valves.CompositeValve.continueInvocation(CompositeValve.java:178)
> at
> org.wso2.carbon.tomcat.ext.valves.CarbonTomcatValve$1.invoke(CarbonTomcatValve.java:47)
> at
> org.wso2.carbon.webapp.mgt.TenantLazyLoaderValve.invoke(TenantLazyLoaderValve.java:56)
> at
> org.wso2.carbon.tomcat.ext.valves.TomcatValveContainer.invokeValves(TomcatValveContainer.java:47)
> at
> org.wso2.carbon.tomcat.ext.valves.CompositeValve.invoke(CompositeValve.java:141)
> at
> org.wso2.carbon.tomcat.ext.valves.CarbonStuckThreadDetectionValve.invoke(CarbonStuckThreadDetectionValve.java:156)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
> at
> org.wso2.carbon.tomcat.ext.valves.CarbonContextCreatorValve.invoke(CarbonContextCreatorValve.java:52)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1653)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.stratos.autoscaler.exception.AutoScalerException:
> Application is in deployed state, please undeploy it before deleting:
> [application-id] cisco-sample-vm
> at
> org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl.deleteApplication(AutoscalerServiceImpl.java:411)
> ... 44 more
>
>
> 3) I am hitting the "redeploy application issue" that was fixed yesterday
> as a part of testing this fix and found that the application is in a
> broken state after an application redeploy such that application delete
> doesn't work anymore because the partially deployed application is in stuck
> in the "Deployed" state.
>
> This is similar to a valid use case which application delete doesn't
> currently handle. Our current implementation of application delete only
> works gracefully if the application is well behaved. If we have a single
> VM that is unresponsive to a terminate event, won't the application
> permanently be stuck in a "Deployed" state? This leads me to think that
> application delete needs to able to clean up all the state in the various
> components that make up stratos instead of preventing the delete requests
> regardless of the cluster instance counts or application status. In other
> words, the request should always be honored, otherwise we have no way of
> forcing the undeploy and deletion of an application. If the user wants to
> be graceful, they have the option to poll the application state changes
> using the application GET api before calling the application delete API.
>
>
> Your point seems to be valid since with the above fix, application will
> not be able to be deleted if it doesn't become created for some reason. One
> solution is to let the user explicitly specify to delete forcefully which
> will delete the application regardless of the state. I will do a further
> analysis and get back to you.
>
>
> -Vanson
>
> okay, will give it a try.
>
> -Vanson
>
> Thanks
>
> On Sat, Mar 28, 2015 at 2:40 AM, Vanson Lim <v...@cisco.com> wrote:
>
> On 3/27/15, 2:26 PM, Imesh Gunaratne wrote:
>
> Hi Vanson,
>
> I analyzed this issue. Logically we cannot delete an application soon
> after un-deploying it. The reason is that the un-deployment process
> executes gracefully on each member in all the clusters in an application.
> Depending on the complexity of the application, it may take some time to
> completely terminate all the members, remove the clusters and then
> un-deploy the application.
>
> IMO what we are missing here is a validation in the delete application
> API method, to tell the API client that an application cannot be deleted
> until it is completely un-deployed.
>
> Imesh,
>
> Thanks for looking at this.
>
> It sounds reasonable to hold off the removing to application and also have
> the remove rest api call return that it's not ready. For applications
> consisting of a lot of groups and cartridges the time to clean up could be
> variable. Could we use the Rest api to get the application status, ie
> check that status=Created before deleting.
>
> ie this api:
>
>
> https://cwiki.apache.org/confluence/display/STRATOS/4.1.0+Getting+Details+of+an+Application+via+REST+API
>
> It looks like an application has two states: "Created" and "Deployed".
> If we had a Undeploying state, then we could check and hold off
> requesting the remove-application until it returns to the Created state.
>
> -Vanson
>
>
> Thanks
> Imesh
>
> On Wed, Mar 25, 2015 at 12:10 PM, Udara Liyanage <ud...@wso2.com> wrote:
>
> Hi,
>
> This arises when the application is deleted immediately after the
> application underemployment. I guess CC does not have the member context
> when the application is removed. I will have a look.
>
> A simple workaround it to wait sometime to remove application after
> undeployment.
>
> On Tue, Mar 24, 2015 at 9:06 AM, Imesh Gunaratne <im...@apache.org> wrote:
>
> Thanks Martin! We will have a look at this.
>
> On Tue, Mar 24, 2015 at 1:21 AM, Martin Eppel (meppel) <mep...@cisco.com>
> wrote:
>
> I opened a jira https://issues.apache.org/jira/browse/STRATOS-1281 to
> track the issue,
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
> *From:* Imesh Gunaratne [mailto:im...@apache.org]
> *Sent:* Friday, March 20, 2015 3:27 AM
> *To:* dev
> *Subject:* Re: Stratos 4.1.0 - tracebacks seen when issuing application
> undeploy/remove
>
>
>
> Hi Vanson,
>
>
>
> Thanks for reporting this problem. According to the logs stratos is trying
> to remove the same member twice in this flow:
>
>
>
> TID: [0] [STRATOS] [2015-03-19 19:45:43,952] INFO
> {org.apache.stratos.messaging.message.processor.application.ApplicationDeletedMessageProcessor}
> - [Application] cisco-sample-vm has been successfully removed
>
> TID: [0] [STRATOS] [2015-03-19 19:45:44,786] INFO
> {org.apache.stratos.cloud.controller.iaases.JcloudsIaas} - Member
> terminated: [member-id]
> cisco-sample-vm.cisco-sample-vm.cisco-sample-vm.domain41624077-30c4-4bfe-a2a8-ece2fc4f550d
>
>
>
> TID: [0] [STRATOS] [2015-03-19 19:45:50,012] INFO
> {org.apache.stratos.common.client.CloudControllerServiceClient} -
> Terminating instance via cloud controller: [member]
> cisco-sample-vm.cisco-sample-vm.cisco-sample-vm.domain41624077-30c4-4bfe-a2a8-ece2fc4f550d
>
> TID: [0] [STRATOS] [2015-03-19 19:45:50,017] ERROR
> {org.apache.stratos.cloud.controller.services.impl.CloudControllerServiceImpl}
> - Could not terminate instance, member context not found: [member-id]
> cisco-sample-vm.cisco-sample-vm.cisco-sample-vm.domain41624077-30c4-4bfe-a2a8-ece2fc4f550d
>
>
>
> We might need to investigate and see what's causing this.
>
>
>
> Thanks
>
>
>
>
>
> On Fri, Mar 20, 2015 at 6:55 AM, Vanson Lim <v...@cisco.com> wrote:
>
> Hi,
>
> We are testing the behavior of stratos 4.1.0 rest api's and found that if
> we issue an undeploy-application followed immediately with
> application-remove, that we see the following traceback.
>
> The VM successfully get's deleted but not sure what kind of side effects
> this has on the system.
>
> Here's the snippet from the wso2carbon.log file. I've also attached the
> entire log.
>
> Steps to reproduce this:
>
> 1) deploy an application which leads to startup a single instance of a
> cartridge.
> 2) wait for it to become active
> 3) issue the undeploy application and application remove rest api calls.
>
>
> -Vanson
>
>
>
> TID: [0] [STRATOS] [2015-03-19 19:45:08,681] INFO
> {org.wso2.carbon.databridge.core.DataBridge} - admin connected
> TID: [0] [STRATOS] [2015-03-19 19:45:43,023] INFO
> {org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl} -
> Starting to undeploy application: [application-id] cisco-sample-vm
> TID: [0] [STRATOS] [2015-03-19 19:45:43,024] INFO
> {org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl} -
> Removing application signup: [application-id] cisco-sample-vm
> TID: [0] [STRATOS] [2015-03-19 19:45:43,051] INFO
> {org.apache.stratos.manager.components.ApplicationSignUpHandler} - Removing
> application signup: [application-id] cisco-sample-vm [tenant-id] -1234
> TID: [0] [STRATOS] [2015-03-19 19:45:43,084] INFO
> {org.apache.stratos.manager.components.ApplicationSignUpHandler} -
> Application signup removed successfully: [application-id] cisco-sample-vm
> [tenant-id] -1234
> TID: [0] [STRATOS] [2015-03-19 19:45:43,091] INFO
> {org.apache.stratos.autoscaler.context.AutoscalerContext} - Network
> partition algorithm context is removed successfully: [id] cisco-sample-vm
> TID: [0] [STRATOS] [2015-03-19 19:45:43,092] INFO
> {org.apache.stratos.autoscaler.monitor.cluster.ClusterMonitor} - Publishing
> Cluster terminating event for [application] cisco-sample-vm [cluster]
> cisco-sample-vm.cisco-sample-vm.cisco-sample-vm.domain [instance]
> cisco-sample-vm-1
> TID: [0] [STRATOS] [2015-03-19 19:45:43,109] INFO
> {org.apache.stratos.cloud.controller.messaging.topology.TopologyBuilder} -
> Cluster Terminating adding status started
> forcisco-sample-vm.cisco-sample-vm.cisco-sample-vm.domain
> TID: [0] [STRATOS] [2015-03-19 19:45:43,117] INFO
> {org.apache.stratos.autoscaler.applications.topic.ApplicationsEventPublisher}
> - Publishing application inactivated event: [application] cisco-sample-vm
> [instance] cisco-sample-vm-1
> TID: [0] [STRATOS] [2015-03-19 19:45:43,120] INFO
> {org.apache.stratos.cloud.controller.messaging.publisher.TopologyEventPublisher}
> - Publishing Cluster terminating event: [application-id] cisco-sample-vm
> [cluster id] cisco-sample-vm.cisco-sample-vm.cisco-sample-vm.domain
> [instance-id] cisco-sample-vm-1
> TID: [0] [STRATOS] [2015-03-19 19:45:43,144] INFO
> {org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl} -
> Application undeployed successfully: [application-id] cisco-sample-vm
> TID: [0] [STRATOS] [2015-03-19 19:45:43,154] INFO
> {org.apache.stratos.autoscaler.event.receiver.topology.AutoscalerTopologyEventReceiver}
> - [ClusterTerminatingEvent] Received: class
> org.apache.stratos.messaging.event.topology.ClusterInstanceTerminatingEvent
> TID: [0] [STRATOS] [2015-03-19 19:45:43,155] INFO
> {org.apache.stratos.autoscaler.event.publisher.InstanceNotificationPublisher}
> - Publishing Instance Cleanup Event: [cluster]
> cisco-sample-vm.cisco-sample-vm.cisco-sample-vm.domain
> TID: [0] [STRATOS] [2015-03-19 19:45:43,171] WARN
> {org.apache.stratos.autoscaler.status.processor.cluster.ClusterStatusActiveProcessor}
> - No possible state change found for [type] [cluster]
> cisco-sample-vm.cisco-sample-vm.cisco-sample-vm.domain
>
>
--
Sent from Gmail Mobile
