Hi Dev,
I updated the CEP and DAS configurations based on the changes for Stratos
4.1.5.
[1]
https://cwiki.apache.org/confluence/display/STRATOS/4.1.x+Configuring+WSO2+Complex+Event+Processor+with+Stratos
[2]
https://cwiki.apache.org/confluence/display/STRATOS/4.1.x+Configuring+WSO2+Data+Analyti
[
https://issues.apache.org/jira/browse/STRATOS-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chamila de Alwis updated STRATOS-1644:
--
Affects Version/s: (was: 4.1.4)
4.1.5
> Python Cartridge Ag
[
https://issues.apache.org/jira/browse/STRATOS-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chamila de Alwis updated STRATOS-1644:
--
Fix Version/s: (was: FUTURE)
4.1.5
> Python Cartridge Agent uti
[
https://issues.apache.org/jira/browse/STRATOS-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chamila de Alwis updated STRATOS-1644:
--
Fix Version/s: (was: 4.1.5)
FUTURE
> Python Cartridge Agent uti
Chamila de Alwis created STRATOS-1644:
-
Summary: Python Cartridge Agent utilizes almost 100% CPU
Key: STRATOS-1644
URL: https://issues.apache.org/jira/browse/STRATOS-1644
Project: Stratos
IMO the threading issue and Git command execution based on a python library
are high priority. We might need to immediately address them. Others can be
considered as low priority.
Writing agent in Go is a good thought but we might need to evaluate the
effort, advantages & disadvantages first.
Tha
Hi Chamila,
On Sat, Dec 12, 2015 at 1:34 AM, Chamila De Alwis wrote:
> Hi devs,
>
> During the testing of the Python Cartridge Agent in the past few weeks we
> were able to identify a few points where performance and functionality
> could be improved.
>
> *1 - Agent's thread utilization *
> It
Main idea behind Python based Cartridge agent is lightweight of the agent
and most of the common operating system comes up with the in build support
with python.Also with python cartridge agent we will be able to execute a
code irrespective of the Operating System on which it is being executed. By
Hi Akila,
I agree that's an exciting road to take, but wouldn't we come across the
same issues, design related and trivial ones like choosing a proper
library, if we rewrite this in Go? Since most of the existing agent is
working and proven code, I think at this point crossing over to Go wouldn't
