You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Chamila De Alwis <ch...@wso2.com> on 2015/02/19 11:11:23 UTC

[Discuss] - Cartridge Agent Workflow and Activated status without ports activity

Hi,

I'm working on the Java Cartridge agent modification to get it to a
matching state with the Python Cartridge Agent. In the process, I came up
with the following diagram of what the main flow of the Cartridge Agent
should be [1].


​
I've also noticed a few irregularities too. It seems in both agents,
InstanceActivatedEvent is published regardless of the ports status (active
or not). This means that a service might not be up in the instance, even
though that instance is marked as active.  For repository based cartridges
ArtifactUpdatedEvent handler does not check whether the ports are active or
not. For non repository based cartridges too there is no check to see if
the ports are active or not.

There is another possibility of instances publishing active status before
the ports activity is checked. If the ports take a considerable time to
activate, during that time the ArtifactUpdatedEvent can be processed and
again the InstanceActivatedEvent can be published without any safe guard.
Although these are minor instances, the potential for inconsistent member
status happening is there.

Akila has reported this issue a while back too [2]. Is there a particular
reason for this design (and am I missing anything here)?


[1] - https://creately.com/diagram/i6bxoj9b1/TJlrvWoZkxqK8mi27aXCKWazI%3D
[2] - https://issues.apache.org/jira/browse/STRATOS-766

Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com

Re: [Discuss] - Cartridge Agent Workflow and Activated status without ports activity

Posted by Chamila De Alwis <ch...@wso2.com>.
Hi Imesh,

Thanks for the feedback! My intention was to first get the main flow in a
diagram. Since event handlers are started asynchronously I didn't include
them in this one. I will improve this to include the asynchronous tasks as
well.




Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com



On Fri, Feb 20, 2015 at 10:20 AM, Imesh Gunaratne <im...@apache.org> wrote:

> Hi Chamila,
>
> Thanks for drawing the work flow diagram of cartridge agent. I have few
> comments:
>
> - Better not to mix the term extension with plugin. IMO fourth box should
> not mention "plugin", it should be an extension.
> - An extension should be mapped to an event, where as a plugin would map
> to multiple events and provide a feature.
> - I know you are planning to execute extensions using plugins due to the
> blocking issue found when invoking them using processes. But better not to
> use the term plugin there. Will call them python extensions and shell
> script extensions.
> - I think server port check should happen as a pre-condition of publishing
> Instance Activated event.
> - I cannot see the work flow that happens after receiving the Artifact
> Updated event.
>
> Thanks
>
> On Thu, Feb 19, 2015 at 3:41 PM, Chamila De Alwis <ch...@wso2.com>
> wrote:
>
>> Hi,
>>
>> I'm working on the Java Cartridge agent modification to get it to a
>> matching state with the Python Cartridge Agent. In the process, I came up
>> with the following diagram of what the main flow of the Cartridge Agent
>> should be [1].
>>
>>
>> ​
>> I've also noticed a few irregularities too. It seems in both agents,
>> InstanceActivatedEvent is published regardless of the ports status (active
>> or not). This means that a service might not be up in the instance, even
>> though that instance is marked as active.  For repository based cartridges
>> ArtifactUpdatedEvent handler does not check whether the ports are active or
>> not. For non repository based cartridges too there is no check to see if
>> the ports are active or not.
>>
>> There is another possibility of instances publishing active status before
>> the ports activity is checked. If the ports take a considerable time to
>> activate, during that time the ArtifactUpdatedEvent can be processed and
>> again the InstanceActivatedEvent can be published without any safe guard.
>> Although these are minor instances, the potential for inconsistent member
>> status happening is there.
>>
>> Akila has reported this issue a while back too [2]. Is there a particular
>> reason for this design (and am I missing anything here)?
>>
>>
>> [1] - https://creately.com/diagram/i6bxoj9b1/TJlrvWoZkxqK8mi27aXCKWazI%3D
>> [2] - https://issues.apache.org/jira/browse/STRATOS-766
>>
>> Regards,
>> Chamila de Alwis
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>

Re: [Discuss] - Cartridge Agent Workflow and Activated status without ports activity

Posted by Imesh Gunaratne <im...@apache.org>.
Hi Chamila,

Thanks for drawing the work flow diagram of cartridge agent. I have few
comments:

- Better not to mix the term extension with plugin. IMO fourth box should
not mention "plugin", it should be an extension.
- An extension should be mapped to an event, where as a plugin would map to
multiple events and provide a feature.
- I know you are planning to execute extensions using plugins due to the
blocking issue found when invoking them using processes. But better not to
use the term plugin there. Will call them python extensions and shell
script extensions.
- I think server port check should happen as a pre-condition of publishing
Instance Activated event.
- I cannot see the work flow that happens after receiving the Artifact
Updated event.

Thanks

On Thu, Feb 19, 2015 at 3:41 PM, Chamila De Alwis <ch...@wso2.com> wrote:

> Hi,
>
> I'm working on the Java Cartridge agent modification to get it to a
> matching state with the Python Cartridge Agent. In the process, I came up
> with the following diagram of what the main flow of the Cartridge Agent
> should be [1].
>
>
> ​
> I've also noticed a few irregularities too. It seems in both agents,
> InstanceActivatedEvent is published regardless of the ports status (active
> or not). This means that a service might not be up in the instance, even
> though that instance is marked as active.  For repository based cartridges
> ArtifactUpdatedEvent handler does not check whether the ports are active or
> not. For non repository based cartridges too there is no check to see if
> the ports are active or not.
>
> There is another possibility of instances publishing active status before
> the ports activity is checked. If the ports take a considerable time to
> activate, during that time the ArtifactUpdatedEvent can be processed and
> again the InstanceActivatedEvent can be published without any safe guard.
> Although these are minor instances, the potential for inconsistent member
> status happening is there.
>
> Akila has reported this issue a while back too [2]. Is there a particular
> reason for this design (and am I missing anything here)?
>
>
> [1] - https://creately.com/diagram/i6bxoj9b1/TJlrvWoZkxqK8mi27aXCKWazI%3D
> [2] - https://issues.apache.org/jira/browse/STRATOS-766
>
> Regards,
> Chamila de Alwis
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>


-- 
Imesh Gunaratne

Technical Lead, WSO2
Committer & PMC Member, Apache Stratos