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 [instance]
> TID: [0] [STRATOS] [2015-03-19 19:45:43,192] INFO
> {org.apache.stratos.cloud.controller.messaging.topology.TopologyBuilder}
>
>
--
Sent from Gmail Mobile
