Re: [Carbon-dev] [Bamboo-Build] WSO2 Carbon Trunk > WSO2 Carbon - Platform Trunk > #189 has FAILED (3 tests failed, no failures were new). Change made by 12 authors.

[Achala Aponso]

Hi,

This compilation failure is fixed now. The reason for this is a
modification in the Shindig Person API.

Thanks,

On Fri, Feb 10, 2012 at 11:45 AM, Shammi Jayasinghe  wrote:

> Hi,
>
>  Please be noted that Bamboo is building with a clean repo in each build
> cycle.
>
> Thanks
> Shammi
>
>
> On Fri, Feb 10, 2012 at 10:07 AM, Achala Aponso  wrote:
>
>> Hi,
>>
>> We are looking into this.
>>
>>
>> On Fri, Feb 10, 2012 at 6:55 AM, Shammi Jayasinghe wrote:
>>
>>> Hi GS Team,
>>>
>>>  It is reported a compilation failure in gadgets component[1]. Please
>>> have a look in to that.
>>>
>>>
>>> http://builder4.us1.wso2.org:/bamboo/browse/WSO2CARBONTUNK-WSO2CARBONPLATFORMTRUNK-JOB1-189/log
>>>
>>>
>>> Thanks
>>> Shammi
>>>
>>> [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/bamboo/Bamboo-3.4/source-repository/build-dir/WSO2CARBONTUNK-WSO2CARBONPLATFORMTRUNK-JOB1/components/gadgets/org.wso2.carbon.gadget.initializer/src/main/java/org/wso2/carbon/gadget/initializer/modules/social/services/GSPersonService.java:[44,7]
>>> org.wso2.carbon.gadget.initializer.modules.social.services.GSPersonService
>>> is not abstract and does not override abstract method
>>> updatePerson(org.apache.shindig.social.opensocial.spi.UserId,org.apache.shindig.social.opensocial.model.Person,org.apache.shindig.auth.SecurityToken)
>>> in org.apache.shindig.social.opensocial.spi.PersonService
>>>
>>> On Fri, Feb 10, 2012 at 3:29 AM, Bamboo  wrote:
>>>
  [image: Failed]  WSO2 Carbon 
 Trunk› 
 WSO2
 Carbon - Platform 
 Trunk›
 #189
 failed

 This build was manually triggered by 
 BambooBuilder
 .

 *3/7599* tests failed.
   Failing 
 Jobs
 Job
 Duration Tests[image: Failed]  WSO2 Carbon Trunk Build 
 Process
  (Default
 Stage)  381 minutes  3 of 7599 failed  
 Logs|
 Artifacts
  Code
 Changes
   View
 all 27 code 
 changes
 kasunw 
 commit new wsdl  120294
 kasunw
 Updated a wsdl in analyzer stub.  120293
 nuwan
 app fix  120292   24 more 
 changes…
 Tests
   View
 full test 
 details
3
 Existing Test Failures   Test Job BAMTestServerManager 
 startServer
   WSO2
 Carbon Trunk Build 
 Process
 GSTestServerManager 
 startServer
   WSO2
 Carbon Trunk Build 
 Process
 MSTestServerManager 
 startServer
   WSO2
 Carbon Trunk Build 
 Process
  View
 Online
 | Add 
 Comments

 This message was sent by Atl

Re: [Carbon-dev] Tomcat OSGification - progress update

[Nuwan Bandara]

On Fri, Feb 10, 2012 at 10:38 AM, Isuru Suriarachchi  wrote:

> Hi Pradeep,
>
> Shall we start committing your changes into trunk? I think it's OK
> to freeze the trunk for 2 days and finish this off.
>

+1

Regards,
/Nuwan


>
> Thanks,
> ~Isuru
>
> On Thu, Feb 9, 2012 at 1:49 PM, Pradeep Fernando  wrote:
>
>>
>>
>> On Thu, Feb 9, 2012 at 1:44 PM, Afkham Azeez  wrote:
>>
>>> You need to ensure that dynamic valve addition to the valve chain from
>>> Carbon components is supported. That is how the TenantLazyLoaderValve is
>>> added by the webapp-mgt component. Need to test tenant lazy loading when
>>> webapps receive requests as well.
>>>
>>
>> working on that. thanks.
>>
>> --Pradeep
>>
>>
>>
>> ___
>> Carbon-dev mailing list
>> Carbon-dev@wso2.org
>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>
>>
>
>
> --
> Isuru Suriarachchi
> Technical Lead
> WSO2 Inc. http://wso2.com
> email : is...@wso2.com
> blog : http://isurues.wordpress.com/
>
> lean . enterprise . middleware
>
>
> ___
> 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
*

___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] [Stratos-dev] Package import conflict in shindig bundle - Stratos Manager trunk build

[Lalaji Sureshika]

Hi Shariq,

As you said we cannot fully exclude dashboard related features from Manager
pack.But when I checked with p2-profile of Stratos Manager.In that pom,it
has only included BAM server feature and for BAM server feature,it's
sufficient and needed to keep 'dashboard server feature' only.

But in Stratos Manager,'dashboard composite feature' has been included to
its p2-profilegen and thus Shindig dependency has been included to Manager
packs.Once we do this modification,shindig dependency won't included in
manager pack. Since Stratos Manager don't use gadget rendering support in
it,there's no use of importing Shindig into Manager pack.Hence is it ok to
proceed with above modification?

Thanks;

Best Regards;


On Fri, Feb 10, 2012 at 11:20 AM, Muhammed Shariq  wrote:

> Hi Sanjeewa,
>
> Ideally we should be able to use only the BAM serve feature in Manager,
> that way we shouldn't need the dashboard feature in Manager. Can you please
> check if we have the BAM server feature only or the aggregate feature, and
> the possibility of excluding the dashboard feature from Manager ?
>
>
> On Fri, Feb 10, 2012 at 10:15 AM, Muhammed Shariq  wrote:
>
>> Hi,
>>
>> I tried removing the dashboard feature from Manager but the issue is
>> Manager uses BAM feature that depends on dashboard feature, hence Shindig
>> getting bundled in to Manager. However I got this error a couple of weeks
>> back and managed to sort it out with Lalaji's help, wonder how it
>> resurfaced ?
>>
>>
>> On Fri, Feb 10, 2012 at 10:00 AM, Lalaji Sureshika wrote:
>>
>>> Hi,
>>>
>>> Will check on the issue with a trunk manager build. However keeping
>>> Shindig inside Stratos Manager pack doesn't useful,since Stratos Manager
>>> doesn't using dashboard in it  and such that can't we simply remove
>>> dashboard related features from Stratos Manager,then we can simply avoid
>>> dependency to Shindig from Stratos Manager?
>>>
>>> Thanks;
>>>
>>> Best Regards;
>>>
>>> On Thu, Feb 9, 2012 at 11:18 PM, Rajika Kumarasiri wrote:
>>>
 org.osgi.framework.BundleException: The bundle "shindig_3.0.0.wso2v1
 [329]" could not be resolved. Reason: Package uses conflict:
 Import-Package: com.google.common.collect; version="0.9.0.wso2v1"
  at
 org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1327)
 at
 org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1311)
  at
 org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:323)
 at
 org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299)
  at
 org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:291)
 at
 org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.startBundles(ConfigApplier.java:307)
  at
 org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.install(ConfigApplier.java:108)
 at
 org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:129)
  at
 org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:143)
 at
 org.eclipse.equinox.internal.p2.reconciler.dropins.ProfileSynchronizer.applyConfiguration(ProfileSynchronizer.java:781)
  at
 org.eclipse.equinox.internal.p2.reconciler.dropins.ProfileSynchronizer.synchronize(ProfileSynchronizer.java:134)
 at
 org.eclipse.equinox.internal.p2.reconciler.dropins.Activator.synchronize(Activator.java:461)
  at
 org.eclipse.equinox.internal.p2.reconciler.dropins.Activator.start(Activator.java:176)
 at
 org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
  at java.security.AccessController.doPrivileged(Native Method)
 at
 org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
  at
 org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
 at
 org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
  at
 org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:389)
 at
 org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1130)
  at
 org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
 at
 org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
  at
 org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
 at
 org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
  at
 org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438)
 at

Re: [Carbon-dev] [Architecture] [Proposal] Restructuring the SVN repository of Carbon

[Afkham Azeez]

Do a PoC or dry run in scratch, figure out the issue, figure out how to
make this work with Bamboo, repeat a few of these dry runs if necessary,
freeze the trunk once ready, and then carry out the exercise in the trunk.
We should understand that the WSO2 SVN is a system in production, and we
cannot afford to have long downtimes. You need to follow strict procedures
while making major changes like this.

On Fri, Feb 10, 2012 at 12:19 PM, Isuru Suriarachchi  wrote:

>
> On Fri, Feb 10, 2012 at 12:04 PM, Sameera Jayasoma wrote:
>
>> Azeez and myself had an offline discussion on this. We
>> will initially perform this on a scratch area and test all the builds. If
>> they are okay, we will make this change live. This requires changes to the
>> existing build plans.
>
>
> Trunk should be frozen until the scratch is stabilized. Isn't it?
> Otherwise the commits should be applied again into the restructured svn.
> Can we get this done including the Tomcat OSGification by the end of next
> week? If so, +1 for the plan.
>
> Thanks,
> ~Isuru
>
>
>>
>> Thanks,
>> Sameera.
>>
>>
>> On Fri, Feb 10, 2012 at 12:00 PM, Sameera Jayasoma wrote:
>>
>>> Hi Azeez/Isuru,
>>>
>>> We(Pradeep and myselft) already planned to perform this action during
>>> this weekend. I understand the complexities of the effort. According the
>>> plan, we were thinking of performing this in scratch area and stabilize the
>>> build.
>>>
>>> IMV, we better of doing this soon, because this is first step towards
>>> making Carbon Core a standalone product.
>>>
>>> My apologies for not executing this earlier. I was on leave.
>>>
>>> Thanks,
>>> Sameera.
>>>
>>>
>>> On Fri, Feb 10, 2012 at 10:50 AM, Afkham Azeez  wrote:
>>>


 On Fri, Feb 10, 2012 at 10:35 AM, Isuru Suriarachchi wrote:

> Hi Sameera,
>
> Are we going to do this change for Carbon 4.0.0? Had an offline chat
> with Samisa on this. Given the amount of work and time needed to complete
> and stabilize this, we just thought it's good to push this to 5.0.0. What
> do you think?
>

 +1 for deferring this, given that we have many other drastic changes
 going into 4.0.0. However, we better get started on the 'kernelization' of
 carbon. This can be easily done by moving many of the modules in the
 current carbon-core into components, and changing the product p2-profiles
 to pick up these components. Once we have that, we can gradually move into
 the proposed SVN structure.


>
> Thanks,
> ~Isuru
>
>
> On Wed, Feb 8, 2012 at 10:30 PM, Nuwan Bandara  wrote:
>
>> Hi
>>
>> On Tue, Feb 7, 2012 at 6:30 AM, Afkham Azeez  wrote:
>>
>>> For this approach to properly work, we need to have proper package
>>> export & import versions. Otherwise, say for example, two different
>>> features require different versions of a particular bundle, then these
>>> features may not be able to coexist. When upgrading a versions of an 
>>> orbit
>>> dependency, the should be a way to track all its dependant &  change 
>>> them
>>> accordingly to avoid ending up with unnecessary jar duplication.
>>>
>>
>> +1, we need to concentrate on imports and exports more than we are
>> doing now. Its a nightmare to find issues when an orbit bundle is updated
>> not knowingly.
>>
>> Regards,
>> /Nuwan
>>
>>
>>>  --
>>> Afkham Azeez
>>> Sent from my phone
>>> On Feb 6, 2012 9:27 PM, "Sanjiva Weerawarana" 
>>> wrote:
>>>
 +1 for going ahead (without opinion on timing) and to Amila's
 suggestion of making the orbit stuff another TLP.

 I'm +1 for graphite per Senaka for X.

 Sanjiva.

 On Mon, Feb 6, 2012 at 4:03 PM, Dimuthu Leelarathne <
 dimut...@wso2.com> wrote:

> Hi all,
>
> +1.
>
> When installing other features to different products, it should
> mention the carbon core version. Currently, the carbon core is the
> intersection of products, so there is no problem at all. But if we go 
> ahead
> with minimizing carbon-core it can be tricky to handle. Just had an 
> offline
> chat with Sameera, and according to him P2 handles it nicely.
>
> thanks,
> dimuthu
>
> On Mon, Feb 6, 2012 at 8:24 AM, Sumedha Rubasinghe <
> sume...@wso2.com> wrote:
>
>> +1 for the idea. B4 doing the actual change, how about running
>> through different scenarios (like Amila mentioned) - like how we did 
>> for
>> branching approach. Figuring out problems later would be costly in 
>> terms of
>> time.
>>
>> /sumedha
>>
>> On Sat, Feb 4, 2012 at 5:14 PM, Sameera Jayasoma <
>> same...@wso2.com> wrote:
>>
>>> *Objective*:
>>>

Re: [Carbon-dev] Tomcat OSGification - progress update

[Kishanthan Thangarajah]

Hi Pradeep,

On Wed, Feb 8, 2012 at 10:53 PM, Pradeep Fernando  wrote:

> Hi all,
>
> Think i'm done with the first iteration of the tomcat-OSGification effort.
> It time to move the code in to trunk. I could run modified wso2-as without
> a problem. Was able to solve the transport related issue by Extending the
> TomcatStandardService and not starting transports.
>
> I need help on following areas (porting),
>
> 1. make sure all the features are working in wso2-as - kishanthan (?)
>

I tried building you scratch, there is a compilation failure when building
AS samples. It is related to the javax-servlet being moved in to orbit. Ill
fix that in your scratch. Also there is another issue when accessing the
services list. It seems like SecurityConfigAdmin class is not found.  We
have to fix that too.

Thanks,
Kishanthan.

> 2. porting the patching code to new carbon startup classes. -Dileepa
> 3. Jaggery deployer related things - (?)
>
>
> As soon as we are done with above tasks, we are going to move the code in
> to trunk. Trunk will be frozen for few days (this work + svn restructuring).
>
>
> Please checkout the code found in [1] and start building it. :)
>
>
> thanks,
> --Pradeep
>



-- 
*Kishanthan Thangarajah*
Software Engineer,
Development Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com*
Twitter - *http://twitter.com/kishanthan*
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] [Stratos-dev] Package import conflict in shindig bundle - Stratos Manager trunk build

[Muhammed Shariq]

Hi Sanjeewa,

Ideally we should be able to use only the BAM serve feature in Manager,
that way we shouldn't need the dashboard feature in Manager. Can you please
check if we have the BAM server feature only or the aggregate feature, and
the possibility of excluding the dashboard feature from Manager ?

On Fri, Feb 10, 2012 at 10:15 AM, Muhammed Shariq  wrote:

> Hi,
>
> I tried removing the dashboard feature from Manager but the issue is
> Manager uses BAM feature that depends on dashboard feature, hence Shindig
> getting bundled in to Manager. However I got this error a couple of weeks
> back and managed to sort it out with Lalaji's help, wonder how it
> resurfaced ?
>
>
> On Fri, Feb 10, 2012 at 10:00 AM, Lalaji Sureshika wrote:
>
>> Hi,
>>
>> Will check on the issue with a trunk manager build. However keeping
>> Shindig inside Stratos Manager pack doesn't useful,since Stratos Manager
>> doesn't using dashboard in it  and such that can't we simply remove
>> dashboard related features from Stratos Manager,then we can simply avoid
>> dependency to Shindig from Stratos Manager?
>>
>> Thanks;
>>
>> Best Regards;
>>
>> On Thu, Feb 9, 2012 at 11:18 PM, Rajika Kumarasiri wrote:
>>
>>> org.osgi.framework.BundleException: The bundle "shindig_3.0.0.wso2v1
>>> [329]" could not be resolved. Reason: Package uses conflict:
>>> Import-Package: com.google.common.collect; version="0.9.0.wso2v1"
>>>  at
>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1327)
>>> at
>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1311)
>>>  at
>>> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:323)
>>> at
>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299)
>>>  at
>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:291)
>>> at
>>> org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.startBundles(ConfigApplier.java:307)
>>>  at
>>> org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.install(ConfigApplier.java:108)
>>> at
>>> org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:129)
>>>  at
>>> org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:143)
>>> at
>>> org.eclipse.equinox.internal.p2.reconciler.dropins.ProfileSynchronizer.applyConfiguration(ProfileSynchronizer.java:781)
>>>  at
>>> org.eclipse.equinox.internal.p2.reconciler.dropins.ProfileSynchronizer.synchronize(ProfileSynchronizer.java:134)
>>> at
>>> org.eclipse.equinox.internal.p2.reconciler.dropins.Activator.synchronize(Activator.java:461)
>>>  at
>>> org.eclipse.equinox.internal.p2.reconciler.dropins.Activator.start(Activator.java:176)
>>> at
>>> org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
>>>  at java.security.AccessController.doPrivileged(Native Method)
>>> at
>>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
>>>  at
>>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
>>> at
>>> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
>>>  at
>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:389)
>>> at
>>> org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1130)
>>>  at
>>> org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
>>> at
>>> org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
>>>  at
>>> org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
>>> at
>>> org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
>>>  at
>>> org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438)
>>> at
>>> org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1)
>>>  at
>>> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
>>> at
>>> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
>>> [2012-02-10 00:11:04,053]  INFO
>>> {org.wso2.carbon.core.init.CarbonServerManager} -  Starting Carbon
>>> initialization...
>>>
>>>
>>> ___
>>> Stratos-dev mailing list
>>> stratos-...@wso2.org
>>> https://wso2.org/cgi-bin/mailman/listinfo/stratos-dev
>>>
>>>
>>
>>
>> --
>> Lalaji Sureshika
>>
>> Software Engineer
>> WSO2 Inc.
>>
>>
>>
>> ___
>> Stratos-dev mailing list
>> stratos-...@wso2.org
>> https://wso2.org/cgi-bin/mailman/listinfo/stratos-dev
>>
>>
>
>
> --
> Thanks,
> Sha

Re: [Carbon-dev] [Architecture] [Proposal] Restructuring the SVN repository of Carbon

[Isuru Suriarachchi]

On Fri, Feb 10, 2012 at 12:04 PM, Sameera Jayasoma  wrote:

> Azeez and myself had an offline discussion on this. We
> will initially perform this on a scratch area and test all the builds. If
> they are okay, we will make this change live. This requires changes to the
> existing build plans.


Trunk should be frozen until the scratch is stabilized. Isn't it? Otherwise
the commits should be applied again into the restructured svn. Can we get
this done including the Tomcat OSGification by the end of next week? If so,
+1 for the plan.

Thanks,
~Isuru


>
> Thanks,
> Sameera.
>
>
> On Fri, Feb 10, 2012 at 12:00 PM, Sameera Jayasoma wrote:
>
>> Hi Azeez/Isuru,
>>
>> We(Pradeep and myselft) already planned to perform this action during
>> this weekend. I understand the complexities of the effort. According the
>> plan, we were thinking of performing this in scratch area and stabilize the
>> build.
>>
>> IMV, we better of doing this soon, because this is first step towards
>> making Carbon Core a standalone product.
>>
>> My apologies for not executing this earlier. I was on leave.
>>
>> Thanks,
>> Sameera.
>>
>>
>> On Fri, Feb 10, 2012 at 10:50 AM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Fri, Feb 10, 2012 at 10:35 AM, Isuru Suriarachchi wrote:
>>>
 Hi Sameera,

 Are we going to do this change for Carbon 4.0.0? Had an offline chat
 with Samisa on this. Given the amount of work and time needed to complete
 and stabilize this, we just thought it's good to push this to 5.0.0. What
 do you think?

>>>
>>> +1 for deferring this, given that we have many other drastic changes
>>> going into 4.0.0. However, we better get started on the 'kernelization' of
>>> carbon. This can be easily done by moving many of the modules in the
>>> current carbon-core into components, and changing the product p2-profiles
>>> to pick up these components. Once we have that, we can gradually move into
>>> the proposed SVN structure.
>>>
>>>

 Thanks,
 ~Isuru


 On Wed, Feb 8, 2012 at 10:30 PM, Nuwan Bandara  wrote:

> Hi
>
> On Tue, Feb 7, 2012 at 6:30 AM, Afkham Azeez  wrote:
>
>> For this approach to properly work, we need to have proper package
>> export & import versions. Otherwise, say for example, two different
>> features require different versions of a particular bundle, then these
>> features may not be able to coexist. When upgrading a versions of an 
>> orbit
>> dependency, the should be a way to track all its dependant &  change them
>> accordingly to avoid ending up with unnecessary jar duplication.
>>
>
> +1, we need to concentrate on imports and exports more than we are
> doing now. Its a nightmare to find issues when an orbit bundle is updated
> not knowingly.
>
> Regards,
> /Nuwan
>
>
>>  --
>> Afkham Azeez
>> Sent from my phone
>> On Feb 6, 2012 9:27 PM, "Sanjiva Weerawarana" 
>> wrote:
>>
>>> +1 for going ahead (without opinion on timing) and to Amila's
>>> suggestion of making the orbit stuff another TLP.
>>>
>>> I'm +1 for graphite per Senaka for X.
>>>
>>> Sanjiva.
>>>
>>> On Mon, Feb 6, 2012 at 4:03 PM, Dimuthu Leelarathne <
>>> dimut...@wso2.com> wrote:
>>>
 Hi all,

 +1.

 When installing other features to different products, it should
 mention the carbon core version. Currently, the carbon core is the
 intersection of products, so there is no problem at all. But if we go 
 ahead
 with minimizing carbon-core it can be tricky to handle. Just had an 
 offline
 chat with Sameera, and according to him P2 handles it nicely.

 thanks,
 dimuthu

 On Mon, Feb 6, 2012 at 8:24 AM, Sumedha Rubasinghe <
 sume...@wso2.com> wrote:

> +1 for the idea. B4 doing the actual change, how about running
> through different scenarios (like Amila mentioned) - like how we did 
> for
> branching approach. Figuring out problems later would be costly in 
> terms of
> time.
>
> /sumedha
>
> On Sat, Feb 4, 2012 at 5:14 PM, Sameera Jayasoma  > wrote:
>
>> *Objective*:
>> Make Carbon core a top level project in WSO2 trunk. At the moment
>> complete Carbon platform code lies under
>> https://svn.wso2.org/repos/wso2/trunk/carbon/. This structure
>> has its own problems.
>>
>> *Motivations*:
>> 1) Carbon core can be treated as a separate product which has its
>> own dependencies, orbit and Carbon core can be released 
>> independently of
>> other Carbon components, products.
>> 2) To ensure that the Carbon based products can depend on a
>> stable, well tested and released version of Carbon instead of the 
>

Re: [Carbon-dev] [Architecture] [Proposal] Restructuring the SVN repository of Carbon

[Sameera Jayasoma]

Azeez and myself had an offline discussion on this. We
will initially perform this on a scratch area and test all the builds. If
they are okay, we will make this change live. This requires changes to the
existing build plans.

Thanks,
Sameera.

On Fri, Feb 10, 2012 at 12:00 PM, Sameera Jayasoma  wrote:

> Hi Azeez/Isuru,
>
> We(Pradeep and myselft) already planned to perform this action during this
> weekend. I understand the complexities of the effort. According the plan,
> we were thinking of performing this in scratch area and stabilize the
> build.
>
> IMV, we better of doing this soon, because this is first step towards
> making Carbon Core a standalone product.
>
> My apologies for not executing this earlier. I was on leave.
>
> Thanks,
> Sameera.
>
>
> On Fri, Feb 10, 2012 at 10:50 AM, Afkham Azeez  wrote:
>
>>
>>
>> On Fri, Feb 10, 2012 at 10:35 AM, Isuru Suriarachchi wrote:
>>
>>> Hi Sameera,
>>>
>>> Are we going to do this change for Carbon 4.0.0? Had an offline chat
>>> with Samisa on this. Given the amount of work and time needed to complete
>>> and stabilize this, we just thought it's good to push this to 5.0.0. What
>>> do you think?
>>>
>>
>> +1 for deferring this, given that we have many other drastic changes
>> going into 4.0.0. However, we better get started on the 'kernelization' of
>> carbon. This can be easily done by moving many of the modules in the
>> current carbon-core into components, and changing the product p2-profiles
>> to pick up these components. Once we have that, we can gradually move into
>> the proposed SVN structure.
>>
>>
>>>
>>> Thanks,
>>> ~Isuru
>>>
>>>
>>> On Wed, Feb 8, 2012 at 10:30 PM, Nuwan Bandara  wrote:
>>>
 Hi

 On Tue, Feb 7, 2012 at 6:30 AM, Afkham Azeez  wrote:

> For this approach to properly work, we need to have proper package
> export & import versions. Otherwise, say for example, two different
> features require different versions of a particular bundle, then these
> features may not be able to coexist. When upgrading a versions of an orbit
> dependency, the should be a way to track all its dependant &  change them
> accordingly to avoid ending up with unnecessary jar duplication.
>

 +1, we need to concentrate on imports and exports more than we are
 doing now. Its a nightmare to find issues when an orbit bundle is updated
 not knowingly.

 Regards,
 /Nuwan


>  --
> Afkham Azeez
> Sent from my phone
> On Feb 6, 2012 9:27 PM, "Sanjiva Weerawarana" 
> wrote:
>
>> +1 for going ahead (without opinion on timing) and to Amila's
>> suggestion of making the orbit stuff another TLP.
>>
>> I'm +1 for graphite per Senaka for X.
>>
>> Sanjiva.
>>
>> On Mon, Feb 6, 2012 at 4:03 PM, Dimuthu Leelarathne <
>> dimut...@wso2.com> wrote:
>>
>>> Hi all,
>>>
>>> +1.
>>>
>>> When installing other features to different products, it should
>>> mention the carbon core version. Currently, the carbon core is the
>>> intersection of products, so there is no problem at all. But if we go 
>>> ahead
>>> with minimizing carbon-core it can be tricky to handle. Just had an 
>>> offline
>>> chat with Sameera, and according to him P2 handles it nicely.
>>>
>>> thanks,
>>> dimuthu
>>>
>>> On Mon, Feb 6, 2012 at 8:24 AM, Sumedha Rubasinghe >> > wrote:
>>>
 +1 for the idea. B4 doing the actual change, how about running
 through different scenarios (like Amila mentioned) - like how we did 
 for
 branching approach. Figuring out problems later would be costly in 
 terms of
 time.

 /sumedha

 On Sat, Feb 4, 2012 at 5:14 PM, Sameera Jayasoma 
 wrote:

> *Objective*:
> Make Carbon core a top level project in WSO2 trunk. At the moment
> complete Carbon platform code lies under
> https://svn.wso2.org/repos/wso2/trunk/carbon/. This structure has
> its own problems.
>
> *Motivations*:
> 1) Carbon core can be treated as a separate product which has its
> own dependencies, orbit and Carbon core can be released independently 
> of
> other Carbon components, products.
> 2) To ensure that the Carbon based products can depend on a
> stable, well tested and released version of Carbon instead of the 
> Carbon
> trunk.
> 3) This will also ensure the stability of the Carbon based
> products, because they are no longer depend on the Carbon trunk which 
> might
> undergo drastic changes time to time.
>
> *Execution*:
> Here is my proposal.
> 1) We need to create two top level directories for Carbon and for
> components, features and Carbon based products. Sample structure is 
> shown
> below.
>

Re: [Carbon-dev] [Architecture] [Proposal] Restructuring the SVN repository of Carbon

[Sameera Jayasoma]

Hi Azeez/Isuru,

We(Pradeep and myselft) already planned to perform this action during this
weekend. I understand the complexities of the effort. According the plan,
we were thinking of performing this in scratch area and stabilize the
build.

IMV, we better of doing this soon, because this is first step towards
making Carbon Core a standalone product.

My apologies for not executing this earlier. I was on leave.

Thanks,
Sameera.

On Fri, Feb 10, 2012 at 10:50 AM, Afkham Azeez  wrote:

>
>
> On Fri, Feb 10, 2012 at 10:35 AM, Isuru Suriarachchi wrote:
>
>> Hi Sameera,
>>
>> Are we going to do this change for Carbon 4.0.0? Had an offline chat with
>> Samisa on this. Given the amount of work and time needed to complete and
>> stabilize this, we just thought it's good to push this to 5.0.0. What do
>> you think?
>>
>
> +1 for deferring this, given that we have many other drastic changes going
> into 4.0.0. However, we better get started on the 'kernelization' of
> carbon. This can be easily done by moving many of the modules in the
> current carbon-core into components, and changing the product p2-profiles
> to pick up these components. Once we have that, we can gradually move into
> the proposed SVN structure.
>
>
>>
>> Thanks,
>> ~Isuru
>>
>>
>> On Wed, Feb 8, 2012 at 10:30 PM, Nuwan Bandara  wrote:
>>
>>> Hi
>>>
>>> On Tue, Feb 7, 2012 at 6:30 AM, Afkham Azeez  wrote:
>>>
 For this approach to properly work, we need to have proper package
 export & import versions. Otherwise, say for example, two different
 features require different versions of a particular bundle, then these
 features may not be able to coexist. When upgrading a versions of an orbit
 dependency, the should be a way to track all its dependant &  change them
 accordingly to avoid ending up with unnecessary jar duplication.

>>>
>>> +1, we need to concentrate on imports and exports more than we are doing
>>> now. Its a nightmare to find issues when an orbit bundle is updated not
>>> knowingly.
>>>
>>> Regards,
>>> /Nuwan
>>>
>>>
  --
 Afkham Azeez
 Sent from my phone
 On Feb 6, 2012 9:27 PM, "Sanjiva Weerawarana"  wrote:

> +1 for going ahead (without opinion on timing) and to Amila's
> suggestion of making the orbit stuff another TLP.
>
> I'm +1 for graphite per Senaka for X.
>
> Sanjiva.
>
> On Mon, Feb 6, 2012 at 4:03 PM, Dimuthu Leelarathne  > wrote:
>
>> Hi all,
>>
>> +1.
>>
>> When installing other features to different products, it should
>> mention the carbon core version. Currently, the carbon core is the
>> intersection of products, so there is no problem at all. But if we go 
>> ahead
>> with minimizing carbon-core it can be tricky to handle. Just had an 
>> offline
>> chat with Sameera, and according to him P2 handles it nicely.
>>
>> thanks,
>> dimuthu
>>
>> On Mon, Feb 6, 2012 at 8:24 AM, Sumedha Rubasinghe 
>> wrote:
>>
>>> +1 for the idea. B4 doing the actual change, how about running
>>> through different scenarios (like Amila mentioned) - like how we did for
>>> branching approach. Figuring out problems later would be costly in 
>>> terms of
>>> time.
>>>
>>> /sumedha
>>>
>>> On Sat, Feb 4, 2012 at 5:14 PM, Sameera Jayasoma 
>>> wrote:
>>>
 *Objective*:
 Make Carbon core a top level project in WSO2 trunk. At the moment
 complete Carbon platform code lies under
 https://svn.wso2.org/repos/wso2/trunk/carbon/. This structure has
 its own problems.

 *Motivations*:
 1) Carbon core can be treated as a separate product which has its
 own dependencies, orbit and Carbon core can be released independently 
 of
 other Carbon components, products.
 2) To ensure that the Carbon based products can depend on a stable,
 well tested and released version of Carbon instead of the Carbon trunk.
 3) This will also ensure the stability of the Carbon based
 products, because they are no longer depend on the Carbon trunk which 
 might
 undergo drastic changes time to time.

 *Execution*:
 Here is my proposal.
 1) We need to create two top level directories for Carbon and for
 components, features and Carbon based products. Sample structure is 
 shown
 below.

 carbon
 |--dependencies
 |--orbits
 |--core (core set of bundles.)
 |--features (Carbon core features)
 |--product (Carbon product)

 X (TODO we need to come up with a name. How about silicon. Dr.
 Sanjiva once mentioned this name. :) )
 |--dependencies
 |--orbits
 |--components
 |--features
 |--products

 2) In order to change the existing svn structure to
 a

Re: [Carbon-dev] [Bamboo-Build] WSO2 Carbon Trunk > WSO2 Carbon - Platform Trunk > #189 has FAILED (3 tests failed, no failures were new). Change made by 12 authors.

[Shammi Jayasinghe]

Hi,

 Please be noted that Bamboo is building with a clean repo in each build
cycle.

Thanks
Shammi

On Fri, Feb 10, 2012 at 10:07 AM, Achala Aponso  wrote:

> Hi,
>
> We are looking into this.
>
>
> On Fri, Feb 10, 2012 at 6:55 AM, Shammi Jayasinghe wrote:
>
>> Hi GS Team,
>>
>>  It is reported a compilation failure in gadgets component[1]. Please
>> have a look in to that.
>>
>>
>> http://builder4.us1.wso2.org:/bamboo/browse/WSO2CARBONTUNK-WSO2CARBONPLATFORMTRUNK-JOB1-189/log
>>
>>
>> Thanks
>> Shammi
>>
>> [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/bamboo/Bamboo-3.4/source-repository/build-dir/WSO2CARBONTUNK-WSO2CARBONPLATFORMTRUNK-JOB1/components/gadgets/org.wso2.carbon.gadget.initializer/src/main/java/org/wso2/carbon/gadget/initializer/modules/social/services/GSPersonService.java:[44,7]
>> org.wso2.carbon.gadget.initializer.modules.social.services.GSPersonService
>> is not abstract and does not override abstract method
>> updatePerson(org.apache.shindig.social.opensocial.spi.UserId,org.apache.shindig.social.opensocial.model.Person,org.apache.shindig.auth.SecurityToken)
>> in org.apache.shindig.social.opensocial.spi.PersonService
>>
>> On Fri, Feb 10, 2012 at 3:29 AM, Bamboo  wrote:
>>
>>>  [image: Failed]  WSO2 Carbon 
>>> Trunk› WSO2
>>> Carbon - Platform 
>>> Trunk›
>>> #189
>>> failed
>>>
>>> This build was manually triggered by 
>>> BambooBuilder
>>> .
>>>
>>> *3/7599* tests failed.
>>>   Failing 
>>> Jobs
>>> Job
>>> Duration Tests[image: Failed]  WSO2 Carbon Trunk Build 
>>> Process
>>>  (Default
>>> Stage)  381 minutes  3 of 7599 failed  
>>> Logs|
>>> Artifacts
>>>  Code
>>> Changes
>>>   View
>>> all 27 code 
>>> changes
>>> kasunw 
>>> commit new wsdl  120294
>>> kasunw
>>> Updated a wsdl in analyzer stub.  120293
>>> nuwan
>>> app fix  120292   24 more 
>>> changes…
>>> Tests
>>>   View
>>> full test 
>>> details
>>>3
>>> Existing Test Failures   Test Job BAMTestServerManager 
>>> startServer
>>>   WSO2
>>> Carbon Trunk Build 
>>> Process
>>> GSTestServerManager 
>>> startServer
>>>   WSO2
>>> Carbon Trunk Build 
>>> Process
>>> MSTestServerManager 
>>> startServer
>>>   WSO2
>>> Carbon Trunk Build 
>>> Process
>>>  View
>>> Online
>>> | Add 
>>> Comments
>>>
>>> This message was sent by Atlassian 
>>> Bamboo
>>> .
>>>
>>> If you wish to stop receiving these emails edit your user 
>>> profileor
>>>  notify
>>> your 
>>> administrator

Re: [Carbon-dev] What is GhoshtRegistry class ?

[Afkham Azeez]

Loading the registry while creating the CarbonContext is an expensive
operation, and adds a lot of overhead since the CarbonContext is created
for each request. So, we load a ghost of the registry, and only load the
real registry when the registry is requested. Perhaps it can go into
registry.core?

On Fri, Feb 10, 2012 at 12:47 AM, Pradeep Fernando  wrote:

> Hi,
>
> found a class named GhostRegistry under carbon.server. Are we actually
> using it ? if yes, Have to find a new home for this class. how about
> carbon.utils ?
>
> thanks,
> --Pradeep
>
>
>
> ___
> 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/
* **
email: **az...@wso2.com* * cell: +94 77 3320919
blog: **http://blog.afkham.org* *
twitter: **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] [Architecture] [Proposal] Restructuring the SVN repository of Carbon

[Afkham Azeez]

On Fri, Feb 10, 2012 at 10:35 AM, Isuru Suriarachchi  wrote:

> Hi Sameera,
>
> Are we going to do this change for Carbon 4.0.0? Had an offline chat with
> Samisa on this. Given the amount of work and time needed to complete and
> stabilize this, we just thought it's good to push this to 5.0.0. What do
> you think?
>

+1 for deferring this, given that we have many other drastic changes going
into 4.0.0. However, we better get started on the 'kernelization' of
carbon. This can be easily done by moving many of the modules in the
current carbon-core into components, and changing the product p2-profiles
to pick up these components. Once we have that, we can gradually move into
the proposed SVN structure.


>
> Thanks,
> ~Isuru
>
>
> On Wed, Feb 8, 2012 at 10:30 PM, Nuwan Bandara  wrote:
>
>> Hi
>>
>> On Tue, Feb 7, 2012 at 6:30 AM, Afkham Azeez  wrote:
>>
>>> For this approach to properly work, we need to have proper package
>>> export & import versions. Otherwise, say for example, two different
>>> features require different versions of a particular bundle, then these
>>> features may not be able to coexist. When upgrading a versions of an orbit
>>> dependency, the should be a way to track all its dependant &  change them
>>> accordingly to avoid ending up with unnecessary jar duplication.
>>>
>>
>> +1, we need to concentrate on imports and exports more than we are doing
>> now. Its a nightmare to find issues when an orbit bundle is updated not
>> knowingly.
>>
>> Regards,
>> /Nuwan
>>
>>
>>>  --
>>> Afkham Azeez
>>> Sent from my phone
>>> On Feb 6, 2012 9:27 PM, "Sanjiva Weerawarana"  wrote:
>>>
 +1 for going ahead (without opinion on timing) and to Amila's
 suggestion of making the orbit stuff another TLP.

 I'm +1 for graphite per Senaka for X.

 Sanjiva.

 On Mon, Feb 6, 2012 at 4:03 PM, Dimuthu Leelarathne 
 wrote:

> Hi all,
>
> +1.
>
> When installing other features to different products, it should
> mention the carbon core version. Currently, the carbon core is the
> intersection of products, so there is no problem at all. But if we go 
> ahead
> with minimizing carbon-core it can be tricky to handle. Just had an 
> offline
> chat with Sameera, and according to him P2 handles it nicely.
>
> thanks,
> dimuthu
>
> On Mon, Feb 6, 2012 at 8:24 AM, Sumedha Rubasinghe 
> wrote:
>
>> +1 for the idea. B4 doing the actual change, how about running
>> through different scenarios (like Amila mentioned) - like how we did for
>> branching approach. Figuring out problems later would be costly in terms 
>> of
>> time.
>>
>> /sumedha
>>
>> On Sat, Feb 4, 2012 at 5:14 PM, Sameera Jayasoma wrote:
>>
>>> *Objective*:
>>> Make Carbon core a top level project in WSO2 trunk. At the moment
>>> complete Carbon platform code lies under
>>> https://svn.wso2.org/repos/wso2/trunk/carbon/. This structure has
>>> its own problems.
>>>
>>> *Motivations*:
>>> 1) Carbon core can be treated as a separate product which has its
>>> own dependencies, orbit and Carbon core can be released independently of
>>> other Carbon components, products.
>>> 2) To ensure that the Carbon based products can depend on a stable,
>>> well tested and released version of Carbon instead of the Carbon trunk.
>>> 3) This will also ensure the stability of the Carbon based products,
>>> because they are no longer depend on the Carbon trunk which might 
>>> undergo
>>> drastic changes time to time.
>>>
>>> *Execution*:
>>> Here is my proposal.
>>> 1) We need to create two top level directories for Carbon and for
>>> components, features and Carbon based products. Sample structure is 
>>> shown
>>> below.
>>>
>>> carbon
>>> |--dependencies
>>> |--orbits
>>> |--core (core set of bundles.)
>>> |--features (Carbon core features)
>>> |--product (Carbon product)
>>>
>>> X (TODO we need to come up with a name. How about silicon. Dr.
>>> Sanjiva once mentioned this name. :) )
>>> |--dependencies
>>> |--orbits
>>> |--components
>>> |--features
>>> |--products
>>>
>>> 2) In order to change the existing svn structure to a structure like
>>> above, we need to hold all the commits, say for two to three days and
>>> restructure the SVN, test properly and release for commits.
>>>
>>> Please feel free to comment.
>>>
>>> Thanks,
>>> Sameera.
>>>
>>> --
>>> 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
>>>
>>> ___
>>> Architecture mailing list
>>> architect...@wso2.org
>>> https://mai

Re: [Carbon-dev] Tomcat OSGification - progress update

[Afkham Azeez]

On Fri, Feb 10, 2012 at 10:38 AM, Isuru Suriarachchi  wrote:

> Hi Pradeep,
>
> Shall we start committing your changes into trunk? I think it's OK
> to freeze the trunk for 2 days and finish this off.
>

+1. You can apply the changes to the trunk, and do a full build with tests
to see how things go. I don't think this will break a lot of things. At
least try to get the tests passing.


> Thanks,
> ~Isuru
>
>  On Thu, Feb 9, 2012 at 1:49 PM, Pradeep Fernando wrote:
>
>>
>>
>> On Thu, Feb 9, 2012 at 1:44 PM, Afkham Azeez  wrote:
>>
>>> You need to ensure that dynamic valve addition to the valve chain from
>>> Carbon components is supported. That is how the TenantLazyLoaderValve is
>>> added by the webapp-mgt component. Need to test tenant lazy loading when
>>> webapps receive requests as well.
>>>
>>
>> working on that. thanks.
>>
>> --Pradeep
>>
>>
>>
>> ___
>> Carbon-dev mailing list
>> Carbon-dev@wso2.org
>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>
>>
>
>
> --
> Isuru Suriarachchi
> Technical Lead
> WSO2 Inc. http://wso2.com
> email : is...@wso2.com
> blog : http://isurues.wordpress.com/
>
> lean . enterprise . middleware
>
>
> ___
> 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/
* **
email: **az...@wso2.com* * cell: +94 77 3320919
blog: **http://blog.afkham.org* *
twitter: **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] Tomcat OSGification - progress update

[Isuru Suriarachchi]

Hi Pradeep,

Shall we start committing your changes into trunk? I think it's OK
to freeze the trunk for 2 days and finish this off.

Thanks,
~Isuru

On Thu, Feb 9, 2012 at 1:49 PM, Pradeep Fernando  wrote:

>
>
> On Thu, Feb 9, 2012 at 1:44 PM, Afkham Azeez  wrote:
>
>> You need to ensure that dynamic valve addition to the valve chain from
>> Carbon components is supported. That is how the TenantLazyLoaderValve is
>> added by the webapp-mgt component. Need to test tenant lazy loading when
>> webapps receive requests as well.
>>
>
> working on that. thanks.
>
> --Pradeep
>
>
>
> ___
> Carbon-dev mailing list
> Carbon-dev@wso2.org
> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>
>


-- 
Isuru Suriarachchi
Technical Lead
WSO2 Inc. http://wso2.com
email : is...@wso2.com
blog : http://isurues.wordpress.com/

lean . enterprise . middleware
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] [Architecture] [Proposal] Restructuring the SVN repository of Carbon

[Isuru Suriarachchi]

Hi Sameera,

Are we going to do this change for Carbon 4.0.0? Had an offline chat with
Samisa on this. Given the amount of work and time needed to complete and
stabilize this, we just thought it's good to push this to 5.0.0. What do
you think?

Thanks,
~Isuru

On Wed, Feb 8, 2012 at 10:30 PM, Nuwan Bandara  wrote:

> Hi
>
> On Tue, Feb 7, 2012 at 6:30 AM, Afkham Azeez  wrote:
>
>> For this approach to properly work, we need to have proper package export
>> & import versions. Otherwise, say for example, two different features
>> require different versions of a particular bundle, then these features may
>> not be able to coexist. When upgrading a versions of an orbit dependency,
>> the should be a way to track all its dependant &  change them accordingly
>> to avoid ending up with unnecessary jar duplication.
>>
>
> +1, we need to concentrate on imports and exports more than we are doing
> now. Its a nightmare to find issues when an orbit bundle is updated not
> knowingly.
>
> Regards,
> /Nuwan
>
>
>>  --
>> Afkham Azeez
>> Sent from my phone
>> On Feb 6, 2012 9:27 PM, "Sanjiva Weerawarana"  wrote:
>>
>>> +1 for going ahead (without opinion on timing) and to Amila's suggestion
>>> of making the orbit stuff another TLP.
>>>
>>> I'm +1 for graphite per Senaka for X.
>>>
>>> Sanjiva.
>>>
>>> On Mon, Feb 6, 2012 at 4:03 PM, Dimuthu Leelarathne 
>>> wrote:
>>>
 Hi all,

 +1.

 When installing other features to different products, it should mention
 the carbon core version. Currently, the carbon core is the intersection of
 products, so there is no problem at all. But if we go ahead with minimizing
 carbon-core it can be tricky to handle. Just had an offline chat with
 Sameera, and according to him P2 handles it nicely.

 thanks,
 dimuthu

 On Mon, Feb 6, 2012 at 8:24 AM, Sumedha Rubasinghe wrote:

> +1 for the idea. B4 doing the actual change, how about running through
> different scenarios (like Amila mentioned) - like how we did for branching
> approach. Figuring out problems later would be costly in terms of time.
>
> /sumedha
>
> On Sat, Feb 4, 2012 at 5:14 PM, Sameera Jayasoma wrote:
>
>> *Objective*:
>> Make Carbon core a top level project in WSO2 trunk. At the moment
>> complete Carbon platform code lies under
>> https://svn.wso2.org/repos/wso2/trunk/carbon/. This structure has
>> its own problems.
>>
>> *Motivations*:
>> 1) Carbon core can be treated as a separate product which has its own
>> dependencies, orbit and Carbon core can be released independently of 
>> other
>> Carbon components, products.
>> 2) To ensure that the Carbon based products can depend on a stable,
>> well tested and released version of Carbon instead of the Carbon trunk.
>> 3) This will also ensure the stability of the Carbon based products,
>> because they are no longer depend on the Carbon trunk which might undergo
>> drastic changes time to time.
>>
>> *Execution*:
>> Here is my proposal.
>> 1) We need to create two top level directories for Carbon and for
>> components, features and Carbon based products. Sample structure is shown
>> below.
>>
>> carbon
>> |--dependencies
>> |--orbits
>> |--core (core set of bundles.)
>> |--features (Carbon core features)
>> |--product (Carbon product)
>>
>> X (TODO we need to come up with a name. How about silicon. Dr.
>> Sanjiva once mentioned this name. :) )
>> |--dependencies
>> |--orbits
>> |--components
>> |--features
>> |--products
>>
>> 2) In order to change the existing svn structure to a structure like
>> above, we need to hold all the commits, say for two to three days and
>> restructure the SVN, test properly and release for commits.
>>
>> Please feel free to comment.
>>
>> Thanks,
>> Sameera.
>>
>> --
>> 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
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> /sumedha
> +94 773017743
>
> ___
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --
 Dimuthu Leelarathne
 Technical Lead

 WSO2, Inc. (http://wso2.com)
 email: dimut...@wso2.com


 Lean . Enterprise . Middleware


 ___
 Carbon-dev mailing list
 Carbon-dev@wso2.org
 http://mail.wso2.org/cgi-b

Re: [Carbon-dev] [Stratos-dev] Package import conflict in shindig bundle - Stratos Manager trunk build

[Muhammed Shariq]

Hi,

I tried removing the dashboard feature from Manager but the issue is
Manager uses BAM feature that depends on dashboard feature, hence Shindig
getting bundled in to Manager. However I got this error a couple of weeks
back and managed to sort it out with Lalaji's help, wonder how it
resurfaced ?

On Fri, Feb 10, 2012 at 10:00 AM, Lalaji Sureshika  wrote:

> Hi,
>
> Will check on the issue with a trunk manager build. However keeping
> Shindig inside Stratos Manager pack doesn't useful,since Stratos Manager
> doesn't using dashboard in it  and such that can't we simply remove
> dashboard related features from Stratos Manager,then we can simply avoid
> dependency to Shindig from Stratos Manager?
>
> Thanks;
>
> Best Regards;
>
> On Thu, Feb 9, 2012 at 11:18 PM, Rajika Kumarasiri wrote:
>
>> org.osgi.framework.BundleException: The bundle "shindig_3.0.0.wso2v1
>> [329]" could not be resolved. Reason: Package uses conflict:
>> Import-Package: com.google.common.collect; version="0.9.0.wso2v1"
>>  at
>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1327)
>> at
>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1311)
>>  at
>> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:323)
>> at
>> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299)
>>  at
>> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:291)
>> at
>> org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.startBundles(ConfigApplier.java:307)
>>  at
>> org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.install(ConfigApplier.java:108)
>> at
>> org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:129)
>>  at
>> org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:143)
>> at
>> org.eclipse.equinox.internal.p2.reconciler.dropins.ProfileSynchronizer.applyConfiguration(ProfileSynchronizer.java:781)
>>  at
>> org.eclipse.equinox.internal.p2.reconciler.dropins.ProfileSynchronizer.synchronize(ProfileSynchronizer.java:134)
>> at
>> org.eclipse.equinox.internal.p2.reconciler.dropins.Activator.synchronize(Activator.java:461)
>>  at
>> org.eclipse.equinox.internal.p2.reconciler.dropins.Activator.start(Activator.java:176)
>> at
>> org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
>>  at java.security.AccessController.doPrivileged(Native Method)
>> at
>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
>>  at
>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
>> at
>> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
>>  at
>> org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:389)
>> at
>> org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1130)
>>  at
>> org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
>> at
>> org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
>>  at
>> org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
>> at
>> org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
>>  at
>> org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438)
>> at
>> org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1)
>>  at
>> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
>> at
>> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
>> [2012-02-10 00:11:04,053]  INFO
>> {org.wso2.carbon.core.init.CarbonServerManager} -  Starting Carbon
>> initialization...
>>
>>
>> ___
>> Stratos-dev mailing list
>> stratos-...@wso2.org
>> https://wso2.org/cgi-bin/mailman/listinfo/stratos-dev
>>
>>
>
>
> --
> Lalaji Sureshika
>
> Software Engineer
> WSO2 Inc.
>
>
>
> ___
> Stratos-dev mailing list
> stratos-...@wso2.org
> https://wso2.org/cgi-bin/mailman/listinfo/stratos-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] [Bamboo-Build] WSO2 Carbon Trunk > WSO2 Carbon - Platform Trunk > #189 has FAILED (3 tests failed, no failures were new). Change made by 12 authors.

[Achala Aponso]

Hi,

We are looking into this.

On Fri, Feb 10, 2012 at 6:55 AM, Shammi Jayasinghe  wrote:

> Hi GS Team,
>
>  It is reported a compilation failure in gadgets component[1]. Please have
> a look in to that.
>
>
> http://builder4.us1.wso2.org:/bamboo/browse/WSO2CARBONTUNK-WSO2CARBONPLATFORMTRUNK-JOB1-189/log
>
>
> Thanks
> Shammi
>
> [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/bamboo/Bamboo-3.4/source-repository/build-dir/WSO2CARBONTUNK-WSO2CARBONPLATFORMTRUNK-JOB1/components/gadgets/org.wso2.carbon.gadget.initializer/src/main/java/org/wso2/carbon/gadget/initializer/modules/social/services/GSPersonService.java:[44,7]
> org.wso2.carbon.gadget.initializer.modules.social.services.GSPersonService
> is not abstract and does not override abstract method
> updatePerson(org.apache.shindig.social.opensocial.spi.UserId,org.apache.shindig.social.opensocial.model.Person,org.apache.shindig.auth.SecurityToken)
> in org.apache.shindig.social.opensocial.spi.PersonService
>
> On Fri, Feb 10, 2012 at 3:29 AM, Bamboo  wrote:
>
>>  [image: Failed]  WSO2 Carbon 
>> Trunk› WSO2
>> Carbon - Platform 
>> Trunk›
>> #189
>> failed
>>
>> This build was manually triggered by 
>> BambooBuilder
>> .
>>
>> *3/7599* tests failed.
>>   Failing 
>> Jobs
>> Job
>> Duration Tests[image: Failed]  WSO2 Carbon Trunk Build 
>> Process
>>  (Default
>> Stage)  381 minutes  3 of 7599 failed  
>> Logs|
>> Artifacts
>>  Code
>> Changes
>>   View
>> all 27 code 
>> changes
>> kasunw 
>> commit new wsdl  120294
>> kasunw
>> Updated a wsdl in analyzer stub.  120293
>> nuwan
>> app fix  120292   24 more 
>> changes…
>> Tests
>>   View
>> full test 
>> details
>>3
>> Existing Test Failures   Test Job BAMTestServerManager 
>> startServer
>>   WSO2
>> Carbon Trunk Build 
>> Process
>> GSTestServerManager 
>> startServer
>>   WSO2
>> Carbon Trunk Build 
>> Process
>> MSTestServerManager 
>> startServer
>>   WSO2
>> Carbon Trunk Build 
>> Process
>>  View
>> Online
>> | Add 
>> Comments
>>
>> This message was sent by Atlassian 
>> Bamboo
>> .
>>
>> If you wish to stop receiving these emails edit your user 
>> profileor
>>  notify
>> your 
>> administrator
>> .
>>
>> ___
>> Carbon-dev mailing list
>> Carbon-dev@wso2.org
>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>
>>
>
>
> --
> Best Regards,*
>
> Shammi Jayasinghe*
> 

[Carbon-dev] [Bamboo-Build] WSO2 Carbon Trunk > WSO2 Carbon - Platform Trunk > #190 has FAILED (3 tests failed, no failures were new). Change made by krishantha, rajika and nuwan.

[Bamboo]

---
WSO2 Carbon Trunk > WSO2 Carbon - Platform Trunk > #190 failed.
---
Code has been updated by krishantha, rajika, nuwan.
3/7599 tests failed, no failures were new.

http://builder4.us1.wso2.org:/bamboo/browse/WSO2CARBONTUNK-WSO2CARBONPLATFORMTRUNK-190/


--
Failing Jobs
--
  - WSO2 Carbon Trunk Build Process (Default Stage): 3 of 7599 tests failed.


--
Code Changes
--
nuwan (120296):

>adding uri to request

nuwan (120304):

>adding uri-template

krishantha (120301):

>Removing garbage code



--
Tests
--
Existing Test Failures (3)
   - BAMTestServerManager: Start server
   - GSTestServerManager: Start server
   - MSTestServerManager: Start server

--
This message is automatically generated by Atlassian Bamboo___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] [Stratos-dev] Package import conflict in shindig bundle - Stratos Manager trunk build

[Lalaji Sureshika]

Hi,

Will check on the issue with a trunk manager build. However keeping Shindig
inside Stratos Manager pack doesn't useful,since Stratos Manager doesn't
using dashboard in it  and such that can't we simply remove dashboard
related features from Stratos Manager,then we can simply avoid dependency
to Shindig from Stratos Manager?

Thanks;

Best Regards;

On Thu, Feb 9, 2012 at 11:18 PM, Rajika Kumarasiri  wrote:

> org.osgi.framework.BundleException: The bundle "shindig_3.0.0.wso2v1
> [329]" could not be resolved. Reason: Package uses conflict:
> Import-Package: com.google.common.collect; version="0.9.0.wso2v1"
>  at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1327)
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1311)
>  at
> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:323)
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299)
>  at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:291)
> at
> org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.startBundles(ConfigApplier.java:307)
>  at
> org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.install(ConfigApplier.java:108)
> at
> org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:129)
>  at
> org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:143)
> at
> org.eclipse.equinox.internal.p2.reconciler.dropins.ProfileSynchronizer.applyConfiguration(ProfileSynchronizer.java:781)
>  at
> org.eclipse.equinox.internal.p2.reconciler.dropins.ProfileSynchronizer.synchronize(ProfileSynchronizer.java:134)
> at
> org.eclipse.equinox.internal.p2.reconciler.dropins.Activator.synchronize(Activator.java:461)
>  at
> org.eclipse.equinox.internal.p2.reconciler.dropins.Activator.start(Activator.java:176)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
>  at java.security.AccessController.doPrivileged(Native Method)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
>  at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
> at
> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
>  at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:389)
> at
> org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1130)
>  at
> org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
> at
> org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
>  at
> org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
> at
> org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
>  at
> org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438)
> at
> org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1)
>  at
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at
> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
> [2012-02-10 00:11:04,053]  INFO
> {org.wso2.carbon.core.init.CarbonServerManager} -  Starting Carbon
> initialization...
>
>
> ___
> Stratos-dev mailing list
> stratos-...@wso2.org
> https://wso2.org/cgi-bin/mailman/listinfo/stratos-dev
>
>


-- 
Lalaji Sureshika

Software Engineer
WSO2 Inc.
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] carbon logging not working in trunk

[Pradeep Fernando]

hi,

we didn't work on this space for some time. Want to know whether someone
did ? Looks like a regression.

thanks,
--Pradeep
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] BAM2: Connection reset in AS side

[Chamara Ariyarathne]

On Thu, Feb 9, 2012 at 6:19 PM, Tharindu Mathew  wrote:

> ChamaraA,
>
> You increased the connection param values in BAM, right?

Yes

>
>
> On Thu, Feb 9, 2012 at 5:28 PM, Isuru Suriarachchi  wrote:
>
>> This error has occurred while the BAM publisher trying to publish stats
>> to BAM and not when AS accepting messages. Therefore I think
>> increasing maxThreads and maxConnections wont have any relationship to this
>> particular problem. Should be related to some issue in the connection
>> between AS and BAM.
>>
>> Thanks,
>> ~Isuru
>>
>> On Thu, Feb 9, 2012 at 3:05 PM, Chamara Ariyarathne wrote:
>>
>>> While testing with an AS cluster with two nodes with latest BAM2
>>> statistic publishers, loading with 500 messages with 50 concurrency,
>>>  I noticed following exception from time to time in AS side;
>>>
>>> [2012-02-09 12:01:01,004] ERROR
>>> {org.wso2.carbon.bam.agent.publish.DataPublisher} -  Unable to publish
>>> event to BAM
>>> org.apache.thrift.transport.TTransportException:
>>> java.net.SocketException: Connection reset
>>>  at org.apache.thrift.transport.THttpClient.flush(THttpClient.java:195)
>>> at
>>> org.wso2.carbon.bam.service.ReceiverService$Client.send_publish(ReceiverService.java:94)
>>>  at
>>> org.wso2.carbon.bam.service.ReceiverService$Client.publish(ReceiverService.java:82)
>>> at
>>> org.wso2.carbon.bam.agent.publish.DataPublisher.publishUsingHttp(DataPublisher.java:216)
>>>  at
>>> org.wso2.carbon.bam.agent.publish.DataPublisher.publish(DataPublisher.java:84)
>>> at
>>> org.wso2.carbon.bam.agent.queue.EventWorker.clearActivityDataQueue(EventWorker.java:63)
>>>  at org.wso2.carbon.bam.agent.queue.EventWorker.run(EventWorker.java:44)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>>  at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>> at java.lang.Thread.run(Thread.java:662)
>>> Caused by: java.net.SocketException: Connection reset
>>> at java.net.SocketInputStream.read(SocketInputStream.java:168)
>>> at
>>> com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
>>>  at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
>>> at
>>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:798)
>>>  at
>>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
>>> at
>>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
>>>  at
>>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149)
>>> at
>>> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
>>>  at
>>> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
>>> at
>>> sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:133)
>>>  at org.apache.thrift.transport.THttpClient.flush(THttpClient.java:183)
>>> ... 9 more
>>>
>>> As I found out, the solution for this is to increase the max threads and
>>> max connections in http protocol in mgt-transports file, as
>>> 1 (default 250)
>>> 1 (default undefined;
>>> value of maxThreads is taken)
>>>
>>> The tomcat config document says  in maxConnections:
>>> The maximum number of connections that the server will accept and
>>> process at any given time. When this number has been reached, the server
>>> will not accept any more connections until the number of connections falls
>>> below this value. The operating system may still accept connections based
>>> on the acceptCount setting. Default value varies by connector type. For BIO
>>> the default is the value of maxThreads. For NIO the default is 1. For
>>> APR/native, the default is 8192.
>>> Note that for APR/native on Windows, the configured value will be
>>> reduced to the highest multiple of 1024 that is less than or equal to
>>> maxConnections. This is done for performance reasons.
>>>
>>> *Still even with this configuration, I get the above exception but not
>>> frequently. *
>>>
>>> --
>>> *Chamara Ariyarathne*
>>> Software Engineer - QA;
>>> WSO2 Inc; http://www.wso2.com/.
>>> Mobile; *0772786766*
>>>
>>> ___
>>> Carbon-dev mailing list
>>> Carbon-dev@wso2.org
>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>>
>>>
>>
>>
>> --
>> Isuru Suriarachchi
>> Technical Lead
>> WSO2 Inc. http://wso2.com
>> email : is...@wso2.com
>> blog : http://isurues.wordpress.com/
>>
>> 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] [Bamboo-Build] WSO2 Carbon Trunk > WSO2 Carbon - Platform Trunk > #189 has FAILED (3 tests failed, no failures were new). Change made by 12 authors.

[Shammi Jayasinghe]

Hi GS Team,

 It is reported a compilation failure in gadgets component[1]. Please have
a look in to that.

http://builder4.us1.wso2.org:/bamboo/browse/WSO2CARBONTUNK-WSO2CARBONPLATFORMTRUNK-JOB1-189/log


Thanks
Shammi

[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/bamboo/Bamboo-3.4/source-repository/build-dir/WSO2CARBONTUNK-WSO2CARBONPLATFORMTRUNK-JOB1/components/gadgets/org.wso2.carbon.gadget.initializer/src/main/java/org/wso2/carbon/gadget/initializer/modules/social/services/GSPersonService.java:[44,7]
org.wso2.carbon.gadget.initializer.modules.social.services.GSPersonService
is not abstract and does not override abstract method
updatePerson(org.apache.shindig.social.opensocial.spi.UserId,org.apache.shindig.social.opensocial.model.Person,org.apache.shindig.auth.SecurityToken)
in org.apache.shindig.social.opensocial.spi.PersonService

On Fri, Feb 10, 2012 at 3:29 AM, Bamboo  wrote:

>  [image: Failed]  WSO2 Carbon 
> Trunk› WSO2
> Carbon - Platform 
> Trunk›
> #189
> failed
>
> This build was manually triggered by 
> BambooBuilder
> .
>
> *3/7599* tests failed.
>   Failing 
> Jobs
> Job Duration Tests[image: Failed]  WSO2 Carbon Trunk Build 
> Process
>  (Default
> Stage)  381 minutes  3 of 7599 failed  
> Logs|
> Artifacts
>  Code
> Changes
>   View
> all 27 code 
> changes
> kasunw 
> commit new wsdl  120294
> kasunw
> Updated a wsdl in analyzer stub.  120293
> nuwan
> app fix  120292   24 more 
> changes…
> Tests
>   View
> full test 
> details
>3
> Existing Test Failures  Test Job BAMTestServerManager 
> startServer
>   WSO2
> Carbon Trunk Build 
> Process
> GSTestServerManager 
> startServer
>   WSO2
> Carbon Trunk Build 
> Process
> MSTestServerManager 
> startServer
>   WSO2
> Carbon Trunk Build 
> Process
>  View
> Online
> | Add 
> Comments
>
> This message was sent by Atlassian 
> Bamboo
> .
>
> If you wish to stop receiving these emails edit your user 
> profileor
>  notify
> your 
> administrator
> .
>
> ___
> Carbon-dev mailing list
> Carbon-dev@wso2.org
> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>
>


-- 
Best Regards,*

Shammi Jayasinghe*
Senior Software Engineer; WSO2, Inc.; http://wso2.com,
mobile: +94 71 4493085
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] carbon logging not working in trunk

[Samisa Abeysinghe]

On Fri, Feb 10, 2012 at 12:49 AM, Pradeep Fernando  wrote:

> Hi,
>
> I enabled DEBUG level logging for some of the packages  and it didnt work.
> This behaviour is only visible in trunk.
>

Have we done a change to logging, like update log4j version?


>
> thanks,
> --Pradeep
>
>
>
> ___
> 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

[Carbon-dev] [Bamboo-Build] WSO2 Carbon Trunk > WSO2 Carbon - Platform Trunk > #189 has FAILED (3 tests failed, no failures were new). Change made by 12 authors.

[Bamboo]

---
WSO2 Carbon Trunk > WSO2 Carbon - Platform Trunk > #189 failed.
---
This build was manually triggered by BambooBuilder.
3/7599 tests failed, no failures were new.

http://builder4.us1.wso2.org:/bamboo/browse/WSO2CARBONTUNK-WSO2CARBONPLATFORMTRUNK-189/


--
Failing Jobs
--
  - WSO2 Carbon Trunk Build Process (Default Stage): 3 of 7599 tests failed.


--
Code Changes
--
dilshan (120274):

>Removing readme file

wathsala (120278):

>

wathsala (120279):

>Refactored hadoop.jobtracker



--
Tests
--
Existing Test Failures (3)
   - BAMTestServerManager: Start server
   - GSTestServerManager: Start server
   - MSTestServerManager: Start server

--
This message is automatically generated by Atlassian Bamboo___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

[Carbon-dev] carbon logging not working in trunk

[Pradeep Fernando]

Hi,

I enabled DEBUG level logging for some of the packages  and it didnt work.
This behaviour is only visible in trunk.

thanks,
--Pradeep
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

[Carbon-dev] What is GhoshtRegistry class ?

[Pradeep Fernando]

Hi,

found a class named GhostRegistry under carbon.server. Are we actually
using it ? if yes, Have to find a new home for this class. how about
carbon.utils ?

thanks,
--Pradeep
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

[Carbon-dev] Recursive warn logs from BAM data collector - Stratos Manager trunk build

[Rajika Kumarasiri]

[2012-02-10 00:23:09,711]  WARN
{org.wso2.carbon.bam.core.collector.DataCollector} -  Error occurred while
retrieving the server list for polling data
[2012-02-10 00:24:09,711]  WARN
{org.wso2.carbon.bam.core.collector.DataCollector} -  Error occurred while
retrieving the server list for polling data

[2012-02-10 00:25:09,711]  WARN
{org.wso2.carbon.bam.core.collector.DataCollector} -  Error occurred while
retrieving the server list for polling data
[2012-02-10 00:26:09,711]  WARN
{org.wso2.carbon.bam.core.collector.DataCollector} -  Error occurred while
retrieving the server list for polling data
[2012-02-10 00:27:09,711]  WARN
{org.wso2.carbon.bam.core.collector.DataCollector} -  Error occurred while
retrieving the server list for polling data
[2012-02-10 00:28:09,711]  WARN
{org.wso2.carbon.bam.core.collector.DataCollector} -  Error occurred while
retrieving the server list for polling data
[2012-02-10 00:29:09,712]  WARN
{org.wso2.carbon.bam.core.collector.DataCollector} -  Error occurred while
retrieving the server list for polling data
[2012-02-10 00:30:09,712]  WARN
{org.wso2.carbon.bam.core.collector.DataCollector} -  Error occurred while
retrieving the server list for polling data

If the remote server is unavailable possible options would be either ignore
silently or try in a exponential back off loop rather than warning in a
loop.

Rajika
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

[Carbon-dev] Package import conflict in shindig bundle - Stratos Manager trunk build

[Rajika Kumarasiri]

org.osgi.framework.BundleException: The bundle "shindig_3.0.0.wso2v1 [329]"
could not be resolved. Reason: Package uses conflict: Import-Package:
com.google.common.collect; version="0.9.0.wso2v1"
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1327)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1311)
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:323)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:291)
at
org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.startBundles(ConfigApplier.java:307)
at
org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.install(ConfigApplier.java:108)
at
org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:129)
at
org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:143)
at
org.eclipse.equinox.internal.p2.reconciler.dropins.ProfileSynchronizer.applyConfiguration(ProfileSynchronizer.java:781)
at
org.eclipse.equinox.internal.p2.reconciler.dropins.ProfileSynchronizer.synchronize(ProfileSynchronizer.java:134)
at
org.eclipse.equinox.internal.p2.reconciler.dropins.Activator.synchronize(Activator.java:461)
at
org.eclipse.equinox.internal.p2.reconciler.dropins.Activator.start(Activator.java:176)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
at java.security.AccessController.doPrivileged(Native Method)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:389)
at
org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1130)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1)
at
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at
org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
[2012-02-10 00:11:04,053]  INFO
{org.wso2.carbon.core.init.CarbonServerManager} -  Starting Carbon
initialization...
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

[Carbon-dev] [Bamboo-Build] WSO2 Carbon Trunk > WSO2 Carbon - Platform Trunk > #188 has FAILED (3 tests failed, no failures were new). Change made by 4 authors.

[Bamboo]

---
WSO2 Carbon Trunk > WSO2 Carbon - Platform Trunk > #188 failed (rerun once).
---
This build was manually triggered from the stage: Default Stage by 
BambooBuilder.
3/7599 tests failed, no failures were new.

http://builder4.us1.wso2.org:/bamboo/browse/WSO2CARBONTUNK-WSO2CARBONPLATFORMTRUNK-188/


--
Failing Jobs
--
  - WSO2 Carbon Trunk Build Process (Default Stage): 3 of 7599 tests failed.


--
Code Changes
--
shammi (120258):

>Fixed build failures due to checkSum validation failures by configuring maven 
>to ignore it

shammi (120259):

>Fixed build failures due to checkSum validation failures by configuring maven 
>to ignore it

prabatha (120260):

>fixing UI issues in serviceDetails page of the DS wizard



--
Tests
--
Existing Test Failures (3)
   - BAMTestServerManager: Start server
   - GSTestServerManager: Start server
   - MSTestServerManager: Start server

--
This message is automatically generated by Atlassian Bamboo___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] Problem with Partner Link in Bpel.

[Leslier López Nicot]

Thanks a lot, that was the problem. I install CS in Eclipse Helios and 
it works.



El 08/02/2012 10:02:PM, Harshana Martin escribió:

Hi Leslier, Thilini and Thilina,

On Wed, Feb 8, 2012 at 6:34 PM, Thilina Buddhika > wrote:


I encountered the same issue with Eclipse Indigo. Although I could
pass this step with some workarounds, I hit some blockers with
class cast exceptions, etc.

The only solution was to switch to Eclipse Helios.


We currently build CS against Eclipse Helios repository. Hence there 
can be some inconsistencies if you try to use CS with Eclipse Indigo. 
So the safest solution is to use CS in Eclipse Helios.


Thanks and Regards,
harshana


Thanks,
Thilina


On Thu, Feb 9, 2012 at 1:51 AM, Leslier López Nicot mailto:lni...@uci.cu>> wrote:

Im using Eclipse Indigo, and that is the problem, I press Ok
and it didn´t work, the 'Create PartnerLink Type' window never
appear.

Thanks


El 08/02/2012 11:27:AM, Thilini Ishaka escribió:



On Wed, Feb 8, 2012 at 9:20 PM, Leslier López Nicot
mailto:lni...@uci.cu>> wrote:

Hi all.

I use Carbon Studio 1.0.14. I have a problem in the
design of a process.
When I am setting the partner link for the invoke
activities, I import the wsdl to the bpel project folder,
and in the invoke activity  I select "Create Global
Partner Link". In the dialog box to Choose Partner-Link
type, I add my wsdl, and it will add the portType of the
wsdl to the list, but when I select it and press Ok, It
won´t let me.


When you select, you should be able to see the 'Create
PartnerLink Type' window.
Are you using eclipse Helios? Please state the eclipse
version you use.

Thanks
Thilini


Thanks


Fin a la injusticia, LIBERTAD AHORA A NUESTROS CINCO
COMPATRIOTAS QUE SE ENCUENTRAN INJUSTAMENTE EN PRISIONES
DE LOS EEUU!
http://www.antiterroristas.cu
http://justiciaparaloscinco.wordpress.com
___
Carbon-dev mailing list
Carbon-dev@wso2.org 
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev




-- 
Regards


Thilini Ishaka
WSO2 Inc



___
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




-- 
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




--
Harshana Martin
Software Engineer
WSO2 Inc.
Web:http://wso2.com
http://wso2.org

Mobile: +94 716062650
Blog: http://harshana05.blogspot.com
Profile: https://www.google.com/profiles/harshana05
Twitter: http://twitter.com/harshana05



___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev





Fin a la injusticia, LIBERTAD AHORA A NUESTROS CINCO COMPATRIOTAS QUE SE 
ENCUENTRAN INJUSTAMENTE EN PRISIONES DE LOS EEUU!
http://www.antiterroristas.cu
http://justiciaparaloscinco.wordpress.com___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] Performance numbers of Agent Component

[Tharindu Mathew]

Hi Srinath,

I wasn't thinking about doing multiple servers now itself. That would be
impractical. We can just start by increasing the number of clients. Just
using a thread pool and increasing the pool size would do...

On Thu, Feb 9, 2012 at 2:32 PM, Srinath Perera  wrote:

> Hi Tharindu,
>
> Agreed .. lets plan to find some HW and do this when we can (will need
> at least 5 servers) .. I just want us not to be blocked on this.
>
> --Srinath
>
> On Thu, Feb 9, 2012 at 2:01 PM, Tharindu Mathew  wrote:
> > Not testing for load at start lead to problems earlier.
> >
> > Testing for 20 clients and 10 M messages is not the same for testing for
> 500
> > clients and 10 M messages. At this scale only, connection pooling,
> caching
> > and all of this matters. This is of course, many clients to one server, a
> > basic test that can be done easily.
> >
> > Anyway, we can post pone the testing to when we integrate BAM or CEP, but
> > please be aware of the implications. This was a situation where earlier
> BAM
> > was not scaling at all.
> >
> >
> > On Thu, Feb 9, 2012 at 1:43 PM, Amila Suriarachchi 
> wrote:
> >>
> >>
> >>
> >> On Thu, Feb 9, 2012 at 12:36 PM, Srinath Perera 
> wrote:
> >>>
> >>> Hi Suho,
> >>>
> >>> IMHO this covers about 90% of our usecases .. I think we should move on
> >>
> >>
> >> we do not required to do an performance study. Since anyway we don't
> have
> >> proper CEP or BAM service to consume events.
> >>
> >> But need to test for once client many server scenario to test for
> >> stability.
> >>
> >> thanks,
> >> Amila.
> >>
> >>>
> >>>
> >>> I do not mind doing a larger perf study later .. ..
> >>>
> >>> but getting the server finished from siddhi side and releasing it, CEP
> >>> perrf numbers,  and integrating this with BAM are more urget IMHO
> >>>
> >>> --Srinath
> >>>
> >>> On Thu, Feb 9, 2012 at 12:29 PM, Suhothayan Sriskandarajah
> >>>  wrote:
> >>> >
> >>> >
> >>> > On Thu, Feb 9, 2012 at 12:00 PM, Amila Suriarachchi 
> >>> > wrote:
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Thu, Feb 9, 2012 at 11:47 AM, Tharindu Mathew  >
> >>> >> wrote:
> >>> >>>
> >>> >>> Suho,
> >>> >>>
> >>> >>> This does not measure the ability to handle load. Basically, what
> we
> >>> >>> did
> >>> >>> for load testing earlier was send around 2M messages, with
> >>> >>> concurrency as
> >>> >>> high increasing from 100 - 1500 clients.
> >>> >>
> >>> >>
> >>> >> How many back end servers and client programs used for that?
> >>> >>
> >>> >>>
> >>> >>>
> >>> >>> Your test is a measure of being able to consistently handle a
> stream
> >>> >>> of
> >>> >>> messages, which IMO, maybe important but is less interesting when
> >>> >>> handling
> >>> >>> load.
> >>> >>
> >>> >>
> >>> >> This test has measured the one client one server. yes it can be
> >>> >> improved
> >>> >> to one client to many servers and many clients to many servers.
> >>> >>
> >>> >
> >>> > This test also covers sending messages from many clients (2,5,10 &
> 20)
> >>> > to
> >>> > one server.
> >>> > Yes it could be improved to many clients to many server.
> >>> > If there are any specific requirements please suggest me a scenario,
> >>> > then I
> >>> > can do the testing and present the findings.
> >>> >
> >>> > Thanks
> >>> > Suho
> >>> >
> >>> >> But this test gives the through put this can handle one client to
> >>> >> server.
> >>> >> For one client scenario whether you add messages with one thread or
> >>> >> many
> >>> >> threads does not effect the performance if there are enough messages
> >>> >> to
> >>> >> send.
> >>> >>
> >>> >> thanks,
> >>> >> Amila.
> >>> >>
> >>> >>>
> >>> >>> To truly test the ability to handle loads we need to do a
> distributed
> >>> >>> load test with an extremely high number of clients and see the
> >>> >>> breaking
> >>> >>> point. Earlier, we could not find such a point with a single
> machine.
> >>> >>>
> >>> >>>
> >>> >>> On Thu, Feb 9, 2012 at 11:31 AM, Suhothayan Sriskandarajah
> >>> >>>  wrote:
> >>> 
> >>> 
> >>> 
> >>>  On Thu, Feb 9, 2012 at 11:24 AM, Amila Suriarachchi <
> am...@wso2.com>
> >>>  wrote:
> >>> >
> >>> > through put should not depend on the number of messages send. You
> >>> > need
> >>> > to send sufficient number of messages after server warmed up.
> >>> >
> >>> > Can you please first send around 2M messages and take the numbers
> >>> > for
> >>> > next 10M messages.
> >>> >
> >>> > And also try to test with number of back end servers.
> >>> >
> >>> 
> >>>  Yes, I'll work on this
> >>> 
> >>>  Thanks
> >>>  Suho
> >>> 
> >>> >
> >>> > thanks,
> >>> > Amila.
> >>> >
> >>> >
> >>> > On Wed, Feb 8, 2012 at 9:25 PM, Suhothayan Sriskandarajah
> >>> >  wrote:
> >>> >>
> >>> >>
> >>> >> According to the decisions made at the architecture mailing list
> >>> >> on
> >>> >> the subject "Serializing generic Siddhi events using Thrift",
> >>> >> I did some

Re: [Carbon-dev] BAM2: Connection reset in AS side

[Tharindu Mathew]

ChamaraA,

You increased the connection param values in BAM, right?

On Thu, Feb 9, 2012 at 5:28 PM, Isuru Suriarachchi  wrote:

> This error has occurred while the BAM publisher trying to publish stats to
> BAM and not when AS accepting messages. Therefore I think
> increasing maxThreads and maxConnections wont have any relationship to this
> particular problem. Should be related to some issue in the connection
> between AS and BAM.
>
> Thanks,
> ~Isuru
>
> On Thu, Feb 9, 2012 at 3:05 PM, Chamara Ariyarathne wrote:
>
>> While testing with an AS cluster with two nodes with latest BAM2
>> statistic publishers, loading with 500 messages with 50 concurrency,
>>  I noticed following exception from time to time in AS side;
>>
>> [2012-02-09 12:01:01,004] ERROR
>> {org.wso2.carbon.bam.agent.publish.DataPublisher} -  Unable to publish
>> event to BAM
>> org.apache.thrift.transport.TTransportException:
>> java.net.SocketException: Connection reset
>>  at org.apache.thrift.transport.THttpClient.flush(THttpClient.java:195)
>> at
>> org.wso2.carbon.bam.service.ReceiverService$Client.send_publish(ReceiverService.java:94)
>>  at
>> org.wso2.carbon.bam.service.ReceiverService$Client.publish(ReceiverService.java:82)
>> at
>> org.wso2.carbon.bam.agent.publish.DataPublisher.publishUsingHttp(DataPublisher.java:216)
>>  at
>> org.wso2.carbon.bam.agent.publish.DataPublisher.publish(DataPublisher.java:84)
>> at
>> org.wso2.carbon.bam.agent.queue.EventWorker.clearActivityDataQueue(EventWorker.java:63)
>>  at org.wso2.carbon.bam.agent.queue.EventWorker.run(EventWorker.java:44)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>  at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>> at java.lang.Thread.run(Thread.java:662)
>> Caused by: java.net.SocketException: Connection reset
>> at java.net.SocketInputStream.read(SocketInputStream.java:168)
>> at
>> com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
>>  at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
>> at
>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:798)
>>  at
>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
>> at
>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
>>  at
>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149)
>> at
>> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
>>  at
>> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
>> at
>> sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:133)
>>  at org.apache.thrift.transport.THttpClient.flush(THttpClient.java:183)
>> ... 9 more
>>
>> As I found out, the solution for this is to increase the max threads and
>> max connections in http protocol in mgt-transports file, as
>> 1 (default 250)
>> 1 (default undefined;
>> value of maxThreads is taken)
>>
>> The tomcat config document says  in maxConnections:
>> The maximum number of connections that the server will accept and process
>> at any given time. When this number has been reached, the server will not
>> accept any more connections until the number of connections falls below
>> this value. The operating system may still accept connections based on the
>> acceptCount setting. Default value varies by connector type. For BIO the
>> default is the value of maxThreads. For NIO the default is 1. For
>> APR/native, the default is 8192.
>> Note that for APR/native on Windows, the configured value will be reduced
>> to the highest multiple of 1024 that is less than or equal to
>> maxConnections. This is done for performance reasons.
>>
>> *Still even with this configuration, I get the above exception but not
>> frequently. *
>>
>> --
>> *Chamara Ariyarathne*
>> Software Engineer - QA;
>> WSO2 Inc; http://www.wso2.com/.
>> Mobile; *0772786766*
>>
>> ___
>> Carbon-dev mailing list
>> Carbon-dev@wso2.org
>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>
>>
>
>
> --
> Isuru Suriarachchi
> Technical Lead
> WSO2 Inc. http://wso2.com
> email : is...@wso2.com
> blog : http://isurues.wordpress.com/
>
> 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] Generic Server add issue

[Tharindu Mathew]

Hi Chris,

It is difficult to integrate BAM 1.3.2 with third party products, which is
one of the reasons why we came up with BAM 2.0.

http://dist.wso2.org/downloads/bam/wso2bam-2.0.0-ALPHA.zip

Try out the samples and give it a spin. Although, documentation is not
readily available is as of yet, we would love to hear your feedback.
There's also a webinar today at 9 am PDT. Do join in.

http://wso2.org/library/webinars/2012/02/kpi-definition-bam

On Thu, Feb 9, 2012 at 5:44 PM, Matthies, Chris C [HDS] <
chris.matthi...@hdsupply.com> wrote:

> I am evaluating BAM 1.3.2. I want to integrate a third party product so I
> am trying to add a Generic server. The Add Server tries to validate the
> server URL entered into the UI. This fails since there is NO connection to
> the third party product. Is there a work around or am I doing something
> wrong? Once I have the server added I can post events using that URL in my
> XML? To see the data I must create a custom dashboard?
>
> ** **
>
> Environment:
>
> ** **
>
> *WSO2 Business Activity Monitor Home *
>
> Welcome to the WSO2 Business Activity Monitor Management Console 
>
>  
>
> *Server*
>
> Host
>
> 11.128.8.177 
>
> Server URL 
>
> https://11.128.8.177:9443/services/ 
>
> Server Start Time
>
> 2012-02-08 11:20:28 
>
> System Up Time
>
> 0 day(s)  19 hr(s)  52 min(s)  36 sec(s)  
>
> Version
>
> 1.3.2 
>
> Repository Location 
>
> file:/C:/ccm/BAM/WSO2BA~1.2/bin/../repository/deployment/server/ 
>
>  
>
> *Operating System*
>
> OS Name 
>
> Windows 7 
>
> OS Version 
>
> 6.1 
>
>  
>
> *Operating System User*
>
> Country 
>
> US 
>
> Home 
>
> C:\Users\cm59 
>
> Name
>
> cm59 
>
> Timezone
>
> America/New_York 
>
>  
>
> *Java VM*
>
> Java Home 
>
> C:\Program Files\Java\jdk1.6.0_30\jre 
>
> Java Runtime Name 
>
> Java(TM) SE Runtime Environment 
>
> Java Version 
>
> 1.6.0_30 
>
> Java Vendor 
>
> Sun Microsystems Inc. 
>
> Java VM Version 
>
> 20.5-b03 
>
>  
>
> *Registry*
>
> Type 
>
> embedded 
>
> DBMS 
>
> H2 
>
> DBMS Version 
>
> 1.2.140 (2010-07-25) 
>
> DBMS Driver 
>
> H2 JDBC Driver 
>
> DBMS Driver Version 
>
> 1.2.140 (2010-07-25) 
>
> DBMS URL 
>
> jdbc:h2:repository/database/WSO2CARBON_DB 
>
> ** **
>
> ** **
>
> *Chris Matthies*
>
> Sr. Enterprise Architect, IT-Platform Application and Development
>
> HD Supply
>
> phone: 407-254-1704
>
> Email: chris.matthi...@hdsupply.com
>
> *One Team, Driving Customer Success and Value Creation *
>
> This message is for intended addressee(s) only and may contain
> confidential, proprietary or privileged information, exempt from
> disclosure, and subject to terms at: http://www.hdsupply.com/email/.
>
> ** **
>
> ** **
>
> ___
> 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

[Carbon-dev] Context mapping to Stratos Applications

[Reka Thirunavukkarasu]

Hi

I'm working on custom context mapping for web-apps in Stratos application
server. In order to handle it, i want to redirect the user given url to the
actual (current) url without user knowing the redirection. So
RequestDispatcher is the possible one that i could use here. But when i
used RequestDispatcher, it is looping several times and finally ends up
with the login page.

I found CarbonSecuredHttpContext in org.wso2.carbon.ui is doing some
redirection for every secured request where after several looping only, one
url is redirected in the browser. When i send the requested URL without any
context (https://test.stratosapps.com:9446/), it is redirecting to
"response.sendRedirect("carbon")" in CarbonSecuredHttpContext . So that
login page finally ends up. When i login as a super tenant, i accessed
http://example.stratosapps.com:9763 through http, same issue happens there
as well.

Can somebody suggest me how could i possibly do a redirection here for a
url like https://example.stratosapps.com:9446/ to redirect
https://example.stratosapps.com:9446/t/testdev.com/webapps/example in case
"example" is the web-app?

FYI=>I have done the domain mapping in /etc/hosts.
The relervant code is:

RequestDispatcher requestDispatcher = request.getRequestDispatcher("/t/
testdev.com/webapps/example");
requestDispatcher.forward(request,response);


Regards,
Reka
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

[Carbon-dev] Generic Server add issue

[Matthies, Chris C [HDS]]

I am evaluating BAM 1.3.2. I want to integrate a third party product so I am 
trying to add a Generic server. The Add Server tries to validate the server URL 
entered into the UI. This fails since there is NO connection to the third party 
product. Is there a work around or am I doing something wrong? Once I have the 
server added I can post events using that URL in my XML? To see the data I must 
create a custom dashboard?

Environment:

WSO2 Business Activity Monitor Home
Welcome to the WSO2 Business Activity Monitor Management Console

Server

Host

11.128.8.177

Server URL

https://11.128.8.177:9443/services/

Server Start Time

2012-02-08 11:20:28

System Up Time

0 day(s)  19 hr(s)  52 min(s)  36 sec(s)

Version

1.3.2

Repository Location

file:/C:/ccm/BAM/WSO2BA~1.2/bin/../repository/deployment/server/


Operating System

OS Name

Windows 7

OS Version

6.1


Operating System User

Country

US

Home

C:\Users\cm59

Name

cm59

Timezone

America/New_York


Java VM

Java Home

C:\Program Files\Java\jdk1.6.0_30\jre

Java Runtime Name

Java(TM) SE Runtime Environment

Java Version

1.6.0_30

Java Vendor

Sun Microsystems Inc.

Java VM Version

20.5-b03


Registry

Type

embedded

DBMS

H2

DBMS Version

1.2.140 (2010-07-25)

DBMS Driver

H2 JDBC Driver

DBMS Driver Version

1.2.140 (2010-07-25)

DBMS URL

jdbc:h2:repository/database/WSO2CARBON_DB






Chris Matthies
Sr. Enterprise Architect, IT-Platform Application and Development
HD Supply
phone: 407-254-1704
Email: chris.matthi...@hdsupply.com
One Team, Driving Customer Success and Value Creation
This message is for intended addressee(s) only and may contain confidential, 
proprietary or privileged information, exempt from disclosure, and subject to 
terms at: http://www.hdsupply.com/email/.


___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] BAM2: Connection reset in AS side

[Isuru Suriarachchi]

This error has occurred while the BAM publisher trying to publish stats to
BAM and not when AS accepting messages. Therefore I think increasing maxThreads
and maxConnections wont have any relationship to this particular problem.
Should be related to some issue in the connection between AS and BAM.

Thanks,
~Isuru

On Thu, Feb 9, 2012 at 3:05 PM, Chamara Ariyarathne wrote:

> While testing with an AS cluster with two nodes with latest BAM2 statistic
> publishers, loading with 500 messages with 50 concurrency,
>  I noticed following exception from time to time in AS side;
>
> [2012-02-09 12:01:01,004] ERROR
> {org.wso2.carbon.bam.agent.publish.DataPublisher} -  Unable to publish
> event to BAM
> org.apache.thrift.transport.TTransportException: java.net.SocketException:
> Connection reset
>  at org.apache.thrift.transport.THttpClient.flush(THttpClient.java:195)
> at
> org.wso2.carbon.bam.service.ReceiverService$Client.send_publish(ReceiverService.java:94)
>  at
> org.wso2.carbon.bam.service.ReceiverService$Client.publish(ReceiverService.java:82)
> at
> org.wso2.carbon.bam.agent.publish.DataPublisher.publishUsingHttp(DataPublisher.java:216)
>  at
> org.wso2.carbon.bam.agent.publish.DataPublisher.publish(DataPublisher.java:84)
> at
> org.wso2.carbon.bam.agent.queue.EventWorker.clearActivityDataQueue(EventWorker.java:63)
>  at org.wso2.carbon.bam.agent.queue.EventWorker.run(EventWorker.java:44)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>  at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:168)
> at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
>  at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:798)
>  at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
>  at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149)
> at
> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
>  at
> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
> at
> sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:133)
>  at org.apache.thrift.transport.THttpClient.flush(THttpClient.java:183)
> ... 9 more
>
> As I found out, the solution for this is to increase the max threads and
> max connections in http protocol in mgt-transports file, as
> 1 (default 250)
> 1 (default undefined;
> value of maxThreads is taken)
>
> The tomcat config document says  in maxConnections:
> The maximum number of connections that the server will accept and process
> at any given time. When this number has been reached, the server will not
> accept any more connections until the number of connections falls below
> this value. The operating system may still accept connections based on the
> acceptCount setting. Default value varies by connector type. For BIO the
> default is the value of maxThreads. For NIO the default is 1. For
> APR/native, the default is 8192.
> Note that for APR/native on Windows, the configured value will be reduced
> to the highest multiple of 1024 that is less than or equal to
> maxConnections. This is done for performance reasons.
>
> *Still even with this configuration, I get the above exception but not
> frequently. *
>
> --
> *Chamara Ariyarathne*
> Software Engineer - QA;
> WSO2 Inc; http://www.wso2.com/.
> Mobile; *0772786766*
>
> ___
> Carbon-dev mailing list
> Carbon-dev@wso2.org
> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>
>


-- 
Isuru Suriarachchi
Technical Lead
WSO2 Inc. http://wso2.com
email : is...@wso2.com
blog : http://isurues.wordpress.com/

lean . enterprise . middleware
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] Build Failure in core

[Maninda Edirisooriya]

@Pradeep

Thanks. It worked.

On Thu, Feb 9, 2012 at 1:54 PM, Pradeep Fernando  wrote:

> you have to build,
> org.eclipse.equinox.p2.touchpoint.eclipse:jar:2.1.0.v20110511-wso2v1 module
> found under /dependencies
>
> --Pradeep
>
> ___
> 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] LB server start-up hangs

[Nirmal Fernando]

On Thu, Feb 9, 2012 at 3:09 PM, Nirmal Fernando  wrote:

> Hi Azeez,
>
> On Thu, Feb 9, 2012 at 2:57 PM, Afkham Azeez  wrote:
>
>> Nirmal,
>> On a side note, please add an integration test to LB which will test that
>> it starts up successfully.
>
>
> Will do!
>
> Not sure whether this is important, but when I debug, I could see that the
> first module that added to the pendingItemMap is
> org.wso2.carbon.security.mgt-4.0.0-SNAPSHOT !
>

Also, at the time of modules been added to the pendingItemMap I can see
following bundle [1] which is imported by most of the 'pending' bundles, is
still at starting state.

[1]
idState   Bundle
0STARTINGorg.eclipse.osgi_3.7.0.v20110613
Fragments=1, 2, 3




>
>>
>>
>> On Thu, Feb 9, 2012 at 2:40 PM, Pradeep Fernando wrote:
>>
>>> No. I'm working on a scratch.
>>>
>>> thanks,
>>> --Pradeep
>>>
>>
>>
>>
>> --
>> *Afkham Azeez*
>> Director of Architecture; WSO2, Inc.; http://wso2.com
>> Member; Apache Software Foundation; http://www.apache.org/
>> * **
>> email: **az...@wso2.com* * cell: +94 77 3320919
>> blog: **http://blog.afkham.org* *
>> twitter: **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
>>
>>
>
>
> --
>
> Thanks & regards,
> Nirmal
>
> Software Engineer- Platform Technologies Team, WSO2 Inc.
> Mobile: +94715779733
> Blog: http://nirmalfdo.blogspot.com/
>



-- 

Thanks & regards,
Nirmal

Software Engineer- Platform Technologies Team, WSO2 Inc.
Mobile: +94715779733
Blog: http://nirmalfdo.blogspot.com/
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] LB server start-up hangs

[Nirmal Fernando]

Hi Azeez,

On Thu, Feb 9, 2012 at 2:57 PM, Afkham Azeez  wrote:

> Nirmal,
> On a side note, please add an integration test to LB which will test that
> it starts up successfully.


Will do!

Not sure whether this is important, but when I debug, I could see that the
first module that added to the pendingItemMap is
org.wso2.carbon.security.mgt-4.0.0-SNAPSHOT !


>
>
> On Thu, Feb 9, 2012 at 2:40 PM, Pradeep Fernando  wrote:
>
>> No. I'm working on a scratch.
>>
>> thanks,
>> --Pradeep
>>
>
>
>
> --
> *Afkham Azeez*
> Director of Architecture; WSO2, Inc.; http://wso2.com
> Member; Apache Software Foundation; http://www.apache.org/
> * **
> email: **az...@wso2.com* * cell: +94 77 3320919
> blog: **http://blog.afkham.org* *
> twitter: **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
>
>


-- 

Thanks & regards,
Nirmal

Software Engineer- Platform Technologies Team, WSO2 Inc.
Mobile: +94715779733
Blog: http://nirmalfdo.blogspot.com/
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

[Carbon-dev] BAM2: Connection reset in AS side

[Chamara Ariyarathne]

While testing with an AS cluster with two nodes with latest BAM2 statistic
publishers, loading with 500 messages with 50 concurrency,
 I noticed following exception from time to time in AS side;

[2012-02-09 12:01:01,004] ERROR
{org.wso2.carbon.bam.agent.publish.DataPublisher} -  Unable to publish
event to BAM
org.apache.thrift.transport.TTransportException: java.net.SocketException:
Connection reset
 at org.apache.thrift.transport.THttpClient.flush(THttpClient.java:195)
at
org.wso2.carbon.bam.service.ReceiverService$Client.send_publish(ReceiverService.java:94)
 at
org.wso2.carbon.bam.service.ReceiverService$Client.publish(ReceiverService.java:82)
at
org.wso2.carbon.bam.agent.publish.DataPublisher.publishUsingHttp(DataPublisher.java:216)
 at
org.wso2.carbon.bam.agent.publish.DataPublisher.publish(DataPublisher.java:84)
at
org.wso2.carbon.bam.agent.queue.EventWorker.clearActivityDataQueue(EventWorker.java:63)
 at org.wso2.carbon.bam.agent.queue.EventWorker.run(EventWorker.java:44)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
 at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:798)
 at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
 at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
 at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:133)
 at org.apache.thrift.transport.THttpClient.flush(THttpClient.java:183)
... 9 more

As I found out, the solution for this is to increase the max threads and
max connections in http protocol in mgt-transports file, as
1 (default 250)
1 (default undefined;
value of maxThreads is taken)

The tomcat config document says  in maxConnections:
The maximum number of connections that the server will accept and process
at any given time. When this number has been reached, the server will not
accept any more connections until the number of connections falls below
this value. The operating system may still accept connections based on the
acceptCount setting. Default value varies by connector type. For BIO the
default is the value of maxThreads. For NIO the default is 1. For
APR/native, the default is 8192.
Note that for APR/native on Windows, the configured value will be reduced
to the highest multiple of 1024 that is less than or equal to
maxConnections. This is done for performance reasons.

*Still even with this configuration, I get the above exception but not
frequently. *

-- 
*Chamara Ariyarathne*
Software Engineer - QA;
WSO2 Inc; http://www.wso2.com/.
Mobile; *0772786766*
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] Suho += WSO2 committers

[Suhothayan Sriskandarajah]

On Thu, Feb 9, 2012 at 2:48 PM, Amila Suriarachchi  wrote:

> hi Suho,
>
> Congratulations and welcome aboard as a WSO2 Committer. Thank you for your
> contributions!.
>
> Thank you,
Its a great privilege for me :)

Thanks,
Suho

 thanks,
> Amila.
>
> --
> *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
>
>


-- 
*S. Suhothayan
*
Software Engineer,
Data Technologies Team,
 *WSO2, Inc. **http://wso2.com
 *
*lean.enterprise.middleware.*

*email: **s...@wso2.com* * cell: (+94) 779 756 757
blog: **http://suhothayan.blogspot.com/* *
twitter: **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] LB server start-up hangs

[Afkham Azeez]

Nirmal,
On a side note, please add an integration test to LB which will test that
it starts up successfully.

On Thu, Feb 9, 2012 at 2:40 PM, Pradeep Fernando  wrote:

> No. I'm working on a scratch.
>
> thanks,
> --Pradeep
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* **
email: **az...@wso2.com* * cell: +94 77 3320919
blog: **http://blog.afkham.org* *
twitter: **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] Suho += WSO2 committers

[Amila Suriarachchi]

hi Suho,

Congratulations and welcome aboard as a WSO2 Committer. Thank you for your
contributions!.

thanks,
Amila.

-- 
*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] LB server start-up hangs

[Pradeep Fernando]

No. I'm working on a scratch.

thanks,
--Pradeep
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] LB server start-up hangs

[Afkham Azeez]

Most of the bundles which re in resolved state startup without any issues
when manually started. What could be the problem? Was any change recently
made to the Equinox version?

On Thu, Feb 9, 2012 at 2:34 PM, Pradeep Fernando  wrote:

> Hi,
>
> On Thu, Feb 9, 2012 at 2:21 PM, Afkham Azeez  wrote:
>
>> org.eclipse.equinox.launcher.gtk.linux.x86_1.1.100.v20110505 is in
>> INSTALLED state. Any idea?
>
>
>
> nothing wrong with that. we have to give architecture specific details
> while initial provisioning. But it does not affect us since we are not
> using architecture/OS specific code. This is the expected behavior.
>
> thanks,
> --Pradeep
>
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* **
email: **az...@wso2.com* * cell: +94 77 3320919
blog: **http://blog.afkham.org* *
twitter: **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] LB server start-up hangs

[Pradeep Fernando]

Hi,

On Thu, Feb 9, 2012 at 2:21 PM, Afkham Azeez  wrote:

> org.eclipse.equinox.launcher.gtk.linux.x86_1.1.100.v20110505 is in
> INSTALLED state. Any idea?



nothing wrong with that. we have to give architecture specific details
while initial provisioning. But it does not affect us since we are not
using architecture/OS specific code. This is the expected behavior.

thanks,
--Pradeep
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] Performance numbers of Agent Component

[Srinath Perera]

Hi Tharindu,

Agreed .. lets plan to find some HW and do this when we can (will need
at least 5 servers) .. I just want us not to be blocked on this.

--Srinath

On Thu, Feb 9, 2012 at 2:01 PM, Tharindu Mathew  wrote:
> Not testing for load at start lead to problems earlier.
>
> Testing for 20 clients and 10 M messages is not the same for testing for 500
> clients and 10 M messages. At this scale only, connection pooling, caching
> and all of this matters. This is of course, many clients to one server, a
> basic test that can be done easily.
>
> Anyway, we can post pone the testing to when we integrate BAM or CEP, but
> please be aware of the implications. This was a situation where earlier BAM
> was not scaling at all.
>
>
> On Thu, Feb 9, 2012 at 1:43 PM, Amila Suriarachchi  wrote:
>>
>>
>>
>> On Thu, Feb 9, 2012 at 12:36 PM, Srinath Perera  wrote:
>>>
>>> Hi Suho,
>>>
>>> IMHO this covers about 90% of our usecases .. I think we should move on
>>
>>
>> we do not required to do an performance study. Since anyway we don't have
>> proper CEP or BAM service to consume events.
>>
>> But need to test for once client many server scenario to test for
>> stability.
>>
>> thanks,
>> Amila.
>>
>>>
>>>
>>> I do not mind doing a larger perf study later .. ..
>>>
>>> but getting the server finished from siddhi side and releasing it, CEP
>>> perrf numbers,  and integrating this with BAM are more urget IMHO
>>>
>>> --Srinath
>>>
>>> On Thu, Feb 9, 2012 at 12:29 PM, Suhothayan Sriskandarajah
>>>  wrote:
>>> >
>>> >
>>> > On Thu, Feb 9, 2012 at 12:00 PM, Amila Suriarachchi 
>>> > wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Thu, Feb 9, 2012 at 11:47 AM, Tharindu Mathew 
>>> >> wrote:
>>> >>>
>>> >>> Suho,
>>> >>>
>>> >>> This does not measure the ability to handle load. Basically, what we
>>> >>> did
>>> >>> for load testing earlier was send around 2M messages, with
>>> >>> concurrency as
>>> >>> high increasing from 100 - 1500 clients.
>>> >>
>>> >>
>>> >> How many back end servers and client programs used for that?
>>> >>
>>> >>>
>>> >>>
>>> >>> Your test is a measure of being able to consistently handle a stream
>>> >>> of
>>> >>> messages, which IMO, maybe important but is less interesting when
>>> >>> handling
>>> >>> load.
>>> >>
>>> >>
>>> >> This test has measured the one client one server. yes it can be
>>> >> improved
>>> >> to one client to many servers and many clients to many servers.
>>> >>
>>> >
>>> > This test also covers sending messages from many clients (2,5,10 & 20)
>>> > to
>>> > one server.
>>> > Yes it could be improved to many clients to many server.
>>> > If there are any specific requirements please suggest me a scenario,
>>> > then I
>>> > can do the testing and present the findings.
>>> >
>>> > Thanks
>>> > Suho
>>> >
>>> >> But this test gives the through put this can handle one client to
>>> >> server.
>>> >> For one client scenario whether you add messages with one thread or
>>> >> many
>>> >> threads does not effect the performance if there are enough messages
>>> >> to
>>> >> send.
>>> >>
>>> >> thanks,
>>> >> Amila.
>>> >>
>>> >>>
>>> >>> To truly test the ability to handle loads we need to do a distributed
>>> >>> load test with an extremely high number of clients and see the
>>> >>> breaking
>>> >>> point. Earlier, we could not find such a point with a single machine.
>>> >>>
>>> >>>
>>> >>> On Thu, Feb 9, 2012 at 11:31 AM, Suhothayan Sriskandarajah
>>> >>>  wrote:
>>> 
>>> 
>>> 
>>>  On Thu, Feb 9, 2012 at 11:24 AM, Amila Suriarachchi 
>>>  wrote:
>>> >
>>> > through put should not depend on the number of messages send. You
>>> > need
>>> > to send sufficient number of messages after server warmed up.
>>> >
>>> > Can you please first send around 2M messages and take the numbers
>>> > for
>>> > next 10M messages.
>>> >
>>> > And also try to test with number of back end servers.
>>> >
>>> 
>>>  Yes, I'll work on this
>>> 
>>>  Thanks
>>>  Suho
>>> 
>>> >
>>> > thanks,
>>> > Amila.
>>> >
>>> >
>>> > On Wed, Feb 8, 2012 at 9:25 PM, Suhothayan Sriskandarajah
>>> >  wrote:
>>> >>
>>> >>
>>> >> According to the decisions made at the architecture mailing list
>>> >> on
>>> >> the subject "Serializing generic Siddhi events using Thrift",
>>> >> I did some improvements to the code base of Agent component and
>>> >> did a
>>> >> performance testing.
>>> >>
>>> >> Here I did the tests by sending total of 1 million and 10 million
>>> >> events using for loop,
>>> >> in both cases I have sent events using 1,2,5,10 & 20 Clients.
>>> >>
>>> >> The results are as follows
>>> >>
>>> >>       1M  10M
>>> >> 1      245118.1    269328.8
>>> >> 2      517509.1    739699.7
>>> >> 5      585823.1    923986.7
>>> >> 10    345582.3    418865.7
>>> >> 20    285008.6    368881.2
>>> >>
>>> >> I have 

Re: [Carbon-dev] Reminder: Supporting admin service authentication via OAuth and WS-... @ Thu Feb 9 11am - 12pm (ami...@wso2.com)

[Amila Jayasekara]

Discussion notes


General
---
Review existing authenticator framework generalize authenticator framework
- Should add functionalities such as service level authenticators

UI to list existing admin services. Users should be able do actions such as,
- Assigning authenticators
- Attaching security policies etc ...

OAuth Support
-
This should be supported by writing a new authenticator.
Consumer keys and consumer secrets will be generated

Basic Auth
-
Again this is supported through an authenticator

WS-Security
--
This is also handled through an authenticator. Security policies are
attached through the admin service managing UI.

Work Items
==
1. Schedule a review for authenticator review
2. Incorporate improvements outcome from the review
3. Implement "Basic Auth" authenticator
4. Implement "OAuth" authenticator
5. Implement admin service UI
6. Implement "WS-Security" authenticator

On Thu, Feb 9, 2012 at 10:50 AM, Google Calendar <
calendar-notificat...@google.com> wrote:

> more details 
> »
> Supporting admin service authentication via OAuth and WS-Security
> Objective of this session is to gather requirements for following task.
> - "Re-do all admin services in Carbon properly (Shared Schema, JAX-WS,
> Proper Security=get rid of login() method and to it with right security
> things like OAuth, WS-Security ..)"
> *When*
> Thu Feb 9 11am – 12pm Colombo
> *Where*
> LK #59 2nd Floor Room 
> (map
> )
> *Calendar*
> ami...@wso2.com
> *Who*
> •
> ami...@wso2.com - organizer
> •
> Sanjiva Weerawarana
> •
> Selvaratnam Uthaiyashankar
> •
> Prabath Siriwardana
> •
> Sagara Gunathunga
> •
> Thilina Buddhika
> •
> Dimuthu Leelarathne
> •
> carbon-dev@wso2.org - optional
>
> Going?   
> ***Yes-
> Maybe-
> No
> ***more options 
> »
>
> Invitation from Google Calendar 
>
> You are receiving this email at the account ami...@wso2.com because you
> set a reminder for this event on the calendar ami...@wso2.com.
>
> You can change your reminders for specific events in the event details
> page in https://www.google.com/calendar/.
>



-- 
Mobile : +94773330538
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] LB server start-up hangs

[Afkham Azeez]

Most bundles which should be in active state but are in the resolved state.
Try to start some of these bundles & see what is wrong.

On Thu, Feb 9, 2012 at 2:05 PM, Nirmal Fernando  wrote:

> RESOLVED




-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* **
email: **az...@wso2.com* * cell: +94 77 3320919
blog: **http://blog.afkham.org* *
twitter: **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] LB server start-up hangs

[Nirmal Fernando]

On Thu, Feb 9, 2012 at 1:49 PM, Afkham Azeez  wrote:

> There is a OSGi dependency problem. Some bundles have not been
> successfully started due to some reason. Start the LB with the OSGi console
> & see what states the bundles are in.
>

AFAIS those bundles are in resolved state.

Framework is launched.

idState   Bundle
0ACTIVE  org.eclipse.osgi_3.7.0.v20110613
Fragments=1, 2, 3
1RESOLVEDgeronimo-saaj_1.3_spec_1.0.0.wso2v2
Master=0
2RESOLVEDorg.wso2.carbon.logging.ext_4.0.0.SNAPSHOT
Master=0
3RESOLVEDorg.wso2.carbon.servletbridge_4.0.0.SNAPSHOT
Master=0
4ACTIVE
org.eclipse.equinox.simpleconfigurator_1.0.200.v20110502-1955
5ACTIVE  XmlSchema_1.4.7.wso2v1
6ACTIVE  abdera_1.0.0.wso2v2
7ACTIVE  ajaxtags_1.3.0.beta-rc7-wso2v1
8ACTIVE  annogen_0.1.0.wso2v1
9ACTIVE  ant_1.7.0.wso2v1
10ACTIVE  antlr_2.7.7.wso2v1
11ACTIVE  authenticator_0.7.0.wso2v1
12RESOLVEDaws.java.sdk.wso2_1.2.3.wso2v1
13ACTIVE  axiom_1.2.11.wso2v1
14ACTIVE  axis2_1.6.1.wso2v4
15ACTIVE  axis2-json_1.6.1.wso2v1
16ACTIVE  axis2-transport-base_1.1.0.wso2v6
17ACTIVE  axis2-transport-jms_1.1.0.wso2v6
18ACTIVE  backport-util-concurrent_3.1.0.wso2v1
19RESOLVEDbsf-all_3.0.0.wso2v1
20ACTIVE  commons-codec_1.4.0.wso2v1
21ACTIVE  commons-collections_3.2.0.wso2v1
22ACTIVE  commons-dbcp_1.4.0.wso2v1
23ACTIVE  commons-fileupload_1.2.0.wso2v1
24ACTIVE  commons-httpclient_3.1.0.wso2v1
25ACTIVE  commons-io_2.0.0.wso2v1
26ACTIVE  commons-lang_2.6.0.wso2v1
27ACTIVE  commons-pool_1.5.6.wso2v1
28ACTIVE  compass_2.0.1.wso2v2
29ACTIVE  ehcache_1.5.0.wso2v1
30ACTIVE  geronimo-stax-api_1.0_spec_1.0.1.wso2v1
31ACTIVE  h2-database-engine_1.2.140.wso2v2
32RESOLVEDhttpclient_4.1.1.wso2v1
33ACTIVE  httpcore_4.1.0.wso2v1
34RESOLVEDhttpcore-nio_4.1.0.wso2v1
35RESOLVEDjackson-core-asl_1.4.0
36ACTIVE  javax.servlet.jsp_2.0.0.v200806031607
37ACTIVE  jaxb_2.1.7.wso2v1
38ACTIVE  jettison_1.1.0.wso2v1
39ACTIVE  neethi_2.0.4.wso2v3
40ACTIVE  opencsv_1.8.0.wso2v1
41ACTIVE  opensaml2_2.4.1.wso2v1
42ACTIVE  org.apache.commons.el_1.0.0.v200806031608
43ACTIVE  org.apache.jasper_5.5.17.v200806031609
44ACTIVE  org.eclipse.core.contenttype_3.4.100.v20110423-0524
45ACTIVE  org.eclipse.core.expressions_3.4.300.v20110228
46ACTIVE  org.eclipse.core.jobs_3.5.100.v20110404
47ACTIVE  org.eclipse.core.runtime_3.7.0.v20110110
48ACTIVE  org.eclipse.ecf_3.1.300.v20110531-2218
49ACTIVE  org.eclipse.ecf.filetransfer_5.0.0.v20110531-2218
50ACTIVE  org.eclipse.ecf.identity_3.1.100.v20110531-2218
51ACTIVE  org.eclipse.ecf.provider.filetransfer_3.2.0.v20110531-2218
52ACTIVE  org.eclipse.equinox.app_1.3.100.v20110321
53ACTIVE  org.eclipse.equinox.common_3.6.0.v20110523
54ACTIVE  org.eclipse.equinox.concurrent_1.0.200.v20110502
55ACTIVE  org.eclipse.equinox.ds_1.3.0.v20110502
56ACTIVE  org.eclipse.equinox.frameworkadmin_2.0.0.v20110502-1955
57ACTIVE
org.eclipse.equinox.frameworkadmin.equinox_1.0.300.v20110506
58ACTIVE  org.eclipse.equinox.http.helper_1.0.0.qualifier
59ACTIVE
org.eclipse.equinox.http.servlet_1.0.200.v20090520-1800-wso2v1
60ACTIVE  org.eclipse.equinox.jsp.jasper_1.0.200.v20090520-1800
61ACTIVE  org.eclipse.equinox.launcher_1.2.0.v20110502
62INSTALLED
org.eclipse.equinox.launcher.gtk.linux.x86_1.1.100.v20110505
63ACTIVE
org.eclipse.equinox.p2.artifact.repository_1.1.100.v20110519
64ACTIVE  org.eclipse.equinox.p2.console_1.0.300.v20110502-1955
65ACTIVE  org.eclipse.equinox.p2.core_2.1.0.v20110502-1955
66ACTIVE  org.eclipse.equinox.p2.director_2.1.0.v20110504-1715
67ACTIVE  org.eclipse.equinox.p2.director.app_1.0.300.v20110505
68ACTIVE
org.eclipse.equinox.p2.directorywatcher_1.0.300.v20110502-1955
69ACTIVE  org.eclipse.equinox.p2.engine_2.1.0.v20110511
70ACTIVE  org.eclipse.equinox.p2.extensionlocation_1.2.100.v20110510
71ACTIVE  org.eclipse.equinox.p2.garbagecollector_1.0.200.v20110510
72ACTIVE  org.eclipse.equinox.p2.jarprocessor_1.0.200.v20110502-1955
73ACTIVE  org.eclipse.equinox.p2.metadata_2.1.0.v20110510
74ACTIVE
org.eclipse.equinox.p2.metadata.repository_1.2.0.v20110511-1359
75ACTIVE  org.eclipse.equinox.p2.publisher_1.2.0.v20110511
76ACTIVE  org.eclipse.equinox.p2.publisher.eclipse_1.0.0.v20110511
77ACTIVE
org.eclipse.equinox.p2.reconciler.dropins_1.1.100.v20110510
78ACTIVE  org.eclipse.equinox.p2.repository_2.1.0.v20110601
79ACTIVE
org.eclipse.equinox.p2.repository.tools_2.0.100.v20110512-1320
80ACTIVE
org.eclipse.equ

[Carbon-dev] [Bamboo-Build] WSO2 Carbon Trunk > WSO2 Carbon - Platform Trunk > #188 has FAILED. Change made by 4 authors.

[Bamboo]

---
WSO2 Carbon Trunk > WSO2 Carbon - Platform Trunk > #188 failed.
---
This build was manually triggered by BambooBuilder.
No failed tests found, a possible compilation error.

http://builder4.us1.wso2.org:/bamboo/browse/WSO2CARBONTUNK-WSO2CARBONPLATFORMTRUNK-188/


--
Failing Jobs
--
  - WSO2 Carbon Trunk Build Process (Default Stage): 7022 tests passed.


--
Code Changes
--
shammi (120258):

>Fixed build failures due to checkSum validation failures by configuring maven 
>to ignore it

shammi (120259):

>Fixed build failures due to checkSum validation failures by configuring maven 
>to ignore it

prabatha (120260):

>fixing UI issues in serviceDetails page of the DS wizard



--
This message is automatically generated by Atlassian Bamboo___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] Performance numbers of Agent Component

[Tharindu Mathew]

Not testing for load at start lead to problems earlier.

Testing for 20 clients and 10 M messages is not the same for testing for
500 clients and 10 M messages. At this scale only, connection pooling,
caching and all of this matters. This is of course, many clients to one
server, a basic test that can be done easily.

Anyway, we can post pone the testing to when we integrate BAM or CEP, but
please be aware of the implications. This was a situation where earlier BAM
was not scaling at all.

On Thu, Feb 9, 2012 at 1:43 PM, Amila Suriarachchi  wrote:

>
>
> On Thu, Feb 9, 2012 at 12:36 PM, Srinath Perera  wrote:
>
>> Hi Suho,
>>
>> IMHO this covers about 90% of our usecases .. I think we should move on
>>
>
> we do not required to do an performance study. Since anyway we don't have
> proper CEP or BAM service to consume events.
>
> But need to test for once client many server scenario to test for
> stability.
>
> thanks,
> Amila.
>
>
>>
>> I do not mind doing a larger perf study later .. ..
>>
>> but getting the server finished from siddhi side and releasing it, CEP
>> perrf numbers,  and integrating this with BAM are more urget IMHO
>>
>> --Srinath
>>
>> On Thu, Feb 9, 2012 at 12:29 PM, Suhothayan Sriskandarajah
>>  wrote:
>> >
>> >
>> > On Thu, Feb 9, 2012 at 12:00 PM, Amila Suriarachchi 
>> wrote:
>> >>
>> >>
>> >>
>> >> On Thu, Feb 9, 2012 at 11:47 AM, Tharindu Mathew 
>> >> wrote:
>> >>>
>> >>> Suho,
>> >>>
>> >>> This does not measure the ability to handle load. Basically, what we
>> did
>> >>> for load testing earlier was send around 2M messages, with
>> concurrency as
>> >>> high increasing from 100 - 1500 clients.
>> >>
>> >>
>> >> How many back end servers and client programs used for that?
>> >>
>> >>>
>> >>>
>> >>> Your test is a measure of being able to consistently handle a stream
>> of
>> >>> messages, which IMO, maybe important but is less interesting when
>> handling
>> >>> load.
>> >>
>> >>
>> >> This test has measured the one client one server. yes it can be
>> improved
>> >> to one client to many servers and many clients to many servers.
>> >>
>> >
>> > This test also covers sending messages from many clients (2,5,10 & 20)
>> to
>> > one server.
>> > Yes it could be improved to many clients to many server.
>> > If there are any specific requirements please suggest me a scenario,
>> then I
>> > can do the testing and present the findings.
>> >
>> > Thanks
>> > Suho
>> >
>> >> But this test gives the through put this can handle one client to
>> server.
>> >> For one client scenario whether you add messages with one thread or
>> many
>> >> threads does not effect the performance if there are enough messages to
>> >> send.
>> >>
>> >> thanks,
>> >> Amila.
>> >>
>> >>>
>> >>> To truly test the ability to handle loads we need to do a distributed
>> >>> load test with an extremely high number of clients and see the
>> breaking
>> >>> point. Earlier, we could not find such a point with a single machine.
>> >>>
>> >>>
>> >>> On Thu, Feb 9, 2012 at 11:31 AM, Suhothayan Sriskandarajah
>> >>>  wrote:
>> 
>> 
>> 
>>  On Thu, Feb 9, 2012 at 11:24 AM, Amila Suriarachchi 
>>  wrote:
>> >
>> > through put should not depend on the number of messages send. You
>> need
>> > to send sufficient number of messages after server warmed up.
>> >
>> > Can you please first send around 2M messages and take the numbers
>> for
>> > next 10M messages.
>> >
>> > And also try to test with number of back end servers.
>> >
>> 
>>  Yes, I'll work on this
>> 
>>  Thanks
>>  Suho
>> 
>> >
>> > thanks,
>> > Amila.
>> >
>> >
>> > On Wed, Feb 8, 2012 at 9:25 PM, Suhothayan Sriskandarajah
>> >  wrote:
>> >>
>> >>
>> >> According to the decisions made at the architecture mailing list on
>> >> the subject "Serializing generic Siddhi events using Thrift",
>> >> I did some improvements to the code base of Agent component and
>> did a
>> >> performance testing.
>> >>
>> >> Here I did the tests by sending total of 1 million and 10 million
>> >> events using for loop,
>> >> in both cases I have sent events using 1,2,5,10 & 20 Clients.
>> >>
>> >> The results are as follows
>> >>
>> >>   1M  10M
>> >> 1  245118.1269328.8
>> >> 2  517509.1739699.7
>> >> 5  585823.1923986.7
>> >> 10345582.3418865.7
>> >> 20285008.6368881.2
>> >>
>> >> I have also attached the performance graph
>> >>
>> >> Regards
>> >> Suho
>> >>
>> >>
>> >> --
>> >> S. Suhothayan
>> >> Software Engineer,
>> >> Data Technologies Team,
>> >> WSO2, Inc. http://wso2.com
>> >> lean.enterprise.middleware.
>> >>
>> >> email: s...@wso2.com cell: (+94) 779 756 757
>> >> blog: http://suhothayan.blogspot.com/
>> >> twitter: http://twitter.com/suhothayan
>> >> linked-in: http

Re: [Carbon-dev] Build Failure in core

[Pradeep Fernando]

you have to build,
org.eclipse.equinox.p2.touchpoint.eclipse:jar:2.1.0.v20110511-wso2v1 module
found under /dependencies

--Pradeep
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] Tomcat OSGification - progress update

[Pradeep Fernando]

On Thu, Feb 9, 2012 at 1:44 PM, Afkham Azeez  wrote:

> You need to ensure that dynamic valve addition to the valve chain from
> Carbon components is supported. That is how the TenantLazyLoaderValve is
> added by the webapp-mgt component. Need to test tenant lazy loading when
> webapps receive requests as well.
>

working on that. thanks.

--Pradeep
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] LB server start-up hangs

[Afkham Azeez]

There is a OSGi dependency problem. Some bundles have not been successfully
started due to some reason. Start the LB with the OSGi console & see what
states the bundles are in.

On Thu, Feb 9, 2012 at 1:43 PM, Nirmal Fernando  wrote:

> Hi,
>
> I see following warnings appear, they keep popping and server start-up
> hangs. Any thoughts?
>
> [2012-02-09 13:38:52,440]  WARN - CarbonServerManager Carbon
> initialization is delayed due to the following unsatisfied items:
> [2012-02-09 13:38:52,442]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.module.mgt-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,442]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.mediator.clazz.services-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,442]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.service.mgt-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,443]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.endpoint-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,443]  WARN - CarbonServerManager Waiting for required
> Module: rampart-trust-1.6.1.wso2v3
> [2012-02-09 13:38:52,443]  WARN - CarbonServerManager Waiting for required
> Module: org.wso2.carbon.rm-4.0.0-SNAPSHOT
> [2012-02-09 13:38:52,444]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.localentry-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,444]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.caching-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,444]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.operation.mgt-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,444]  WARN - CarbonServerManager Waiting for required
> Module: org.wso2.carbon.relay.module-4.0.0-SNAPSHOT
> [2012-02-09 13:38:52,445]  WARN - CarbonServerManager Waiting for required
> OSGi Service: org.apache.axis2.engine.AxisObserver
> [2012-02-09 13:38:52,445]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.throttle-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,445]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.security.mgt-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,445]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.transport.mgt-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,446]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.datasource-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,446]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.task-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,446]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.sequences-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,446]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.event.ws-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,447]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.rm-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,447]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.mediator.command.services-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,448]  WARN - CarbonServerManager Waiting for required
> Module: org.wso2.carbon.caching-4.0.0-SNAPSHOT
> [2012-02-09 13:38:52,448]  WARN - CarbonServerManager Waiting for required
> Module: org.wso2.carbon.security.mgt-4.0.0-SNAPSHOT
> [2012-02-09 13:38:52,448]  WARN - CarbonServerManager Waiting for required
> Module: org.wso2.carbon.throttle-4.0.0-SNAPSHOT
> [2012-02-09 13:38:52,449]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.event.admin-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,449]  WARN - CarbonServerManager Waiting for required
> Module: rampart-core-1.6.1.wso2v3
> [2012-02-09 13:39:52,440]  WARN - CarbonServerManager Carbon
> initialization is delayed due to the following unsatisfied items:
> [2012-02-09 13:39:52,440]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.module.mgt-4.0.0.SNAPSHOT
> [2012-02-09 13:39:52,441]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.mediator.clazz.services-4.0.0.SNAPSHOT
> [2012-02-09 13:39:52,441]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.service.mgt-4.0.0.SNAPSHOT
> [2012-02-09 13:39:52,441]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.endpoint-4.0.0.SNAPSHOT
> [2012-02-09 13:39:52,441]  WARN - CarbonServerManager Waiting for required
> Module: rampart-trust-1.6.1.wso2v3
> [2012-02-09 13:39:52,442]  WARN - CarbonServerManager Waiting for required
> Module: org.wso2.carbon.rm-4.0.0-SNAPSHOT
> [2012-02-09 13:39:52,442]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.localentry-4.0.0.SNAPSHOT
> [2012-02-09 13:39:52,442]  WARN - CarbonServerManager Waiting for required
> OSGiA

Re: [Carbon-dev] LB server start-up hangs

[Nirmal Fernando]

This happens in the trunk version.

On Thu, Feb 9, 2012 at 1:43 PM, Nirmal Fernando  wrote:

> Hi,
>
> I see following warnings appear, they keep popping and server start-up
> hangs. Any thoughts?
>
> [2012-02-09 13:38:52,440]  WARN - CarbonServerManager Carbon
> initialization is delayed due to the following unsatisfied items:
> [2012-02-09 13:38:52,442]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.module.mgt-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,442]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.mediator.clazz.services-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,442]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.service.mgt-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,443]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.endpoint-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,443]  WARN - CarbonServerManager Waiting for required
> Module: rampart-trust-1.6.1.wso2v3
> [2012-02-09 13:38:52,443]  WARN - CarbonServerManager Waiting for required
> Module: org.wso2.carbon.rm-4.0.0-SNAPSHOT
> [2012-02-09 13:38:52,444]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.localentry-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,444]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.caching-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,444]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.operation.mgt-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,444]  WARN - CarbonServerManager Waiting for required
> Module: org.wso2.carbon.relay.module-4.0.0-SNAPSHOT
> [2012-02-09 13:38:52,445]  WARN - CarbonServerManager Waiting for required
> OSGi Service: org.apache.axis2.engine.AxisObserver
> [2012-02-09 13:38:52,445]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.throttle-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,445]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.security.mgt-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,445]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.transport.mgt-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,446]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.datasource-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,446]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.task-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,446]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.sequences-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,446]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.event.ws-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,447]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.rm-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,447]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.mediator.command.services-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,448]  WARN - CarbonServerManager Waiting for required
> Module: org.wso2.carbon.caching-4.0.0-SNAPSHOT
> [2012-02-09 13:38:52,448]  WARN - CarbonServerManager Waiting for required
> Module: org.wso2.carbon.security.mgt-4.0.0-SNAPSHOT
> [2012-02-09 13:38:52,448]  WARN - CarbonServerManager Waiting for required
> Module: org.wso2.carbon.throttle-4.0.0-SNAPSHOT
> [2012-02-09 13:38:52,449]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.event.admin-4.0.0.SNAPSHOT
> [2012-02-09 13:38:52,449]  WARN - CarbonServerManager Waiting for required
> Module: rampart-core-1.6.1.wso2v3
> [2012-02-09 13:39:52,440]  WARN - CarbonServerManager Carbon
> initialization is delayed due to the following unsatisfied items:
> [2012-02-09 13:39:52,440]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.module.mgt-4.0.0.SNAPSHOT
> [2012-02-09 13:39:52,441]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.mediator.clazz.services-4.0.0.SNAPSHOT
> [2012-02-09 13:39:52,441]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.service.mgt-4.0.0.SNAPSHOT
> [2012-02-09 13:39:52,441]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.endpoint-4.0.0.SNAPSHOT
> [2012-02-09 13:39:52,441]  WARN - CarbonServerManager Waiting for required
> Module: rampart-trust-1.6.1.wso2v3
> [2012-02-09 13:39:52,442]  WARN - CarbonServerManager Waiting for required
> Module: org.wso2.carbon.rm-4.0.0-SNAPSHOT
> [2012-02-09 13:39:52,442]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.localentry-4.0.0.SNAPSHOT
> [2012-02-09 13:39:52,442]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Service: org.wso2.carbon.caching-4.0.0.SNAPSHOT
> [2012-02-09 13:39:52,442]  WARN - CarbonServerManager Waiting for required
> OSGiAxis2Se

Re: [Carbon-dev] Tomcat OSGification - progress update

[Afkham Azeez]

You need to ensure that dynamic valve addition to the valve chain from
Carbon components is supported. That is how the TenantLazyLoaderValve is
added by the webapp-mgt component. Need to test tenant lazy loading when
webapps receive requests as well.

On Wed, Feb 8, 2012 at 10:53 PM, Pradeep Fernando  wrote:

> Hi all,
>
> Think i'm done with the first iteration of the tomcat-OSGification effort.
> It time to move the code in to trunk. I could run modified wso2-as without
> a problem. Was able to solve the transport related issue by Extending the
> TomcatStandardService and not starting transports.
>
> I need help on following areas (porting),
>
> 1. make sure all the features are working in wso2-as - kishanthan (?)
> 2. porting the patching code to new carbon startup classes. -Dileepa
> 3. Jaggery deployer related things - (?)
>
>
> As soon as we are done with above tasks, we are going to move the code in
> to trunk. Trunk will be frozen for few days (this work + svn restructuring).
>
>
> Please checkout the code found in [1] and start building it. :)
>
>
> thanks,
> --Pradeep
>
> ___
> 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/
* **
email: **az...@wso2.com* * cell: +94 77 3320919
blog: **http://blog.afkham.org* *
twitter: **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] Tomcat OSGification - progress update

[Afkham Azeez]

On Thu, Feb 9, 2012 at 10:34 AM, Isuru Suriarachchi  wrote:

>
>
> On Thu, Feb 9, 2012 at 10:28 AM, Nuwan Bandara  wrote:
>
>> Hi Guys
>>
>> On Thu, Feb 9, 2012 at 10:26 AM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>> Hi Pradeep,
>>>
>>> On Wed, Feb 8, 2012 at 10:53 PM, Pradeep Fernando wrote:
>>>
 Hi all,

 Think i'm done with the first iteration of the tomcat-OSGification
 effort. It time to move the code in to trunk. I could run modified wso2-as
 without a problem. Was able to solve the transport related issue by
 Extending the TomcatStandardService and not starting transports.

 I need help on following areas (porting),

 1. make sure all the features are working in wso2-as - kishanthan (?)
>>>
>>>
>>> Sure, ill work on this. I believe that i have to check mostly the
>>> web-app related functionalities as you have imported the web-app deployment
>>> into web-app mgt component from server in your new changes. And ill check
>>> on other features as well.
>>>
>>
>> Can we also look at web-app exploded mode deployment at the same time.
>>
>
> This is something different from the ongoing work and we'll have to think
> of a way of supporting it. With the current deployment model, it's not that
> easy. Let's look into this after stabilizing the trunk.
>

+1. Exploded mode deployment is a different problem, and we cannot make
that easily work on StratosLive (how do you upload a directory?)


>
> Thanks,
> ~Isuru
>
>
>>
>> Regards,
>> /Nuwan
>>
>>
>>>
>>> Thanks,
>>> Kishanthan.
>>>
>>> 2. porting the patching code to new carbon startup classes. -Dileepa
 3. Jaggery deployer related things - (?)


 As soon as we are done with above tasks, we are going to move the code
 in to trunk. Trunk will be frozen for few days (this work + svn
 restructuring).


 Please checkout the code found in [1] and start building it. :)


 thanks,
 --Pradeep

>>>
>>>
>>>
>>> --
>>> *Kishanthan Thangarajah*
>>> Software Engineer,
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile - +94773426635
>>> Blog - *http://kishanthan.wordpress.com*
>>> Twitter - *http://twitter.com/kishanthan*
>>>
>>>
>>
>>
>> --
>> *
>> Thanks & Regards,
>>
>> Nuwan Bandara
>> Senior Software Engineer
>> WSO2 Inc. | http://wso2.com
>> lean . enterprise . middleware
>>
>> http://nuwan.bandara.co
>> *
>> 
>>
>
>
>
> --
> Isuru Suriarachchi
> Technical Lead
> WSO2 Inc. http://wso2.com
> email : is...@wso2.com
> blog : http://isurues.wordpress.com/
>
> lean . enterprise . middleware
>
>
> ___
> 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/
* **
email: **az...@wso2.com* * cell: +94 77 3320919
blog: **http://blog.afkham.org* *
twitter: **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] Performance numbers of Agent Component

[Amila Suriarachchi]

On Thu, Feb 9, 2012 at 12:36 PM, Srinath Perera  wrote:

> Hi Suho,
>
> IMHO this covers about 90% of our usecases .. I think we should move on
>

we do not required to do an performance study. Since anyway we don't have
proper CEP or BAM service to consume events.

But need to test for once client many server scenario to test for stability.

thanks,
Amila.


>
> I do not mind doing a larger perf study later .. ..
>
> but getting the server finished from siddhi side and releasing it, CEP
> perrf numbers,  and integrating this with BAM are more urget IMHO
>
> --Srinath
>
> On Thu, Feb 9, 2012 at 12:29 PM, Suhothayan Sriskandarajah
>  wrote:
> >
> >
> > On Thu, Feb 9, 2012 at 12:00 PM, Amila Suriarachchi 
> wrote:
> >>
> >>
> >>
> >> On Thu, Feb 9, 2012 at 11:47 AM, Tharindu Mathew 
> >> wrote:
> >>>
> >>> Suho,
> >>>
> >>> This does not measure the ability to handle load. Basically, what we
> did
> >>> for load testing earlier was send around 2M messages, with concurrency
> as
> >>> high increasing from 100 - 1500 clients.
> >>
> >>
> >> How many back end servers and client programs used for that?
> >>
> >>>
> >>>
> >>> Your test is a measure of being able to consistently handle a stream of
> >>> messages, which IMO, maybe important but is less interesting when
> handling
> >>> load.
> >>
> >>
> >> This test has measured the one client one server. yes it can be improved
> >> to one client to many servers and many clients to many servers.
> >>
> >
> > This test also covers sending messages from many clients (2,5,10 & 20) to
> > one server.
> > Yes it could be improved to many clients to many server.
> > If there are any specific requirements please suggest me a scenario,
> then I
> > can do the testing and present the findings.
> >
> > Thanks
> > Suho
> >
> >> But this test gives the through put this can handle one client to
> server.
> >> For one client scenario whether you add messages with one thread or many
> >> threads does not effect the performance if there are enough messages to
> >> send.
> >>
> >> thanks,
> >> Amila.
> >>
> >>>
> >>> To truly test the ability to handle loads we need to do a distributed
> >>> load test with an extremely high number of clients and see the breaking
> >>> point. Earlier, we could not find such a point with a single machine.
> >>>
> >>>
> >>> On Thu, Feb 9, 2012 at 11:31 AM, Suhothayan Sriskandarajah
> >>>  wrote:
> 
> 
> 
>  On Thu, Feb 9, 2012 at 11:24 AM, Amila Suriarachchi 
>  wrote:
> >
> > through put should not depend on the number of messages send. You
> need
> > to send sufficient number of messages after server warmed up.
> >
> > Can you please first send around 2M messages and take the numbers for
> > next 10M messages.
> >
> > And also try to test with number of back end servers.
> >
> 
>  Yes, I'll work on this
> 
>  Thanks
>  Suho
> 
> >
> > thanks,
> > Amila.
> >
> >
> > On Wed, Feb 8, 2012 at 9:25 PM, Suhothayan Sriskandarajah
> >  wrote:
> >>
> >>
> >> According to the decisions made at the architecture mailing list on
> >> the subject "Serializing generic Siddhi events using Thrift",
> >> I did some improvements to the code base of Agent component and did
> a
> >> performance testing.
> >>
> >> Here I did the tests by sending total of 1 million and 10 million
> >> events using for loop,
> >> in both cases I have sent events using 1,2,5,10 & 20 Clients.
> >>
> >> The results are as follows
> >>
> >>   1M  10M
> >> 1  245118.1269328.8
> >> 2  517509.1739699.7
> >> 5  585823.1923986.7
> >> 10345582.3418865.7
> >> 20285008.6368881.2
> >>
> >> I have also attached the performance graph
> >>
> >> Regards
> >> Suho
> >>
> >>
> >> --
> >> S. Suhothayan
> >> Software Engineer,
> >> Data Technologies Team,
> >> WSO2, Inc. http://wso2.com
> >> lean.enterprise.middleware.
> >>
> >> email: s...@wso2.com cell: (+94) 779 756 757
> >> blog: http://suhothayan.blogspot.com/
> >> twitter: http://twitter.com/suhothayan
> >> linked-in: http://lk.linkedin.com/in/suhothayan
> >>
> >>
> >
> >
> >
> > --
> > Amila Suriarachchi
> >
> > Software Architect
> > WSO2 Inc. ; http://wso2.com
> > lean . enterprise . middleware
> >
> > phone : +94 71 3082805
> >
> 
> 
> 
>  --
>  S. Suhothayan
>  Software Engineer,
>  Data Technologies Team,
>  WSO2, Inc. http://wso2.com
>  lean.enterprise.middleware.
> 
>  email: s...@wso2.com cell: (+94) 779 756 757
>  blog: http://suhothayan.blogspot.com/
>  twitter: http://twitter.com/suhothayan
>  linked-in: http://lk.linkedin.com/in/suhothayan
> 
> 
> >>>
> >>>
> >>>
> >>> --
> >>> Regards,
> >>>
> >>> Tharindu
> >>>
>

[Carbon-dev] LB server start-up hangs

[Nirmal Fernando]

Hi,

I see following warnings appear, they keep popping and server start-up
hangs. Any thoughts?

[2012-02-09 13:38:52,440]  WARN - CarbonServerManager Carbon initialization
is delayed due to the following unsatisfied items:
[2012-02-09 13:38:52,442]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.module.mgt-4.0.0.SNAPSHOT
[2012-02-09 13:38:52,442]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.mediator.clazz.services-4.0.0.SNAPSHOT
[2012-02-09 13:38:52,442]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.service.mgt-4.0.0.SNAPSHOT
[2012-02-09 13:38:52,443]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.endpoint-4.0.0.SNAPSHOT
[2012-02-09 13:38:52,443]  WARN - CarbonServerManager Waiting for required
Module: rampart-trust-1.6.1.wso2v3
[2012-02-09 13:38:52,443]  WARN - CarbonServerManager Waiting for required
Module: org.wso2.carbon.rm-4.0.0-SNAPSHOT
[2012-02-09 13:38:52,444]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.localentry-4.0.0.SNAPSHOT
[2012-02-09 13:38:52,444]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.caching-4.0.0.SNAPSHOT
[2012-02-09 13:38:52,444]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.operation.mgt-4.0.0.SNAPSHOT
[2012-02-09 13:38:52,444]  WARN - CarbonServerManager Waiting for required
Module: org.wso2.carbon.relay.module-4.0.0-SNAPSHOT
[2012-02-09 13:38:52,445]  WARN - CarbonServerManager Waiting for required
OSGi Service: org.apache.axis2.engine.AxisObserver
[2012-02-09 13:38:52,445]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.throttle-4.0.0.SNAPSHOT
[2012-02-09 13:38:52,445]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.security.mgt-4.0.0.SNAPSHOT
[2012-02-09 13:38:52,445]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.transport.mgt-4.0.0.SNAPSHOT
[2012-02-09 13:38:52,446]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.datasource-4.0.0.SNAPSHOT
[2012-02-09 13:38:52,446]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.task-4.0.0.SNAPSHOT
[2012-02-09 13:38:52,446]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.sequences-4.0.0.SNAPSHOT
[2012-02-09 13:38:52,446]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.event.ws-4.0.0.SNAPSHOT
[2012-02-09 13:38:52,447]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.rm-4.0.0.SNAPSHOT
[2012-02-09 13:38:52,447]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.mediator.command.services-4.0.0.SNAPSHOT
[2012-02-09 13:38:52,448]  WARN - CarbonServerManager Waiting for required
Module: org.wso2.carbon.caching-4.0.0-SNAPSHOT
[2012-02-09 13:38:52,448]  WARN - CarbonServerManager Waiting for required
Module: org.wso2.carbon.security.mgt-4.0.0-SNAPSHOT
[2012-02-09 13:38:52,448]  WARN - CarbonServerManager Waiting for required
Module: org.wso2.carbon.throttle-4.0.0-SNAPSHOT
[2012-02-09 13:38:52,449]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.event.admin-4.0.0.SNAPSHOT
[2012-02-09 13:38:52,449]  WARN - CarbonServerManager Waiting for required
Module: rampart-core-1.6.1.wso2v3
[2012-02-09 13:39:52,440]  WARN - CarbonServerManager Carbon initialization
is delayed due to the following unsatisfied items:
[2012-02-09 13:39:52,440]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.module.mgt-4.0.0.SNAPSHOT
[2012-02-09 13:39:52,441]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.mediator.clazz.services-4.0.0.SNAPSHOT
[2012-02-09 13:39:52,441]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.service.mgt-4.0.0.SNAPSHOT
[2012-02-09 13:39:52,441]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.endpoint-4.0.0.SNAPSHOT
[2012-02-09 13:39:52,441]  WARN - CarbonServerManager Waiting for required
Module: rampart-trust-1.6.1.wso2v3
[2012-02-09 13:39:52,442]  WARN - CarbonServerManager Waiting for required
Module: org.wso2.carbon.rm-4.0.0-SNAPSHOT
[2012-02-09 13:39:52,442]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.localentry-4.0.0.SNAPSHOT
[2012-02-09 13:39:52,442]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.caching-4.0.0.SNAPSHOT
[2012-02-09 13:39:52,442]  WARN - CarbonServerManager Waiting for required
OSGiAxis2Service: org.wso2.carbon.operation.mgt-4.0.0.SNAPSHOT
[2012-02-09 13:39:52,443]  WARN - CarbonServerManager Waiting for required
Module: org.wso2.carbon.relay.module-4.0.0-SNAPSHOT
[2012-02-09 13:39:52,443]  WARN - CarbonServerManager Waiting for 

Re: [Carbon-dev] Build Failure in core

[Reka Thirunavukkarasu]

Hi

I could build the core successfully with yesterday's updates. Could you
able to get full update without any errors?

On Thu, Feb 9, 2012 at 1:22 PM, Maninda Edirisooriya wrote:

> This build error came since yesterday. This may be a problem with nexus.
>
> [INFO]
> 
> [INFO] Building WSO2 Carbon - Carbon UI Feature 4.0.0-SNAPSHOT
> [INFO]
> 
> [INFO]
> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @
> org.wso2.carbon.core.ui.feature ---
> [INFO] Deleting
> /home/maninda/carbon-source/carbon/core/features/org.wso2.carbon.core.ui.feature/target
> [INFO]
> [INFO] --- incremental-build-plugin:1.3:incremental-build (default) @
> org.wso2.carbon.core.ui.feature ---
> [INFO] Verifying module descriptor ...
> [INFO] Pom descriptor modification detected.
> [INFO] Deleting
> /home/maninda/carbon-source/carbon/core/features/org.wso2.carbon.core.ui.feature/target
> [INFO]
> [INFO] --- carbon-p2-plugin:1.4-SNAPSHOT:p2-feature-gen
> (4-p2-feature-generation) @ org.wso2.carbon.core.ui.feature ---
> [INFO] Generating feature manifest
> [INFO] Generating feature properties
> [INFO] Generating MANIFEST.MF
> [INFO] Generating Advice file (p2.inf)
> [INFO] Copying bundle dependencies
> [INFO]org.apache.jasper:5.5.17.v200806031609
> [INFO]org.eclipse.equinox.jsp.jasper:1.0.200.v20090520-1800
> [INFO]org.wso2.carbon.ui:4.0.0.SNAPSHOT
> [INFO]org.wso2.carbon.core.commons.stub:4.0.0.SNAPSHOT
> [INFO]org.wso2.carbon.ui.menu.general:4.0.0.SNAPSHOT
> [INFO]org.wso2.carbon.i18n:4.0.0.SNAPSHOT
> [INFO]org.wso2.carbon.server.admin.ui:4.0.0.SNAPSHOT
> [INFO]org.wso2.carbon.server.admin.stub:4.0.0.SNAPSHOT
> [INFO]org.wso2.carbon.user.mgt.ui:4.0.0.SNAPSHOT
> [INFO]org.wso2.carbon.user.mgt.stub:4.0.0.SNAPSHOT
> [INFO]org.wso2.carbon.feature.mgt.ui:4.0.0.SNAPSHOT
> [INFO]org.wso2.carbon.feature.mgt.stub:4.0.0.SNAPSHOT
> [INFO]org.wso2.carbon.roles.mgt.ui:4.0.0.SNAPSHOT
> [INFO]org.wso2.carbon.roles.mgt.stub:4.0.0.SNAPSHOT
> [INFO]ajaxtags:1.3.0.beta-rc7-wso2v1
> [INFO]taglibs.standard:1.1.2.wso2v1
> [INFO] Generating feature archive:
> /home/maninda/carbon-source/carbon/core/features/org.wso2.carbon.core.ui.feature/target/org.wso2.carbon.core.ui.feature-4.0.0-SNAPSHOT.zip
> [INFO]
> [INFO] --- maven-install-plugin:2.3.1:install (default-install) @
> org.wso2.carbon.core.ui.feature ---
> [INFO] Installing
> /home/maninda/carbon-source/carbon/core/features/org.wso2.carbon.core.ui.feature/pom.xml
> to
> /home/maninda/.m2/repository/org/wso2/carbon/org.wso2.carbon.core.ui.feature/4.0.0-SNAPSHOT/org.wso2.carbon.core.ui.feature-4.0.0-SNAPSHOT.pom
> [INFO] Installing
> /home/maninda/carbon-source/carbon/core/features/org.wso2.carbon.core.ui.feature/target/org.wso2.carbon.core.ui.feature-4.0.0-SNAPSHOT.zip
> to
> /home/maninda/.m2/repository/org/wso2/carbon/org.wso2.carbon.core.ui.feature/4.0.0-SNAPSHOT/org.wso2.carbon.core.ui.feature-4.0.0-SNAPSHOT.zip
> [INFO]
>
> [INFO]
> 
> [INFO] Building WSO2 Carbon - Carbon Runtime Feature 4.0.0-SNAPSHOT
> [INFO]
> 
> [WARNING] The POM for
> org.eclipse.equinox:org.eclipse.equinox.p2.touchpoint.eclipse:jar:2.1.0.v20110511-wso2v1
> is missing, no dependency information available
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] WSO2 Carbon Core - Parent Maven Project ... SUCCESS [0.235s]
> [INFO] WSO2 Carbon - Thread .. SUCCESS [1.188s]
> [INFO] WSO2 Carbon - Better Tomcat ... SUCCESS [3.041s]
> [INFO] WSO2 Carbon - Registry API  SUCCESS [0.509s]
> [INFO] WSO2 Carbon - User Manager API  SUCCESS [0.424s]
> [INFO] WSO2 Carbon - Xbootclasspath libraries  SUCCESS [0.304s]
> [INFO] WSO2 Carbon - Logging . SUCCESS [0.656s]
> [INFO] WSO2 Carbon - Queuing . SUCCESS [0.496s]
> [INFO] WSO2 Carbon - Secure Vault  SUCCESS [0.607s]
> [INFO] WSO2 Carbon - Base  SUCCESS [0.752s]
> [INFO] WSO2 Carbon - Caching . SUCCESS [0.841s]
> [INFO] WSO2 Carbon - Utilities ... SUCCESS [2.449s]
> [INFO] WSO2 Carbon - Bootstrap ... SUCCESS [0.448s]
> [INFO] WSO2 Carbon - Servlet to OSGi Bridge .. SUCCESS [0.890s]
> [INFO] WSO2 Carbon - OSGi Security ... SUCCESS [0.656s]
> [INFO] WSO2 Carbon - Xbootclasspath library for Registry Kernel  SUCCESS
> [0.279s]
> [INFO] WSO2 Carbon - Logging Extension ... SUCCESS [0.794s]
> [INFO] WSO2 Carbon - Windows NT Service In