stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reka Thirunavukkarasu (JIRA)" <>
Subject [jira] [Commented] (STRATOS-1489) Faulty behavior in application monitor creation logic
Date Fri, 21 Aug 2015 12:24:45 GMT


Reka Thirunavukkarasu commented on STRATOS-1489:

This is fixed in  Commit: 0c794b098e1f28414cc9330eb68fe6aa12231ead.

> Faulty behavior in application monitor creation logic
> -----------------------------------------------------
>                 Key: STRATOS-1489
>                 URL:
>             Project: Stratos
>          Issue Type: Bug
>    Affects Versions: 4.1.0
>            Reporter: Akila
> When a user sign up for an application, AS makes a service call to CC and executed "createApplicationClusters"
method which will publish ApplicationClustersCreated event. There is a separate event listener
for this event in AS side which will start cluster monitors upon receiving this event. But
in this listener AS first checks whether this corresponding application's status is set to
DEPLOYED state. If not it will wait for 5 seconds and print following warning;
> WARN {org.apache.stratos.autoscaler.event.receiver.topology.AutoscalerTopologyEventReceiver}
-  Application monitor creation is not triggered on application clusters created event even
after 5 retries [application-id] xxxxxx-xxxxx. Possible cause is either application context
is null or application status didn't become Deployed yet.
> In the code [1] there is no way to recover if the application doesn't get updated to
DEPLOYED status within the given 5 seconds timeout window. There is a comment in the code
which says that the reason for not throwing an error is because this is not the only place
where it starts monitors. But the only other place I could find is upon receiving CompleteTopologyEvent.
But that event is processed only at the very first time.
> Therefore, there is no way to recover from this error state, and it does not throw an
error either. This logic needs to be improved.
> [1]

This message was sent by Atlassian JIRA

View raw message