[Carbon-dev] Fwd: API Store/Management Monitoring
Forwarding to carbon-dev -- Forwarded message -- From: Sumedha Rubasinghe sume...@wso2.com Date: Mon, Feb 20, 2012 at 1:57 PM Subject: Re: API Store/Management Monitoring To: Johann Nallathamby joh...@wso2.com, Tharindu Mathew thari...@wso2.com Cc: WSO2 Strategy strategy-gr...@wso2.com On Mon, Feb 20, 2012 at 1:52 PM, Tharindu Mathew thari...@wso2.com wrote: Any reason this conversation is private? Sorry did not realize it. Johann, move this to carbon-dev please. /sumedha On Mon, Feb 20, 2012 at 1:47 PM, Sumedha Rubasinghe sume...@wso2.comwrote: I think this enough for the MVP. If we focus of few reports/charts, this would be much easier to figure out what data is needed to generate them. eg: 1. List of APIs against it's total user count (may be a pie chart) 2. API, version it's user count (tabular representation) 3. API, version, user activity - eg. access time history, accessed operations 4. API, version performance (no of requests, no of responses, success, failure, avg. response time) /sumedha On Mon, Feb 20, 2012 at 12:24 PM, Johann Nallathamby joh...@wso2.comwrote: Hi, In the API Store/Management Monitoring component, we are publishing monitoring data to BAM using Activity Mediation Data Publisher. For now we are only monitoring API usage via the consumer key. What are some of the other data/statistics that need to be published/monitored? Thanks, Johann. -- /sumedha +94 773017743 -- Regards, Tharindu blog: http://mackiemathew.com/ M: +9459908 -- /sumedha +94 773017743 ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
[Carbon-dev] Error when building gadgets component.
I am getting the following error when building gadgets component at [1]. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project org.wso2.carbon.gadget.initializer: Compilation failure [ERROR] /home/shariq/src/trunk/graphite/components/gadgets/org.wso2.carbon.gadget.initializer/src/main/java/org/wso2/carbon/gadget/initializer/modules/social/services/GSPersonService.java:[138,4] method does not override or implement a method from a supertype [ERROR] - [Help 1] [ERROR] [1] - https://svn.wso2.org/repos/wso2/trunk/graphite/components/gadgets -- Thanks, Shariq. Phone: +94 777 202 225 ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Error when building gadgets component.
Hi, I am looking into this. Thanks, On Mon, Feb 20, 2012 at 2:42 PM, Muhammed Shariq sha...@wso2.com wrote: I am getting the following error when building gadgets component at [1]. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project org.wso2.carbon.gadget.initializer: Compilation failure [ERROR] /home/shariq/src/trunk/graphite/components/gadgets/org.wso2.carbon.gadget.initializer/src/main/java/org/wso2/carbon/gadget/initializer/modules/social/services/GSPersonService.java:[138,4] method does not override or implement a method from a supertype [ERROR] - [Help 1] [ERROR] [1] - https://svn.wso2.org/repos/wso2/trunk/graphite/components/gadgets -- Thanks, Shariq. Phone: +94 777 202 225 ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Achala Aponso Software Engineer; WSO2 Inc.; http://wso2.com, Email: ach...@wso2.com Mobile: +94 (77) 5234925 Blog: http://achala11.blogspot.com/ ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] [Update] JVM Autoscaler
Hi Nirmal, Good progress!. we can do a review on the work already done. Did you try the agent in windows? Is it using any native code? See some comments below. On Sat, Feb 18, 2012 at 11:10 PM, Nirmal Fernando nir...@wso2.com wrote: Hi All, I've started to implement 'new autoscaler architecture' [1] on February 8th. After having a discussion with Azeez, we came up with three milestones for the first iteration. --- M1: Make a WS call spawns a new JVM instance make the new instance joins the cluster with hard coded Agents. M2: Finish Agent registration related parts and spawn a new instance in a selected Agent. M3: Let current autoscaler component calls 'AutoscalerService' and spawns a new JVM instance in a selected Agent. Also applying WS security. --- I've attached set of images which depicts different stages of new architecture. Reading order of images is as follows: agent-reg -- autoscaler -- spawn -- cluster M1 is already finished. I've almost done the Agent registration (M2) aspect. What it does now? AgentManagementService and AutoscalerService should be deployed in the back-end server. (say: IP is 192.168.1.2) AgentService should be deployed in machines (i.e. where new JVM instances will be spawned). (say: IP is 192.168.1.3) AgentService do a web service call (eg: curl -X GET http://localhost:8080/axis2/services/AgentService/agent) to AgentManagementService and get registered. Then AgentManagementService stores the URL (eg: http://192.168.1.3:8080/axis2/services/AgentService/) of that particular request. When autoscaler API (implementing this is M3) wanted to spawn a new instance (JVM or EC2 or anything else), it should call AutoscalerService (eg: curl --data instanceName=as -X POST http://192.168.1.2:8080/axis2/services/AutoscalerService/instance). Then AutoscalerService decides which kind of instance to spawn. If AutoscalerService decides to spawn a JVM instance, it creates a new JVMAdaptor instance. JVMAdaptor then calls (eg: curl -X GET http://192.168.1.2:8080/axis2/services/AgentManagementService/agent) AgentManagementService in order to pick an Agent. AgentManagementService picks an Agent in a round robin manner and sends back that Agent's EPR (http://192.168.1.3:8080/axis2/services/AgentService/) to JVMAdaptor. Then JVMAdaptor does a web service call to that particular AgentService and asked it to spawn the requested instance (instance is yet hard coded). Spawned instance then joins the cluster. Current observations: Currently starting instance aspect is done. I've tested this using 2 machines, and starting instance works fine. It is observed that the spawned JVM instances get killed when you issue 'ctrl+c' in the terminal where axis2 running. But when I killed axis2server.sh process only, the new JAVA process wasn't get killed. To avoid process get killing when issue ctrl+c, we might need to handle SIGINT [2]. Can't we be happy with the fact that it doesn't get killed after killing axis2server.sh? JVMs (which were created) should live even if you kill the agent. Work to be done: Terminating and finding instance aspects should be addressed. You have to keep track of which JVMs/VMs created by the autoscaler. Otherwise you will not be able to stop them when you want to scale down. I believe, this information should be stored/kept with autoscaler service. The 'sad side' (when things go wrong) should be addressed. AgentServices should know EPR of AgentManagementService (this is hard coded now). Should read from a config file? +1 fore reading from config file. JVMAdaptor should keep a map of Agent EPR to AgentService client, to avoid creating multiple clients to access the same Agent. AgentService should keep a count of spawned instances and get itself unregistered if it can't handle any new instances (threshold value should be decided). And when it feels (another threshold) that it can handle new instances it should register again. Autoscaler API should be designed. Should port EC2 client to EC2Adaptor. Should test the whole scenario. I appreciate your comments/thoughts on above facts. [1] http://mail.wso2.org/mailarchive/architecture/2011-October/006414.html [2] http://www.cons.org/cracauer/sigint.html -- Thanks regards, Nirmal Software Engineer- Platform Technologies Team, WSO2 Inc. Mobile: +94715779733 Blog: http://nirmalfdo.blogspot.com/ -- S.Uthaiyashankar Senior Architect Senior Manager WSO2 Inc. http://wso2.com/ - lean . enterprise . middleware Phone: +94
Re: [Carbon-dev] Error when building gadgets component.
Hi, This is fixed now. The reason was a change in the shindig person api. The next release version of shindig trunk has been changed to 2.5.0. I changed the versions according to the shindig trunk version. Please take a svn update. Thanks, On Mon, Feb 20, 2012 at 2:58 PM, Achala Aponso ach...@wso2.com wrote: Hi, I am looking into this. Thanks, On Mon, Feb 20, 2012 at 2:42 PM, Muhammed Shariq sha...@wso2.com wrote: I am getting the following error when building gadgets component at [1]. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project org.wso2.carbon.gadget.initializer: Compilation failure [ERROR] /home/shariq/src/trunk/graphite/components/gadgets/org.wso2.carbon.gadget.initializer/src/main/java/org/wso2/carbon/gadget/initializer/modules/social/services/GSPersonService.java:[138,4] method does not override or implement a method from a supertype [ERROR] - [Help 1] [ERROR] [1] - https://svn.wso2.org/repos/wso2/trunk/graphite/components/gadgets -- Thanks, Shariq. Phone: +94 777 202 225 ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Achala Aponso Software Engineer; WSO2 Inc.; http://wso2.com, Email: ach...@wso2.com Mobile: +94 (77) 5234925 Blog: http://achala11.blogspot.com/ -- Achala Aponso Software Engineer; WSO2 Inc.; http://wso2.com, Email: ach...@wso2.com Mobile: +94 (77) 5234925 Blog: http://achala11.blogspot.com/ ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Error when building gadgets component.
On Mon, Feb 20, 2012 at 5:58 PM, Achala Aponso ach...@wso2.com wrote: Hi, This is fixed now. The reason was a change in the shindig person api. The next release version of shindig trunk has been changed to 2.5.0. I changed the versions according to the shindig trunk version. Please take a svn update. Builds fine now, thanks! Thanks, On Mon, Feb 20, 2012 at 2:58 PM, Achala Aponso ach...@wso2.com wrote: Hi, I am looking into this. Thanks, On Mon, Feb 20, 2012 at 2:42 PM, Muhammed Shariq sha...@wso2.com wrote: I am getting the following error when building gadgets component at [1]. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project org.wso2.carbon.gadget.initializer: Compilation failure [ERROR] /home/shariq/src/trunk/graphite/components/gadgets/org.wso2.carbon.gadget.initializer/src/main/java/org/wso2/carbon/gadget/initializer/modules/social/services/GSPersonService.java:[138,4] method does not override or implement a method from a supertype [ERROR] - [Help 1] [ERROR] [1] - https://svn.wso2.org/repos/wso2/trunk/graphite/components/gadgets -- Thanks, Shariq. Phone: +94 777 202 225 ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Achala Aponso Software Engineer; WSO2 Inc.; http://wso2.com, Email: ach...@wso2.com Mobile: +94 (77) 5234925 Blog: http://achala11.blogspot.com/ -- Achala Aponso Software Engineer; WSO2 Inc.; http://wso2.com, Email: ach...@wso2.com Mobile: +94 (77) 5234925 Blog: http://achala11.blogspot.com/ ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Thanks, Shariq. Phone: +94 777 202 225 ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] [Update] JVM Autoscaler
Hi Shankar, On Mon, Feb 20, 2012 at 5:34 PM, Selvaratnam Uthaiyashankar shan...@wso2.com wrote: Hi Nirmal, Good progress!. we can do a review on the work already done. Thanks, will arrange a review this week. Did you try the agent in windows? No, I didn't! Is it using any native code? It needs to use native code in cases like spawning a new JVM (in Ubuntu we need /bin/sh to run the script 'wso2server.sh' in windows we need to run the batch file. But I believe this can be handled within the code it self by checking the OS name and execute appropriate commands! See some comments below. On Sat, Feb 18, 2012 at 11:10 PM, Nirmal Fernando nir...@wso2.com wrote: Hi All, I've started to implement 'new autoscaler architecture' [1] on February 8th. After having a discussion with Azeez, we came up with three milestones for the first iteration. --- M1: Make a WS call spawns a new JVM instance make the new instance joins the cluster with hard coded Agents. M2: Finish Agent registration related parts and spawn a new instance in a selected Agent. M3: Let current autoscaler component calls 'AutoscalerService' and spawns a new JVM instance in a selected Agent. Also applying WS security. --- I've attached set of images which depicts different stages of new architecture. Reading order of images is as follows: agent-reg -- autoscaler -- spawn -- cluster M1 is already finished. I've almost done the Agent registration (M2) aspect. What it does now? AgentManagementService and AutoscalerService should be deployed in the back-end server. (say: IP is 192.168.1.2) AgentService should be deployed in machines (i.e. where new JVM instances will be spawned). (say: IP is 192.168.1.3) AgentService do a web service call (eg: curl -X GET http://localhost:8080/axis2/services/AgentService/agent) to AgentManagementService and get registered. Then AgentManagementService stores the URL (eg: http://192.168.1.3:8080/axis2/services/AgentService/) of that particular request. When autoscaler API (implementing this is M3) wanted to spawn a new instance (JVM or EC2 or anything else), it should call AutoscalerService (eg: curl --data instanceName=as -X POST http://192.168.1.2:8080/axis2/services/AutoscalerService/instance). Then AutoscalerService decides which kind of instance to spawn. If AutoscalerService decides to spawn a JVM instance, it creates a new JVMAdaptor instance. JVMAdaptor then calls (eg: curl -X GET http://192.168.1.2:8080/axis2/services/AgentManagementService/agent) AgentManagementService in order to pick an Agent. AgentManagementService picks an Agent in a round robin manner and sends back that Agent's EPR (http://192.168.1.3:8080/axis2/services/AgentService/) to JVMAdaptor. Then JVMAdaptor does a web service call to that particular AgentService and asked it to spawn the requested instance (instance is yet hard coded). Spawned instance then joins the cluster. Current observations: Currently starting instance aspect is done. I've tested this using 2 machines, and starting instance works fine. It is observed that the spawned JVM instances get killed when you issue 'ctrl+c' in the terminal where axis2 running. But when I killed axis2server.sh process only, the new JAVA process wasn't get killed. To avoid process get killing when issue ctrl+c, we might need to handle SIGINT [2]. Can't we be happy with the fact that it doesn't get killed after killing axis2server.sh? JVMs (which were created) should live even if you kill the agent. Yes, but the problem is how you kill! If you use kill -9 and kills Axis2 related process (Axis2 is where Agent Service is deployed), spawned JVM instances aren't get killed. Anyway will research a bit more, I understand that spawned instance should never get killed, unless it is asked to! Work to be done: Terminating and finding instance aspects should be addressed. You have to keep track of which JVMs/VMs created by the autoscaler. Otherwise you will not be able to stop them when you want to scale down. I believe, this information should be stored/kept with autoscaler service. I have started to implement this part today! According to the design 'Autoscaler Service' is only responsible for deciding the type of instance it should be spawned. That is a JVM instance or an EC2 instance or something else. Thus, it keeps track of the type of instance spawned. It is JVM Adaptor which keeps track of instances
Re: [Carbon-dev] Updating mvel2 orbit version to 2.0.19
is there any product other than CEP and BRS use this library?
thanks,
Amila.
On Mon, Feb 20, 2012 at 5:45 PM, Suhothayan Sriskandarajah s...@wso2.comwrote:
Drools and Siddhi have dependency on mvel2. Currently WSO2 platform uses
mvel 2.0.10 but
this version of mvel2 has some critical bugs where it couldn't process
expressions like
((7+(8*2)CSEStream.price) (CSEStream.symbol=='IBM')
and it is producing an error [1]
Hence this has been fixed in the latest stable version 2.0.19 released on
Nov 19 2010 [2].
I'm upgrading the mvel2 orbit to 2.0.19
Thanks
Suho
[1] [Error: was expecting type: java.lang.Boolean; but found type:
java.lang.Integer]
[Near : {... )price) (symbol=='IBM') }]
^
[Line: 1, Column: 40]
[2] http://mvel.codehaus.org/Downloading+MVEL
--
*S. Suhothayan
*
Software Engineer,
Data Technologies Team,
*WSO2, Inc. **http://wso2.com
http://wso2.com/*
*lean.enterprise.middleware.*
*email: **s...@wso2.com* s...@wso2.com* cell: (+94) 779 756 757
blog: **http://suhothayan.blogspot.com/* http://suhothayan.blogspot.com/
*
twitter: **http://twitter.com/suhothayan* http://twitter.com/suhothayan*
linked-in: **http://lk.linkedin.com/in/suhothayan*
*
*
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
--
*Amila Suriarachchi*
Software Architect
WSO2 Inc. ; http://wso2.com
lean . enterprise . middleware
phone : +94 71 3082805
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] [Update] JVM Autoscaler
On Mon, Feb 20, 2012 at 8:17 PM, Nirmal Fernando nir...@wso2.com wrote: Hi Shankar, On Mon, Feb 20, 2012 at 5:34 PM, Selvaratnam Uthaiyashankar shan...@wso2.com wrote: Hi Nirmal, Good progress!. we can do a review on the work already done. Thanks, will arrange a review this week. Did you try the agent in windows? No, I didn't! Is it using any native code? It needs to use native code in cases like spawning a new JVM (in Ubuntu we need /bin/sh to run the script 'wso2server.sh' in windows we need to run the batch file. But I believe this can be handled within the code it self by checking the OS name and execute appropriate commands! See some comments below. On Sat, Feb 18, 2012 at 11:10 PM, Nirmal Fernando nir...@wso2.com wrote: Hi All, I've started to implement 'new autoscaler architecture' [1] on February 8th. After having a discussion with Azeez, we came up with three milestones for the first iteration. --- M1: Make a WS call spawns a new JVM instance make the new instance joins the cluster with hard coded Agents. M2: Finish Agent registration related parts and spawn a new instance in a selected Agent. M3: Let current autoscaler component calls 'AutoscalerService' and spawns a new JVM instance in a selected Agent. Also applying WS security. --- I've attached set of images which depicts different stages of new architecture. Reading order of images is as follows: agent-reg -- autoscaler -- spawn -- cluster M1 is already finished. I've almost done the Agent registration (M2) aspect. What it does now? AgentManagementService and AutoscalerService should be deployed in the back-end server. (say: IP is 192.168.1.2) AgentService should be deployed in machines (i.e. where new JVM instances will be spawned). (say: IP is 192.168.1.3) AgentService do a web service call (eg: curl -X GET http://localhost:8080/axis2/services/AgentService/agent) to AgentManagementService and get registered. Then AgentManagementService stores the URL (eg: http://192.168.1.3:8080/axis2/services/AgentService/) of that particular request. When autoscaler API (implementing this is M3) wanted to spawn a new instance (JVM or EC2 or anything else), it should call AutoscalerService (eg: curl --data instanceName=as -X POST http://192.168.1.2:8080/axis2/services/AutoscalerService/instance). Then AutoscalerService decides which kind of instance to spawn. If AutoscalerService decides to spawn a JVM instance, it creates a new JVMAdaptor instance. JVMAdaptor then calls (eg: curl -X GET http://192.168.1.2:8080/axis2/services/AgentManagementService/agent) AgentManagementService in order to pick an Agent. AgentManagementService picks an Agent in a round robin manner and sends back that Agent's EPR (http://192.168.1.3:8080/axis2/services/AgentService/) to JVMAdaptor. Then JVMAdaptor does a web service call to that particular AgentService and asked it to spawn the requested instance (instance is yet hard coded). Spawned instance then joins the cluster. Current observations: Currently starting instance aspect is done. I've tested this using 2 machines, and starting instance works fine. It is observed that the spawned JVM instances get killed when you issue 'ctrl+c' in the terminal where axis2 running. But when I killed axis2server.sh process only, the new JAVA process wasn't get killed. To avoid process get killing when issue ctrl+c, we might need to handle SIGINT [2]. Can't we be happy with the fact that it doesn't get killed after killing axis2server.sh? JVMs (which were created) should live even if you kill the agent. Yes, but the problem is how you kill! If you use kill -9 and kills Axis2 related process (Axis2 is where Agent Service is deployed), spawned JVM instances aren't get killed. Anyway will research a bit more, I understand that spawned instance should never get killed, unless it is asked to! Work to be done: Terminating and finding instance aspects should be addressed. You have to keep track of which JVMs/VMs created by the autoscaler. Otherwise you will not be able to stop them when you want to scale down. I believe, this information should be stored/kept with autoscaler service. I have started to implement this part today! According to the design 'Autoscaler Service' is only responsible for deciding the type of instance it should be spawned. That is a JVM instance or an EC2 instance or something
Re: [Carbon-dev] Jaggery test pack
The docs are still not final it seems. I would rather wait till docs are complete to test this. What is the ETA for completing the docs? Also, the samples are using $j all over. Can we use the simplest format in samples and drop use of $j in there? On Mon, Feb 20, 2012 at 9:11 AM, Nuwan Bandara nu...@wso2.com wrote: Hi, Please find the snapshot pack at [1] [1] http://people.wso2.com/~nuwan/jaggery/jaggery-1.0.0-SNAPSHOT.zip Regards, /Nuwan On Mon, Feb 20, 2012 at 9:01 AM, Samisa Abeysinghe sam...@wso2.comwrote: On Mon, Feb 20, 2012 at 8:55 AM, Nuwan Bandara nu...@wso2.com wrote: Hi Samisa, Will give you a pack today. Thanks! Regards, /Nuwan On Mon, Feb 20, 2012 at 7:26 AM, Samisa Abeysinghe sam...@wso2.comwrote: Can someone please provide a latest pack that I can test? Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- *Thanks Regards, Nuwan Bandara Senior Software Engineer WSO2 Inc. | http://wso2.com lean . enterprise . middleware http://nuwan.bandara.co * http://www.nuwanbando.com/ ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- *Thanks Regards, Nuwan Bandara Senior Software Engineer WSO2 Inc. | http://wso2.com lean . enterprise . middleware http://nuwan.bandara.co * http://www.nuwanbando.com/ ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Jaggery test pack
On Tue, Feb 21, 2012 at 6:54 AM, Samisa Abeysinghe sam...@wso2.com wrote: The docs are still not final it seems. I would rather wait till docs are complete to test this. +1 What is the ETA for completing the docs? Also, the samples are using $j all over. Can we use the simplest format in samples and drop use of $j in there? On Mon, Feb 20, 2012 at 9:11 AM, Nuwan Bandara nu...@wso2.com wrote: Hi, Please find the snapshot pack at [1] [1] http://people.wso2.com/~nuwan/jaggery/jaggery-1.0.0-SNAPSHOT.zip Regards, /Nuwan On Mon, Feb 20, 2012 at 9:01 AM, Samisa Abeysinghe sam...@wso2.comwrote: On Mon, Feb 20, 2012 at 8:55 AM, Nuwan Bandara nu...@wso2.com wrote: Hi Samisa, Will give you a pack today. Thanks! Regards, /Nuwan On Mon, Feb 20, 2012 at 7:26 AM, Samisa Abeysinghe sam...@wso2.comwrote: Can someone please provide a latest pack that I can test? Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- *Thanks Regards, Nuwan Bandara Senior Software Engineer WSO2 Inc. | http://wso2.com lean . enterprise . middleware http://nuwan.bandara.co * http://www.nuwanbando.com/ ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- *Thanks Regards, Nuwan Bandara Senior Software Engineer WSO2 Inc. | http://wso2.com lean . enterprise . middleware http://nuwan.bandara.co * http://www.nuwanbando.com/ ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Yumani Ranaweera Associate Technical Lead - QA WSO2, Inc. - http://wso2.org Email : yum...@wso2.com Cell: +94 077 7795242 Blog : http://yumani.blogspot.com/ ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] [Update] JVM Autoscaler
Hi All, I need your views on following. In the Agent side we need to have a configuration file (say instances_config.xml) which specifies the paths and names of the instances belong to domains. I thought to have following structure: domain name=wso2.as.domain instance name=wso2as-4.1.0-SNAPSHOT path=/home/nirmal/Desktop/wso2as-4.1.0-SNAPSHOT/ instance name=wso2as-4.1.0-SNAPSHOT path=/home/nirmal/Temp/wso2as-4.1.0-SNAPSHOT/ . /domain domain name=wso2.bps.domain instance name=wso2bps-4.1.0-SNAPSHOT path=/home/nirmal/Desktop/wso2bps-4.1.0-SNAPSHOT/ instance name=wso2bps-4.1.0-SNAPSHOT path=/home/nirmal/Temp/wso2bps-4.1.0-SNAPSHOT/ . /domain . WDYT? PS: It is my understanding that the autoscaler component passes the 'domain name' to the Autoscaler Service, when it wants to scale. On Mon, Feb 20, 2012 at 9:31 PM, Selvaratnam Uthaiyashankar shan...@wso2.com wrote: On Mon, Feb 20, 2012 at 8:17 PM, Nirmal Fernando nir...@wso2.com wrote: Hi Shankar, On Mon, Feb 20, 2012 at 5:34 PM, Selvaratnam Uthaiyashankar shan...@wso2.com wrote: Hi Nirmal, Good progress!. we can do a review on the work already done. Thanks, will arrange a review this week. Did you try the agent in windows? No, I didn't! Is it using any native code? It needs to use native code in cases like spawning a new JVM (in Ubuntu we need /bin/sh to run the script 'wso2server.sh' in windows we need to run the batch file. But I believe this can be handled within the code it self by checking the OS name and execute appropriate commands! See some comments below. On Sat, Feb 18, 2012 at 11:10 PM, Nirmal Fernando nir...@wso2.com wrote: Hi All, I've started to implement 'new autoscaler architecture' [1] on February 8th. After having a discussion with Azeez, we came up with three milestones for the first iteration. --- M1: Make a WS call spawns a new JVM instance make the new instance joins the cluster with hard coded Agents. M2: Finish Agent registration related parts and spawn a new instance in a selected Agent. M3: Let current autoscaler component calls 'AutoscalerService' and spawns a new JVM instance in a selected Agent. Also applying WS security. --- I've attached set of images which depicts different stages of new architecture. Reading order of images is as follows: agent-reg -- autoscaler -- spawn -- cluster M1 is already finished. I've almost done the Agent registration (M2) aspect. What it does now? AgentManagementService and AutoscalerService should be deployed in the back-end server. (say: IP is 192.168.1.2) AgentService should be deployed in machines (i.e. where new JVM instances will be spawned). (say: IP is 192.168.1.3) AgentService do a web service call (eg: curl -X GET http://localhost:8080/axis2/services/AgentService/agent) to AgentManagementService and get registered. Then AgentManagementService stores the URL (eg: http://192.168.1.3:8080/axis2/services/AgentService/) of that particular request. When autoscaler API (implementing this is M3) wanted to spawn a new instance (JVM or EC2 or anything else), it should call AutoscalerService (eg: curl --data instanceName=as -X POST http://192.168.1.2:8080/axis2/services/AutoscalerService/instance). Then AutoscalerService decides which kind of instance to spawn. If AutoscalerService decides to spawn a JVM instance, it creates a new JVMAdaptor instance. JVMAdaptor then calls (eg: curl -X GET http://192.168.1.2:8080/axis2/services/AgentManagementService/agent) AgentManagementService in order to pick an Agent. AgentManagementService picks an Agent in a round robin manner and sends back that Agent's EPR (http://192.168.1.3:8080/axis2/services/AgentService/) to JVMAdaptor. Then JVMAdaptor does a web service call to that particular AgentService and asked it to spawn the requested instance (instance is yet hard coded). Spawned instance then joins the cluster. Current observations: Currently starting instance aspect is done. I've tested this using 2 machines, and starting instance works fine. It is observed that the spawned JVM instances get killed when you issue 'ctrl+c' in the terminal where axis2 running. But when I killed axis2server.sh process only, the new JAVA process wasn't get killed. To avoid process get killing when issue
[Carbon-dev] Removing Cassandra dependency in Carbon Kernel
Hi Devs, There is a Cassandra log4j appender in Carbon.Utils bundle[1]. Due to this logger, following dependencies has been added to the Carbon kernel. Cassandra Hectore-core libthrift. IMHO, these are unnecessary dependencies to Carbon kernel. We need to move this Cassandra appender to the components level. There are some other cases where we can get rid of unnecessary dependencies from Carbon kernel, These are initial steps towards minimizing Carbon kenel. Thanks, Sameera. [1] https://svn.wso2.org/repos/wso2/trunk/carbon/core/org.wso2.carbon.utils/pom.xml -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] [Update] JVM Autoscaler
On Tue, Feb 21, 2012 at 10:18 AM, Nirmal Fernando nir...@wso2.com wrote: Hi All, I need your views on following. In the Agent side we need to have a configuration file (say instances_config.xml) which specifies the paths and names of the instances belong to domains. I thought to have following structure: Value of the path attribute should change like this: domain name=wso2.as.domain instance name=wso2as-4.1.0-SNAPSHOT path=/home/nirmal/Desktop/wso2as-4.1.0-SNAPSHOT/bin/wso2server.sh/ instance name=wso2as-4.1.0-SNAPSHOT path=/home/nirmal/Temp/wso2as-4.1.0-SNAPSHOT/bin/wso2server.sh/ . /domain domain name=wso2.bps.domain instance name=wso2bps-4.1.0-SNAPSHOT path=/home/nirmal/Desktop/wso2bps-4.1.0-SNAPSHOT/bin/wso2server.sh/ instance name=wso2bps-4.1.0-SNAPSHOT path=/home/nirmal/Temp/wso2bps-4.1.0-SNAPSHOT/bin/wso2server.sh/ . /domain . WDYT? PS: It is my understanding that the autoscaler component passes the 'domain name' to the Autoscaler Service, when it wants to scale. On Mon, Feb 20, 2012 at 9:31 PM, Selvaratnam Uthaiyashankar shan...@wso2.com wrote: On Mon, Feb 20, 2012 at 8:17 PM, Nirmal Fernando nir...@wso2.com wrote: Hi Shankar, On Mon, Feb 20, 2012 at 5:34 PM, Selvaratnam Uthaiyashankar shan...@wso2.com wrote: Hi Nirmal, Good progress!. we can do a review on the work already done. Thanks, will arrange a review this week. Did you try the agent in windows? No, I didn't! Is it using any native code? It needs to use native code in cases like spawning a new JVM (in Ubuntu we need /bin/sh to run the script 'wso2server.sh' in windows we need to run the batch file. But I believe this can be handled within the code it self by checking the OS name and execute appropriate commands! See some comments below. On Sat, Feb 18, 2012 at 11:10 PM, Nirmal Fernando nir...@wso2.com wrote: Hi All, I've started to implement 'new autoscaler architecture' [1] on February 8th. After having a discussion with Azeez, we came up with three milestones for the first iteration. --- M1: Make a WS call spawns a new JVM instance make the new instance joins the cluster with hard coded Agents. M2: Finish Agent registration related parts and spawn a new instance in a selected Agent. M3: Let current autoscaler component calls 'AutoscalerService' and spawns a new JVM instance in a selected Agent. Also applying WS security. --- I've attached set of images which depicts different stages of new architecture. Reading order of images is as follows: agent-reg -- autoscaler -- spawn -- cluster M1 is already finished. I've almost done the Agent registration (M2) aspect. What it does now? AgentManagementService and AutoscalerService should be deployed in the back-end server. (say: IP is 192.168.1.2) AgentService should be deployed in machines (i.e. where new JVM instances will be spawned). (say: IP is 192.168.1.3) AgentService do a web service call (eg: curl -X GET http://localhost:8080/axis2/services/AgentService/agent) to AgentManagementService and get registered. Then AgentManagementService stores the URL (eg: http://192.168.1.3:8080/axis2/services/AgentService/) of that particular request. When autoscaler API (implementing this is M3) wanted to spawn a new instance (JVM or EC2 or anything else), it should call AutoscalerService (eg: curl --data instanceName=as -X POST http://192.168.1.2:8080/axis2/services/AutoscalerService/instance). Then AutoscalerService decides which kind of instance to spawn. If AutoscalerService decides to spawn a JVM instance, it creates a new JVMAdaptor instance. JVMAdaptor then calls (eg: curl -X GET http://192.168.1.2:8080/axis2/services/AgentManagementService/agent) AgentManagementService in order to pick an Agent. AgentManagementService picks an Agent in a round robin manner and sends back that Agent's EPR (http://192.168.1.3:8080/axis2/services/AgentService/) to JVMAdaptor. Then JVMAdaptor does a web service call to that particular AgentService and asked it to spawn the requested instance (instance is yet hard coded). Spawned instance then joins the cluster. Current observations: Currently starting instance aspect is done. I've tested this using 2 machines, and starting instance works fine. It is observed that the
[Carbon-dev] Agent component build failure
[INFO] Reactor Summary: [INFO] [INFO] WSO2 Carbon - Agent ... SUCCESS [0.472s] [INFO] WSO2 Carbon - Agent Thrift Commons SUCCESS [3.948s] [INFO] WSO2 Carbon - Agent Commons ... SUCCESS [0.534s] [INFO] WSO2 Carbon - Agent Client FAILURE [0.726s] [INFO] WSO2 Carbon - Agent Server SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 7.069s [INFO] Finished at: Tue Feb 21 10:59:36 IST 2012 [INFO] Final Memory: 22M/92M [INFO] [ERROR] Failed to execute goal on project org.wso2.carbon.agent: Could not resolve dependencies for project org.wso2.carbon:org.wso2.carbon.agent:bundle:4.0.0-SNAPSHOT: The following artifacts could not be resolved: org.wso2.carbon:org.wso2.carbon.agent.commons:jar:1.0.0-SNAPSHOT, org.wso2.carbon:org.wso2.carbon.agent.commons.thrift:jar:1.0.0-SNAPSHOT: Failure to find org.wso2.carbon:org.wso2.carbon.agent.commons:jar:1.0.0-SNAPSHOT in http://maven.wso2.org/nexus/content/groups/wso2-public/ was cached in the local repository, resolution will not be reattempted until the update interval of wso2-nexus has elapsed or updates are forced - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn goals -rf :org.wso2.carbon.agent [rajika@localhost agent]$ I think this component doesn't have good name. It doesn't reveal any domain name. Rajika ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
[Carbon-dev] (no subject)
On a side note, I think we have some classes inside Carbon core which are not really a part of Carbon core functionality, for example the cache entry implementations like IdentityCacheEntry. With Tomcat OSGification, I guess we can move these classes to corresponding components and allow them to evolve independent of the core. Thanks, Thilina On Tue, Feb 21, 2012 at 10:38 AM, Sameera Jayasoma same...@wso2.com wrote: Hi Devs, There is a Cassandra log4j appender in Carbon.Utils bundle[1]. Due to this logger, following dependencies has been added to the Carbon kernel. Cassandra Hectore-core libthrift. IMHO, these are unnecessary dependencies to Carbon kernel. We need to move this Cassandra appender to the components level. There are some other cases where we can get rid of unnecessary dependencies from Carbon kernel, These are initial steps towards minimizing Carbon kenel. Thanks, Sameera. [1] https://svn.wso2.org/repos/wso2/trunk/carbon/core/org.wso2.carbon.utils/pom.xml -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Thilina Buddhika Associate Technical Lead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] [Update] JVM Autoscaler
On Tue, Feb 21, 2012 at 11:04 AM, Nirmal Fernando nir...@wso2.com wrote: On Tue, Feb 21, 2012 at 10:18 AM, Nirmal Fernando nir...@wso2.com wrote: Hi All, I need your views on following. In the Agent side we need to have a configuration file (say instances_config.xml) which specifies the paths and names of the instances belong to domains. I thought to have following structure: Value of the path attribute should change like this: Whoops! Forgot to add the root element! :S instanceConfig domain name=wso2.as.domain instance name=wso2as-4.1.0-SNAPSHOT path=/home/nirmal/Desktop/wso2as-4.1.0-SNAPSHOT/bin/wso2server.sh/ instance name=wso2as-4.1.0-SNAPSHOT path=/home/nirmal/Temp/wso2as-4.1.0-SNAPSHOT/bin/wso2server.sh/ . /domain domain name=wso2.bps.domain instance name=wso2bps-4.1.0-SNAPSHOT path=/home/nirmal/Desktop/wso2bps-4.1.0-SNAPSHOT/bin/wso2server.sh/ instance name=wso2bps-4.1.0-SNAPSHOT path=/home/nirmal/Temp/wso2bps-4.1.0-SNAPSHOT/bin/wso2server.sh/ . /domain . /instanceConfig WDYT? PS: It is my understanding that the autoscaler component passes the 'domain name' to the Autoscaler Service, when it wants to scale. On Mon, Feb 20, 2012 at 9:31 PM, Selvaratnam Uthaiyashankar shan...@wso2.com wrote: On Mon, Feb 20, 2012 at 8:17 PM, Nirmal Fernando nir...@wso2.com wrote: Hi Shankar, On Mon, Feb 20, 2012 at 5:34 PM, Selvaratnam Uthaiyashankar shan...@wso2.com wrote: Hi Nirmal, Good progress!. we can do a review on the work already done. Thanks, will arrange a review this week. Did you try the agent in windows? No, I didn't! Is it using any native code? It needs to use native code in cases like spawning a new JVM (in Ubuntu we need /bin/sh to run the script 'wso2server.sh' in windows we need to run the batch file. But I believe this can be handled within the code it self by checking the OS name and execute appropriate commands! See some comments below. On Sat, Feb 18, 2012 at 11:10 PM, Nirmal Fernando nir...@wso2.com wrote: Hi All, I've started to implement 'new autoscaler architecture' [1] on February 8th. After having a discussion with Azeez, we came up with three milestones for the first iteration. --- M1: Make a WS call spawns a new JVM instance make the new instance joins the cluster with hard coded Agents. M2: Finish Agent registration related parts and spawn a new instance in a selected Agent. M3: Let current autoscaler component calls 'AutoscalerService' and spawns a new JVM instance in a selected Agent. Also applying WS security. --- I've attached set of images which depicts different stages of new architecture. Reading order of images is as follows: agent-reg -- autoscaler -- spawn -- cluster M1 is already finished. I've almost done the Agent registration (M2) aspect. What it does now? AgentManagementService and AutoscalerService should be deployed in the back-end server. (say: IP is 192.168.1.2) AgentService should be deployed in machines (i.e. where new JVM instances will be spawned). (say: IP is 192.168.1.3) AgentService do a web service call (eg: curl -X GET http://localhost:8080/axis2/services/AgentService/agent) to AgentManagementService and get registered. Then AgentManagementService stores the URL (eg: http://192.168.1.3:8080/axis2/services/AgentService/) of that particular request. When autoscaler API (implementing this is M3) wanted to spawn a new instance (JVM or EC2 or anything else), it should call AutoscalerService (eg: curl --data instanceName=as -X POST http://192.168.1.2:8080/axis2/services/AutoscalerService/instance). Then AutoscalerService decides which kind of instance to spawn. If AutoscalerService decides to spawn a JVM instance, it creates a new JVMAdaptor instance. JVMAdaptor then calls (eg: curl -X GET http://192.168.1.2:8080/axis2/services/AgentManagementService/agent ) AgentManagementService in order to pick an Agent. AgentManagementService picks an Agent in a round robin manner and sends back that Agent's EPR (http://192.168.1.3:8080/axis2/services/AgentService/) to JVMAdaptor. Then JVMAdaptor does a web service call to that particular AgentService and asked it to spawn the requested instance (instance is yet hard coded). Spawned instance then joins the cluster. Current
[Carbon-dev] Cleaning up Carbon-Core
[Sorry, the subject was accidentally removed when sending out the email.] On a side note, I think we have some classes inside Carbon core which are not really a part of Carbon core functionality, for example the cache entry implementations like IdentityCacheEntry. With Tomcat OSGification, I guess we can move these classes to corresponding components and allow them to evolve independent of the core. Thanks, Thilina On Tue, Feb 21, 2012 at 10:38 AM, Sameera Jayasoma same...@wso2.com wrote: Hi Devs, There is a Cassandra log4j appender in Carbon.Utils bundle[1]. Due to this logger, following dependencies has been added to the Carbon kernel. Cassandra Hectore-core libthrift. IMHO, these are unnecessary dependencies to Carbon kernel. We need to move this Cassandra appender to the components level. There are some other cases where we can get rid of unnecessary dependencies from Carbon kernel, These are initial steps towards minimizing Carbon kenel. Thanks, Sameera. [1] https://svn.wso2.org/repos/wso2/trunk/carbon/core/org.wso2.carbon.utils/pom.xml -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Thilina Buddhika Associate Technical Lead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com -- Thilina Buddhika Associate Technical Lead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Cleaning up Carbon-Core
On Tue, Feb 21, 2012 at 11:16 AM, Thilina Buddhika thili...@wso2.comwrote: [Sorry, the subject was accidentally removed when sending out the email.] On a side note, I think we have some classes inside Carbon core which are not really a part of Carbon core functionality, for example the cache entry implementations like IdentityCacheEntry. With Tomcat OSGification, I guess we can move these classes to corresponding components and allow them to evolve independent of the core. +1. Deep/Amani, Can we remove this appender from the Carbon kernel? Btw, who will work on removing cache entry functionality from kernel. Thanks, Sameera. Thanks, Thilina On Tue, Feb 21, 2012 at 10:38 AM, Sameera Jayasoma same...@wso2.comwrote: Hi Devs, There is a Cassandra log4j appender in Carbon.Utils bundle[1]. Due to this logger, following dependencies has been added to the Carbon kernel. Cassandra Hectore-core libthrift. IMHO, these are unnecessary dependencies to Carbon kernel. We need to move this Cassandra appender to the components level. There are some other cases where we can get rid of unnecessary dependencies from Carbon kernel, These are initial steps towards minimizing Carbon kenel. Thanks, Sameera. [1] https://svn.wso2.org/repos/wso2/trunk/carbon/core/org.wso2.carbon.utils/pom.xml -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Thilina Buddhika Associate Technical Lead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com -- Thilina Buddhika Associate Technical Lead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Agent component build failure
Thanks for reporting Its now fixed at r121086 Regards Suho On Tue, Feb 21, 2012 at 11:05 AM, Rajika Kumarasiri raj...@wso2.com wrote: [INFO] Reactor Summary: [INFO] [INFO] WSO2 Carbon - Agent ... SUCCESS [0.472s] [INFO] WSO2 Carbon - Agent Thrift Commons SUCCESS [3.948s] [INFO] WSO2 Carbon - Agent Commons ... SUCCESS [0.534s] [INFO] WSO2 Carbon - Agent Client FAILURE [0.726s] [INFO] WSO2 Carbon - Agent Server SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 7.069s [INFO] Finished at: Tue Feb 21 10:59:36 IST 2012 [INFO] Final Memory: 22M/92M [INFO] [ERROR] Failed to execute goal on project org.wso2.carbon.agent: Could not resolve dependencies for project org.wso2.carbon:org.wso2.carbon.agent:bundle:4.0.0-SNAPSHOT: The following artifacts could not be resolved: org.wso2.carbon:org.wso2.carbon.agent.commons:jar:1.0.0-SNAPSHOT, org.wso2.carbon:org.wso2.carbon.agent.commons.thrift:jar:1.0.0-SNAPSHOT: Failure to find org.wso2.carbon:org.wso2.carbon.agent.commons:jar:1.0.0-SNAPSHOT in http://maven.wso2.org/nexus/content/groups/wso2-public/ was cached in the local repository, resolution will not be reattempted until the update interval of wso2-nexus has elapsed or updates are forced - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn goals -rf :org.wso2.carbon.agent [rajika@localhost agent]$ I think this component doesn't have good name. It doesn't reveal any domain name. Rajika ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- *S. Suhothayan * Software Engineer, Data Technologies Team, *WSO2, Inc. **http://wso2.com http://wso2.com/* *lean.enterprise.middleware.* *email: **s...@wso2.com* s...@wso2.com* cell: (+94) 779 756 757 blog: **http://suhothayan.blogspot.com/* http://suhothayan.blogspot.com/* twitter: **http://twitter.com/suhothayan* http://twitter.com/suhothayan* linked-in: **http://lk.linkedin.com/in/suhothayan* * * ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Agent component build failure
Hi, On Tue, Feb 21, 2012 at 11:05 AM, Rajika Kumarasiri raj...@wso2.com wrote: [INFO] Reactor Summary: [INFO] [INFO] WSO2 Carbon - Agent ... SUCCESS [0.472s] [INFO] WSO2 Carbon - Agent Thrift Commons SUCCESS [3.948s] [INFO] WSO2 Carbon - Agent Commons ... SUCCESS [0.534s] [INFO] WSO2 Carbon - Agent Client FAILURE [0.726s] [INFO] WSO2 Carbon - Agent Server SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 7.069s [INFO] Finished at: Tue Feb 21 10:59:36 IST 2012 [INFO] Final Memory: 22M/92M [INFO] [ERROR] Failed to execute goal on project org.wso2.carbon.agent: Could not resolve dependencies for project org.wso2.carbon:org.wso2.carbon.agent:bundle:4.0.0-SNAPSHOT: The following artifacts could not be resolved: org.wso2.carbon:org.wso2.carbon.agent.commons:jar:1.0.0-SNAPSHOT, org.wso2.carbon:org.wso2.carbon.agent.commons.thrift:jar:1.0.0-SNAPSHOT: Failure to find org.wso2.carbon:org.wso2.carbon.agent.commons:jar:1.0.0-SNAPSHOT in http://maven.wso2.org/nexus/content/groups/wso2-public/ was cached in the local repository, resolution will not be reattempted until the update interval of wso2-nexus has elapsed or updates are forced - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn goals -rf :org.wso2.carbon.agent [rajika@localhost agent]$ I also encountered the same build failure . I think this component doesn't have good name. It doesn't reveal any domain name. Rajika ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Subash Chaturanga Software Engineer WSO2 Inc. http://wso2.com email - sub...@wso2.com phone - 077 2225922 ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Cleaning up Carbon-Core
On Tue, Feb 21, 2012 at 11:24 AM, Sameera Jayasoma same...@wso2.com wrote: On Tue, Feb 21, 2012 at 11:16 AM, Thilina Buddhika thili...@wso2.comwrote: [Sorry, the subject was accidentally removed when sending out the email.] On a side note, I think we have some classes inside Carbon core which are not really a part of Carbon core functionality, for example the cache entry implementations like IdentityCacheEntry. With Tomcat OSGification, I guess we can move these classes to corresponding components and allow them to evolve independent of the core. +1. Deep/Amani, Can we remove this appender from the Carbon kernel? Btw, who will work on removing cache entry functionality from kernel. Will do, but where should we keep CassandraAppender?. Since its extending log4jAppender and isn't carbon kernel the best place to put it? Thanks, Sameera. Thanks, Thilina On Tue, Feb 21, 2012 at 10:38 AM, Sameera Jayasoma same...@wso2.comwrote: Hi Devs, There is a Cassandra log4j appender in Carbon.Utils bundle[1]. Due to this logger, following dependencies has been added to the Carbon kernel. Cassandra Hectore-core libthrift. IMHO, these are unnecessary dependencies to Carbon kernel. We need to move this Cassandra appender to the components level. There are some other cases where we can get rid of unnecessary dependencies from Carbon kernel, These are initial steps towards minimizing Carbon kenel. Thanks, Sameera. [1] https://svn.wso2.org/repos/wso2/trunk/carbon/core/org.wso2.carbon.utils/pom.xml -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Thilina Buddhika Associate Technical Lead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com -- Thilina Buddhika Associate Technical Lead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Cleaning up Carbon-Core
On Tue, Feb 21, 2012 at 11:32 AM, Amani Soysa am...@wso2.com wrote: On Tue, Feb 21, 2012 at 11:24 AM, Sameera Jayasoma same...@wso2.comwrote: On Tue, Feb 21, 2012 at 11:16 AM, Thilina Buddhika thili...@wso2.comwrote: [Sorry, the subject was accidentally removed when sending out the email.] On a side note, I think we have some classes inside Carbon core which are not really a part of Carbon core functionality, for example the cache entry implementations like IdentityCacheEntry. With Tomcat OSGification, I guess we can move these classes to corresponding components and allow them to evolve independent of the core. +1. Deep/Amani, Can we remove this appender from the Carbon kernel? Btw, who will work on removing cache entry functionality from kernel. Will do, but where should we keep CassandraAppender?. Since its extending log4jAppender and isn't carbon kernel the best place to put it? Log4jAppender is an interface which allows to people to extends log4j functionality. And this appender is one such implementation which push logs to the Cassandra database. This appender has nothing to do with Carbon kenel, IMHO. Can you please explain why you think, it should be in Carbon kernel? Thanks, Sameera. Thanks, Sameera. Thanks, Thilina On Tue, Feb 21, 2012 at 10:38 AM, Sameera Jayasoma same...@wso2.comwrote: Hi Devs, There is a Cassandra log4j appender in Carbon.Utils bundle[1]. Due to this logger, following dependencies has been added to the Carbon kernel. Cassandra Hectore-core libthrift. IMHO, these are unnecessary dependencies to Carbon kernel. We need to move this Cassandra appender to the components level. There are some other cases where we can get rid of unnecessary dependencies from Carbon kernel, These are initial steps towards minimizing Carbon kenel. Thanks, Sameera. [1] https://svn.wso2.org/repos/wso2/trunk/carbon/core/org.wso2.carbon.utils/pom.xml -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Thilina Buddhika Associate Technical Lead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com -- Thilina Buddhika Associate Technical Lead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Cleaning up Carbon-Core
On Tue, Feb 21, 2012 at 11:47 AM, Sameera Jayasoma same...@wso2.com wrote: On Tue, Feb 21, 2012 at 11:32 AM, Amani Soysa am...@wso2.com wrote: On Tue, Feb 21, 2012 at 11:24 AM, Sameera Jayasoma same...@wso2.comwrote: On Tue, Feb 21, 2012 at 11:16 AM, Thilina Buddhika thili...@wso2.comwrote: [Sorry, the subject was accidentally removed when sending out the email.] On a side note, I think we have some classes inside Carbon core which are not really a part of Carbon core functionality, for example the cache entry implementations like IdentityCacheEntry. With Tomcat OSGification, I guess we can move these classes to corresponding components and allow them to evolve independent of the core. +1. Deep/Amani, Can we remove this appender from the Carbon kernel? Btw, who will work on removing cache entry functionality from kernel. Will do, but where should we keep CassandraAppender?. Move it to a component named carbon-logging or any other suitable name. I don't think this belongs to the kernel. Since its extending log4jAppender and isn't carbon kernel the best place to put it? Log4jAppender is an interface which allows to people to extends log4j functionality. And this appender is one such implementation which push logs to the Cassandra database. This appender has nothing to do with Carbon kenel, IMHO. Can you please explain why you think, it should be in Carbon kernel? Thanks, Sameera. Thanks, Sameera. Thanks, Thilina On Tue, Feb 21, 2012 at 10:38 AM, Sameera Jayasoma same...@wso2.comwrote: Hi Devs, There is a Cassandra log4j appender in Carbon.Utils bundle[1]. Due to this logger, following dependencies has been added to the Carbon kernel. Cassandra Hectore-core libthrift. IMHO, these are unnecessary dependencies to Carbon kernel. We need to move this Cassandra appender to the components level. There are some other cases where we can get rid of unnecessary dependencies from Carbon kernel, These are initial steps towards minimizing Carbon kenel. Thanks, Sameera. [1] https://svn.wso2.org/repos/wso2/trunk/carbon/core/org.wso2.carbon.utils/pom.xml -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Thilina Buddhika Associate Technical Lead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com -- Thilina Buddhika Associate Technical Lead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu blog: http://mackiemathew.com/ M: +9459908 ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Cleaning up Carbon-Core
On Tue, Feb 21, 2012 at 11:51 AM, Tharindu Mathew thari...@wso2.com wrote: On Tue, Feb 21, 2012 at 11:47 AM, Sameera Jayasoma same...@wso2.comwrote: On Tue, Feb 21, 2012 at 11:32 AM, Amani Soysa am...@wso2.com wrote: On Tue, Feb 21, 2012 at 11:24 AM, Sameera Jayasoma same...@wso2.comwrote: On Tue, Feb 21, 2012 at 11:16 AM, Thilina Buddhika thili...@wso2.comwrote: [Sorry, the subject was accidentally removed when sending out the email.] On a side note, I think we have some classes inside Carbon core which are not really a part of Carbon core functionality, for example the cache entry implementations like IdentityCacheEntry. With Tomcat OSGification, I guess we can move these classes to corresponding components and allow them to evolve independent of the core. +1. Deep/Amani, Can we remove this appender from the Carbon kernel? Btw, who will work on removing cache entry functionality from kernel. Will do, but where should we keep CassandraAppender?. Move it to a component named carbon-logging or any other suitable name. I don't think this belongs to the kernel. Ah ok I will remove it from the kernel. Since its extending log4jAppender and isn't carbon kernel the best place to put it? Log4jAppender is an interface which allows to people to extends log4j functionality. And this appender is one such implementation which push logs to the Cassandra database. This appender has nothing to do with Carbon kenel, IMHO. Can you please explain why you think, it should be in Carbon kernel? Thanks, Sameera. Thanks, Sameera. Thanks, Thilina On Tue, Feb 21, 2012 at 10:38 AM, Sameera Jayasoma same...@wso2.comwrote: Hi Devs, There is a Cassandra log4j appender in Carbon.Utils bundle[1]. Due to this logger, following dependencies has been added to the Carbon kernel. Cassandra Hectore-core libthrift. IMHO, these are unnecessary dependencies to Carbon kernel. We need to move this Cassandra appender to the components level. There are some other cases where we can get rid of unnecessary dependencies from Carbon kernel, These are initial steps towards minimizing Carbon kenel. Thanks, Sameera. [1] https://svn.wso2.org/repos/wso2/trunk/carbon/core/org.wso2.carbon.utils/pom.xml -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Thilina Buddhika Associate Technical Lead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com -- Thilina Buddhika Associate Technical Lead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu blog: http://mackiemathew.com/ M: +9459908 ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Cleaning up Carbon-Core
Hi Sameera, We are picking on logging here but there are many more. Do you have a list of bundles we want to remove to make Carbon a proper minimum kernel? On Tue, Feb 21, 2012 at 11:52 AM, Amani Soysa am...@wso2.com wrote: On Tue, Feb 21, 2012 at 11:51 AM, Tharindu Mathew thari...@wso2.comwrote: On Tue, Feb 21, 2012 at 11:47 AM, Sameera Jayasoma same...@wso2.comwrote: On Tue, Feb 21, 2012 at 11:32 AM, Amani Soysa am...@wso2.com wrote: On Tue, Feb 21, 2012 at 11:24 AM, Sameera Jayasoma same...@wso2.comwrote: On Tue, Feb 21, 2012 at 11:16 AM, Thilina Buddhika thili...@wso2.comwrote: [Sorry, the subject was accidentally removed when sending out the email.] On a side note, I think we have some classes inside Carbon core which are not really a part of Carbon core functionality, for example the cache entry implementations like IdentityCacheEntry. With Tomcat OSGification, I guess we can move these classes to corresponding components and allow them to evolve independent of the core. +1. Deep/Amani, Can we remove this appender from the Carbon kernel? Btw, who will work on removing cache entry functionality from kernel. Will do, but where should we keep CassandraAppender?. Move it to a component named carbon-logging or any other suitable name. I don't think this belongs to the kernel. Ah ok I will remove it from the kernel. Since its extending log4jAppender and isn't carbon kernel the best place to put it? Log4jAppender is an interface which allows to people to extends log4j functionality. And this appender is one such implementation which push logs to the Cassandra database. This appender has nothing to do with Carbon kenel, IMHO. Can you please explain why you think, it should be in Carbon kernel? Thanks, Sameera. Thanks, Sameera. Thanks, Thilina On Tue, Feb 21, 2012 at 10:38 AM, Sameera Jayasoma same...@wso2.comwrote: Hi Devs, There is a Cassandra log4j appender in Carbon.Utils bundle[1]. Due to this logger, following dependencies has been added to the Carbon kernel. Cassandra Hectore-core libthrift. IMHO, these are unnecessary dependencies to Carbon kernel. We need to move this Cassandra appender to the components level. There are some other cases where we can get rid of unnecessary dependencies from Carbon kernel, These are initial steps towards minimizing Carbon kenel. Thanks, Sameera. [1] https://svn.wso2.org/repos/wso2/trunk/carbon/core/org.wso2.carbon.utils/pom.xml -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Thilina Buddhika Associate Technical Lead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com -- Thilina Buddhika Associate Technical Lead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu blog: http://mackiemathew.com/ M: +9459908 -- Regards, Tharindu blog: http://mackiemathew.com/ M: +9459908 ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing Cassandra dependency in Carbon Kernel
On Tue, Feb 21, 2012 at 10:38 AM, Sameera Jayasoma same...@wso2.com wrote: Hi Devs, There is a Cassandra log4j appender in Carbon.Utils bundle[1]. Due to this logger, following dependencies has been added to the Carbon kernel. Cassandra Hectore-core libthrift. IMHO, these are unnecessary dependencies to Carbon kernel. We need to move this Cassandra appender to the components level. +1 I think *Atomikos is another example. I have raised this at the time we are introducing this feature (See mail thread *Adding a Transaction Manager to Carbon @architecure*). * * * *But then again that *discussion* was *concluded* saying we are going to use it in carbon core. Are we using it now ? Or is there any plans to use this in near future ? If not we should remove that since this even violated the carbon concept in since Transactions is not a core and *required* feature most of the time in our problem domain. * * * *thanks,* *Charith * There are some other cases where we can get rid of unnecessary dependencies from Carbon kernel, These are initial steps towards minimizing Carbon kenel. Thanks, Sameera. [1] https://svn.wso2.org/repos/wso2/trunk/carbon/core/org.wso2.carbon.utils/pom.xml -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Charith Dhanushka Wickramarachchi Software Engineer WSO2 Inc http://wso2.com/ http://wso2.org/ blog http://charithwiki.blogspot.com/ twitter http://twitter.com/charithwiki Mobile : 0776706568 ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Cleaning up Carbon-Core
Hi Tharindu, On Tue, Feb 21, 2012 at 11:55 AM, Tharindu Mathew thari...@wso2.com wrote: Hi Sameera, We are picking on logging here We are not picking any particular component, team or developer. Yesterday we came across this while fixing a build failure. Hence thought of removing this dependency. If anyone thinks that we are picking on stuff, then please advice us on the correct ways to handle such cases. but there are many more. Yes. There are many more. And we can't solve EVERYTHING at once. It should be a step by step process. Identifying small improvements one by one and fixing them. Do you have a list of bundles we want to remove to make Carbon a proper minimum kernel? Nope. I am afraid we don't have. In fact we don't have to completely minimize Kernel for 4.0.0 release. Proper minimization will happen for 5.0.0 release as per the release plans. Therefore for Carbon 4.0.0, the plan is to fix these small cases and make it ready for a proper minimization. We would appreciate the cooperation from all the developer on this effort. Thanks, Sameera. On Tue, Feb 21, 2012 at 11:52 AM, Amani Soysa am...@wso2.com wrote: On Tue, Feb 21, 2012 at 11:51 AM, Tharindu Mathew thari...@wso2.comwrote: On Tue, Feb 21, 2012 at 11:47 AM, Sameera Jayasoma same...@wso2.comwrote: On Tue, Feb 21, 2012 at 11:32 AM, Amani Soysa am...@wso2.com wrote: On Tue, Feb 21, 2012 at 11:24 AM, Sameera Jayasoma same...@wso2.comwrote: On Tue, Feb 21, 2012 at 11:16 AM, Thilina Buddhika thili...@wso2.com wrote: [Sorry, the subject was accidentally removed when sending out the email.] On a side note, I think we have some classes inside Carbon core which are not really a part of Carbon core functionality, for example the cache entry implementations like IdentityCacheEntry. With Tomcat OSGification, I guess we can move these classes to corresponding components and allow them to evolve independent of the core. +1. Deep/Amani, Can we remove this appender from the Carbon kernel? Btw, who will work on removing cache entry functionality from kernel. Will do, but where should we keep CassandraAppender?. Move it to a component named carbon-logging or any other suitable name. I don't think this belongs to the kernel. Ah ok I will remove it from the kernel. Since its extending log4jAppender and isn't carbon kernel the best place to put it? Log4jAppender is an interface which allows to people to extends log4j functionality. And this appender is one such implementation which push logs to the Cassandra database. This appender has nothing to do with Carbon kenel, IMHO. Can you please explain why you think, it should be in Carbon kernel? Thanks, Sameera. Thanks, Sameera. Thanks, Thilina On Tue, Feb 21, 2012 at 10:38 AM, Sameera Jayasoma same...@wso2.com wrote: Hi Devs, There is a Cassandra log4j appender in Carbon.Utils bundle[1]. Due to this logger, following dependencies has been added to the Carbon kernel. Cassandra Hectore-core libthrift. IMHO, these are unnecessary dependencies to Carbon kernel. We need to move this Cassandra appender to the components level. There are some other cases where we can get rid of unnecessary dependencies from Carbon kernel, These are initial steps towards minimizing Carbon kenel. Thanks, Sameera. [1] https://svn.wso2.org/repos/wso2/trunk/carbon/core/org.wso2.carbon.utils/pom.xml -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Thilina Buddhika Associate Technical Lead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com -- Thilina Buddhika Associate Technical Lead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu blog: http://mackiemathew.com/ M: +9459908 -- Regards, Tharindu blog:
Re: [Carbon-dev] Removing Cassandra dependency in Carbon Kernel
On Tue, Feb 21, 2012 at 12:09 PM, Charith Wickramarachchi char...@wso2.comwrote: On Tue, Feb 21, 2012 at 10:38 AM, Sameera Jayasoma same...@wso2.comwrote: Hi Devs, There is a Cassandra log4j appender in Carbon.Utils bundle[1]. Due to this logger, following dependencies has been added to the Carbon kernel. Cassandra Hectore-core libthrift. IMHO, these are unnecessary dependencies to Carbon kernel. We need to move this Cassandra appender to the components level. +1 I think *Atomikos is another example. I have raised this at the time we are introducing this feature (See mail thread *Adding a Transaction Manager to Carbon @architecure*). * * * *But then again that *discussion* was *concluded* saying we are going to use it in carbon core. Are we using it now ? Or is there any plans to use this in near future ? If not we should remove that since this even violated the carbon concept in since Transactions is not a core and *required* feature most of the time in our problem domain. * +1. I guess Dinush/Pradeep is working on that at the moment. Sameera. * * *thanks,* *Charith * There are some other cases where we can get rid of unnecessary dependencies from Carbon kernel, These are initial steps towards minimizing Carbon kenel. Thanks, Sameera. [1] https://svn.wso2.org/repos/wso2/trunk/carbon/core/org.wso2.carbon.utils/pom.xml -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Charith Dhanushka Wickramarachchi Software Engineer WSO2 Inc http://wso2.com/ http://wso2.org/ blog http://charithwiki.blogspot.com/ twitter http://twitter.com/charithwiki Mobile : 0776706568 ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing Cassandra dependency in Carbon Kernel
At that time, we had to bring in a lot of stuff into Carbon core since they could not be made into true components due to the partial webapp, partial OSGi architecture. Now with a clean OSGi based architecture, we can move most of these things into separate bundles. On Tue, Feb 21, 2012 at 12:09 PM, Charith Wickramarachchi char...@wso2.comwrote: On Tue, Feb 21, 2012 at 10:38 AM, Sameera Jayasoma same...@wso2.comwrote: Hi Devs, There is a Cassandra log4j appender in Carbon.Utils bundle[1]. Due to this logger, following dependencies has been added to the Carbon kernel. Cassandra Hectore-core libthrift. IMHO, these are unnecessary dependencies to Carbon kernel. We need to move this Cassandra appender to the components level. +1 I think *Atomikos is another example. I have raised this at the time we are introducing this feature (See mail thread *Adding a Transaction Manager to Carbon @architecure*). * * * *But then again that *discussion* was *concluded* saying we are going to use it in carbon core. Are we using it now ? Or is there any plans to use this in near future ? If not we should remove that since this even violated the carbon concept in since Transactions is not a core and *required* feature most of the time in our problem domain. * * * *thanks,* *Charith * There are some other cases where we can get rid of unnecessary dependencies from Carbon kernel, These are initial steps towards minimizing Carbon kenel. Thanks, Sameera. [1] https://svn.wso2.org/repos/wso2/trunk/carbon/core/org.wso2.carbon.utils/pom.xml -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Charith Dhanushka Wickramarachchi Software Engineer WSO2 Inc http://wso2.com/ http://wso2.org/ blog http://charithwiki.blogspot.com/ twitter http://twitter.com/charithwiki Mobile : 0776706568 ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/** email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919 blog: **http://blog.afkham.org* http://blog.afkham.org* twitter: **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez * linked-in: **http://lk.linkedin.com/in/afkhamazeez* * * *Lean . Enterprise . Middleware* ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
[Carbon-dev] Make system statistics component cluster aware
When you get directed to different nodes in the cluster, you will see different values for system statistics. For example, the service request/response counts may be different. To overcome this, we need to send a cluster message to all members in the relevant cluster, gather the stats from those members, and then display them. Who is going to work on this? It is not very difficult to implement. -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/** email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919 blog: **http://blog.afkham.org* http://blog.afkham.org* twitter: **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez * linked-in: **http://lk.linkedin.com/in/afkhamazeez* * * *Lean . Enterprise . Middleware* ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Cleaning up Carbon-Core
Hi Sameera, I wonder whether my reply was not communicated properly. If that's the case, I will work on improving that aspect :). Please take it in good spirit. On Tue, Feb 21, 2012 at 12:21 PM, Sameera Jayasoma same...@wso2.com wrote: Hi Tharindu, On Tue, Feb 21, 2012 at 11:55 AM, Tharindu Mathew thari...@wso2.comwrote: Hi Sameera, We are picking on logging here We are not picking any particular component, team or developer. Yesterday we came across this while fixing a build failure. Hence thought of removing this dependency. If anyone thinks that we are picking on stuff, then please advice us on the correct ways to handle such cases. It's ok to pick on logging, if they have done a wrong thing. It is totally acceptable, as it's constructive. No developer or team would/should take it personally. but there are many more. Yes. There are many more. And we can't solve EVERYTHING at once. It should be a step by step process. Identifying small improvements one by one and fixing them. You broke down my single sentence :). I never said about solving EVERYTHING at once. Of course, being incremental or doing it all at once (maybe in a hackathon mode) is just a choice in execution. Do you have a list of bundles we want to remove to make Carbon a proper minimum kernel? Nope. I am afraid we don't have. In fact we don't have to completely minimize Kernel for 4.0.0 release. Proper minimization will happen for 5.0.0 release as per the release plans. Therefore for Carbon 4.0.0, the plan is to fix these small cases and make it ready for a proper minimization. We would appreciate the cooperation from all the developer on this effort. I wasn't aware of this. I thought it was a Carbon 4.0.0 effort. Sorry, if I missed a mail on this. I was interested in using a minimum kernel asap, but this is not urgent so 5.0.0 is good enough. IMO, the more systematic way would be to check and list what should be removed. Then, there's a lesser chance of us missing any part of the current kernel that should be removed. Thanks, Sameera. On Tue, Feb 21, 2012 at 11:52 AM, Amani Soysa am...@wso2.com wrote: On Tue, Feb 21, 2012 at 11:51 AM, Tharindu Mathew thari...@wso2.comwrote: On Tue, Feb 21, 2012 at 11:47 AM, Sameera Jayasoma same...@wso2.comwrote: On Tue, Feb 21, 2012 at 11:32 AM, Amani Soysa am...@wso2.com wrote: On Tue, Feb 21, 2012 at 11:24 AM, Sameera Jayasoma same...@wso2.comwrote: On Tue, Feb 21, 2012 at 11:16 AM, Thilina Buddhika thili...@wso2.com wrote: [Sorry, the subject was accidentally removed when sending out the email.] On a side note, I think we have some classes inside Carbon core which are not really a part of Carbon core functionality, for example the cache entry implementations like IdentityCacheEntry. With Tomcat OSGification, I guess we can move these classes to corresponding components and allow them to evolve independent of the core. +1. Deep/Amani, Can we remove this appender from the Carbon kernel? Btw, who will work on removing cache entry functionality from kernel. Will do, but where should we keep CassandraAppender?. Move it to a component named carbon-logging or any other suitable name. I don't think this belongs to the kernel. Ah ok I will remove it from the kernel. Since its extending log4jAppender and isn't carbon kernel the best place to put it? Log4jAppender is an interface which allows to people to extends log4j functionality. And this appender is one such implementation which push logs to the Cassandra database. This appender has nothing to do with Carbon kenel, IMHO. Can you please explain why you think, it should be in Carbon kernel? Thanks, Sameera. Thanks, Sameera. Thanks, Thilina On Tue, Feb 21, 2012 at 10:38 AM, Sameera Jayasoma same...@wso2.com wrote: Hi Devs, There is a Cassandra log4j appender in Carbon.Utils bundle[1]. Due to this logger, following dependencies has been added to the Carbon kernel. Cassandra Hectore-core libthrift. IMHO, these are unnecessary dependencies to Carbon kernel. We need to move this Cassandra appender to the components level. There are some other cases where we can get rid of unnecessary dependencies from Carbon kernel, These are initial steps towards minimizing Carbon kenel. Thanks, Sameera. [1] https://svn.wso2.org/repos/wso2/trunk/carbon/core/org.wso2.carbon.utils/pom.xml -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://tech.jayasoma.org Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Thilina Buddhika Associate Technical Lead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com --
[Carbon-dev] Error building Stratos AS in trunk
$Subject .. !ENTRY org.eclipse.equinox.p2.director 4 1 2012-02-21 12:11:07.252 !MESSAGE Cannot complete the install because one or more required items could not be found. !SUBENTRY 1 org.eclipse.equinox.p2.director 4 0 2012-02-21 12:11:07.252 !MESSAGE Software being installed: WSO2 Carbon - BAM Service Statistics Data Publisher Feature 4.0.0.SNAPSHOT (org.wso2.carbon.bam.data.publisher.servicestats.feature.group 4.0.0.SNAPSHOT) !SUBENTRY 1 org.eclipse.equinox.p2.director 4 0 2012-02-21 12:11:07.253 !MESSAGE Missing requirement: org.wso2.carbon.bam.data.publisher.servicestats 4.0.0.SNAPSHOT (org.wso2.carbon.bam.data.publisher.servicestats 4.0.0.SNAPSHOT) requires 'package org.wso2.carbon.bam.lwevent.core 4.0.0.SNAPSHOT' but it could not be found !SUBENTRY 1 org.eclipse.equinox.p2.director 4 1 2012-02-21 12:11:07.254 !MESSAGE Cannot satisfy dependency: !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2012-02-21 12:11:07.254 !MESSAGE From: WSO2 Carbon - BAM Service Statistics Data Publisher Feature 4.0.0.SNAPSHOT (org.wso2.carbon.bam.data.publisher.servicestats.feature.group 4.0.0.SNAPSHOT) !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2012-02-21 12:11:07.255 !MESSAGE To: org.wso2.carbon.bam.data.publisher.servicestats.server.feature.group [4.0.0.SNAPSHOT] !SUBENTRY 1 org.eclipse.equinox.p2.director 4 1 2012-02-21 12:11:07.256 !MESSAGE Cannot satisfy dependency: !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2012-02-21 12:11:07.257 !MESSAGE From: BAM Data Publisher Service Statistics Server Feature 4.0.0.SNAPSHOT (org.wso2.carbon.bam.data.publisher.servicestats.server.feature.group 4.0.0.SNAPSHOT) !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2012-02-21 12:11:07.257 !MESSAGE To: org.wso2.carbon.bam.data.publisher.servicestats [4.0.0.SNAPSHOT] -- Thanks, Shariq. Phone: +94 777 202 225 ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] [Stratos-dev] Make system statistics component cluster aware
Hi Azeez, Wouldn't we lost the ability to view statistics from a single node when we do this? Different nodes showing different statistics is ok. To view cluster wise, we are using BAM as a point for cluster monitoring. We have done a sample on handling this aspect from the BAM side, where we aggregate and show cluster wise. On Tue, Feb 21, 2012 at 12:38 PM, Afkham Azeez az...@wso2.com wrote: When you get directed to different nodes in the cluster, you will see different values for system statistics. For example, the service request/response counts may be different. To overcome this, we need to send a cluster message to all members in the relevant cluster, gather the stats from those members, and then display them. Who is going to work on this? It is not very difficult to implement. -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/** email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919 blog: **http://blog.afkham.org* http://blog.afkham.org* twitter: **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez * linked-in: **http://lk.linkedin.com/in/afkhamazeez* * * *Lean . Enterprise . Middleware* ___ Stratos-dev mailing list stratos-...@wso2.org https://wso2.org/cgi-bin/mailman/listinfo/stratos-dev -- Regards, Tharindu blog: http://mackiemathew.com/ M: +9459908 ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Error building Stratos AS in trunk
Hi, I'm looking into this. Regards, Sinthuja. On Tue, Feb 21, 2012 at 12:56 PM, Muhammed Shariq sha...@wso2.com wrote: $Subject .. !ENTRY org.eclipse.equinox.p2.director 4 1 2012-02-21 12:11:07.252 !MESSAGE Cannot complete the install because one or more required items could not be found. !SUBENTRY 1 org.eclipse.equinox.p2.director 4 0 2012-02-21 12:11:07.252 !MESSAGE Software being installed: WSO2 Carbon - BAM Service Statistics Data Publisher Feature 4.0.0.SNAPSHOT (org.wso2.carbon.bam.data.publisher.servicestats.feature.group 4.0.0.SNAPSHOT) !SUBENTRY 1 org.eclipse.equinox.p2.director 4 0 2012-02-21 12:11:07.253 !MESSAGE Missing requirement: org.wso2.carbon.bam.data.publisher.servicestats 4.0.0.SNAPSHOT (org.wso2.carbon.bam.data.publisher.servicestats 4.0.0.SNAPSHOT) requires 'package org.wso2.carbon.bam.lwevent.core 4.0.0.SNAPSHOT' but it could not be found !SUBENTRY 1 org.eclipse.equinox.p2.director 4 1 2012-02-21 12:11:07.254 !MESSAGE Cannot satisfy dependency: !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2012-02-21 12:11:07.254 !MESSAGE From: WSO2 Carbon - BAM Service Statistics Data Publisher Feature 4.0.0.SNAPSHOT (org.wso2.carbon.bam.data.publisher.servicestats.feature.group 4.0.0.SNAPSHOT) !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2012-02-21 12:11:07.255 !MESSAGE To: org.wso2.carbon.bam.data.publisher.servicestats.server.feature.group [4.0.0.SNAPSHOT] !SUBENTRY 1 org.eclipse.equinox.p2.director 4 1 2012-02-21 12:11:07.256 !MESSAGE Cannot satisfy dependency: !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2012-02-21 12:11:07.257 !MESSAGE From: BAM Data Publisher Service Statistics Server Feature 4.0.0.SNAPSHOT (org.wso2.carbon.bam.data.publisher.servicestats.server.feature.group 4.0.0.SNAPSHOT) !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2012-02-21 12:11:07.257 !MESSAGE To: org.wso2.carbon.bam.data.publisher.servicestats [4.0.0.SNAPSHOT] -- Thanks, Shariq. Phone: +94 777 202 225 ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
