Re: [Architecture] Carbon C5 - Server Configuration Model

[Ramith Jayasinghe]

to me that makes sense. we started having the same thing since mb v 3.0.0.
it even put out a (helpful) warnings during the start up if any
configuration is missing in the config file and (default) value server
chose to go with.

On Tue, Nov 29, 2016 at 1:18 PM, Dilan Udara Ariyaratne 
wrote:

> Hi Ruwan,
>
> The purpose of suggesting to move these default values to CONSTANTS is as
> follows.
> Instead of simply setting a raw value to a bean property, by setting it up
> via a CONSTANT with a meaningful name like DEFAULT_VERSION brings
> the message that unless you set an alternative value via the yaml file, a
> default value will be set via this CONSTANT.
>
> It's true that a property like version would change from one release to
> another. But it remains as a CONSTANT for a particular release which we
> need to understand in my opinion.
>
> Thanks,
> Dilan.
>
> *Dilan U. Ariyaratne*
> Senior Software Engineer
> WSO2 Inc. 
> Mobile: +94766405580 <%2B94766405580>
> lean . enterprise . middleware
>
>
> On Tue, Nov 29, 2016 at 7:27 AM, Ruwan Abeykoon  wrote:
>
>> Hi Dilan,
>> -1 moving the default value in the properties to constants, since they
>> are not constants. Most of the values within those defaults will be changed
>> over the time, when we learn more about the system behavior, over many
>> release cycles.
>>
>> For the propose of readability and maintainability the original code
>> looks better than the suggestion.
>>
>> i.e
>> @Element(description = "server version")
>> private String version = "5.2.0";
>>
>> is better than
>> @Element(description = "server version")
>> private String version = CarbonConfigurationConstants.DEFAULT_VERSION;
>>
>> Cheers,
>> Ruwan
>>
>> On Mon, Nov 28, 2016 at 9:08 PM, Dilan Udara Ariyaratne 
>> wrote:
>>
>>> Hi Danesh,
>>>
>>> Referring to the following,
>>>
>>> @Configuration(namespace = "wso2.carbon", description = "Carbon 
>>> Configuration Parameters")
>>> public class CarbonConfiguration {
>>>
>>> @Element(description = "value to uniquely identify a server", required 
>>> = true)
>>> private String id = "carbon-kernel";
>>>
>>> @Element(description = "server name")
>>> private String name = "WSO2 Carbon Kernel";
>>>
>>> @Element(description = "server version")
>>> private String version = "5.2.0";
>>>
>>> ...
>>>
>>> }
>>>
>>> In a developer's perspective, it would be more meaningful to define any
>>> default value as a separate CONSTANT in the code level and
>>> set any bean property similar to above with such a constant for better
>>> readability.
>>>
>>> For ex:
>>>
>>> @Configuration(namespace = "wso2.carbon", description = "Carbon 
>>> Configuration Parameters")
>>> public class CarbonConfiguration {
>>>
>>> @Element(description = "value to uniquely identify a server", required 
>>> = true)
>>> private String id = CarbonConfigurationConstants.DEFAULT_ID;
>>> @Element(description = "server name")
>>> private String name = CarbonConfigurationConstants.DEFAULT_NAME;
>>> @Element(description = "server version")
>>> private String version = CarbonConfigurationConstants.DEFAULT_VERSION;
>>> ...
>>> }
>>>
>>> In the meantime, also have the following question.
>>>
>>> If all user-configurable properties are not readily available in the
>>> .yaml file by default, how would a user know which
>>> properties are configurable and which are not ?
>>>
>>> Thanks,
>>> Dilan.
>>>
>>> *Dilan U. Ariyaratne*
>>> Senior Software Engineer
>>> WSO2 Inc. 
>>> Mobile: +94766405580 <%2B94766405580>
>>> lean . enterprise . middleware
>>>
>>>
>>> On Mon, Nov 28, 2016 at 10:58 AM, Danesh Kuruppu 
>>> wrote:
>>>
 Hi Rukshan,

 No. We are going to include this in next kernel release(5.2.0).

 Thanks
 Danesh

 On Mon, Nov 28, 2016 at 10:26 AM, Rukshan Premathunga >>> > wrote:

> Hi Danesh,
>
> Is this feature is available now? if so can you mention the kernel
> version please?
>
> Thanks and Regards
>
> On Tue, Nov 22, 2016 at 12:22 PM, Danesh Kuruppu 
> wrote:
>
>> Hi Nuwan,
>>
>> Can you also provide an example bean class for the netty listener?
>>> That would make it clear how the bean class and its nested classes 
>>> would be
>>> annotated when array elements come into play.
>>>
>>
>> Please check TransportsConfiguration sample below. We need to mention
>> the default values of an array or collection in class constructor as 
>> below.
>>
>> @Configuration(namespace = "wso2.transports.netty", description = "Netty 
>> Transport Configurations")
>> public class TransportsConfiguration {
>>
>> //default values of an array or collection need to mention in class 
>> constructor
>> public TransportsConfiguration() {
>> ListenerConfiguration listenerConfiguration = 
>> ListenerConfiguration();
>> listenerConfigurations = 

[Architecture] WSO2 API Manager 2.1.0-BETA Released!

[Chamin Dias]

WSO2 API Manager team is pleased to announce WSO2 API Manager 2.1.0-BETA
release.

Distribution : https://github.com/wso2/product-apim/releases/tag/v2.1.0-beta
Analytics : https://github.com/wso2/analytics-apim/releases/tag/v2.1.0-beta
Tooling : https://github.com/wso2/devstudio-tooling-apim/releases/ta
g/Released-release-2.1.0-Beta-2016-11-29-111525

*Bug*

   - [APIMANAGER-5297 ] -
   CLONE - API Console Seems not to handle SOAP API
   - [APIMANAGER-5299 ] -
   Updating Forum topic gives an error
   - [APIMANAGER-5361 ] -
   CORS Headers not returned for default endpoint version
   - [APIMANAGER-5414 ] -
   CORS headers not sent when calling from AJAX web app
   - [APIMANAGER-5460 ] -
   Possible timeout issue in Gateway Cache
   - [APIMANAGER-5476 ] - Dep
   Sync feature is not included in Traffic Manager profile
   - [APIMANAGER-5480 ] -
   WSDL shows wrong API transport
   - [APIMANAGER-5482 ] -
   [WebSocket API] Publishing without a sandbox url give an error
   - [APIMANAGER-5484 ] -
   Unable to create an API using existing SOAP endpoint
   - [APIMANAGER-5485 ] -
   Sequence artifact isn't removed when Websocket API is deleted
   - [APIMANAGER-5491 ] -
   Product Profile not working
   - [APIMANAGER-5498 ] -
   Intermittent NullPointerException in Websocket API handshake
   - [APIMANAGER-5504 ] -
   Error while adding a custom sequence
   - [APIMANAGER-5506 ] -
   Selected Endpoint type is empty in publsher implement tab


*Improvement*

   - [APIMANAGER-5486 ] - Add
   Google Analytics Support for Websocket APIs
   - [APIMANAGER-5494 ] - Add
   useful property values for In, Out and Fault sequences
   - [APIMANAGER-5495 ] -
   Bottleneck in throttle policy deployment to Traffic Manager
   - [APIMANAGER-5497 ] - Non
   responsive behavior in UI when deploying throttling policies


Thanks.
WSO2 API Manager Team.

-- 
Chamin Dias
*Software Engineer*
Mobile : +94 (0) 716 097455 <%2B94%20%280%29%20773%20451194>
Email : cham...@wso2.com
Blog : https://chamindias.wordpress.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [Dev] [VOTE] Release WSO2 Enterprise Mobility Manager 2.2.0 RC2

[Harshan Liyanage]

Hi Devs,

This is the release candidate of WSO2 Enterprise Mobility Manager 2.2.0.

Please download EMM 2.2.0 RC2 and test the functionality and vote. Vote
will be open for 72 hours or as needed.
Know issues: https://wso2.org/jira/issues/?filter=13384
Fixes provided : https://wso2.org/jira/issues/?filter=13582


Source & binary distribution files:
https://github.com/wso2/product-emm/releases/tag/v2.2.0-RC2

The tag to be voted upon:
https://github.com/wso2/product-emm/tree/release-2.2.0-RC2


[+] Stable - go ahead and release
[-]  Broken - do not release (explain why)

Thanks and Regards,


Harshan Liyanage
EMM/IoT TG
Mobile: *+94765672894*
Email: hars...@wso2.com
Blog : http://harshanliyanage.blogspot.com/
*WSO2, Inc. :** wso2.com *
lean.enterprise.middleware.
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Carbon C5 - Server Configuration Model

[Abimaran Kugathasan]

Hi Danesh,

On Mon, Nov 21, 2016 at 11:32 PM, Danesh Kuruppu  wrote:

> Hi all,
>
> In Carbon C5, we are going to introduce new global configuration model
> where we have only one configuration file for all server configurations.
> So that user have to maintain only one config file for a server.
>
> With New Configuration Model,
>
>- Global configuration file (deployment.yaml) includes minimal sets of
>configurations which need to override very often by default (e.g: server
>ports etc).
>- All user settable configurations must have default values and they
>are burnt into compile codes.
>- Any default configuration can overridden by adding the particular
>configuration to the global configuration file(deployment.yaml).
>- Defining all configurations in the configuration file in not
>required. add only if we need to override the default value.
>- If configurations are not specified in the configuration file,
>values defined in the bean class will apply by default.
>
> In global configuration file (deployment.yaml),
>
>- Each component will have their own configurations with a unique
>namespace (e.g: wso2.carbon, wso2.transports.netty etc) and it will be a
>fragment of deployment.yaml file. Please find the sample file below.
>- At runtime, the relevant config bean will be generated by overriding
>the default values specified in bean class with values mentioned in
>deployment.yaml file.
>
>
Who will generate the relevant config beans? If it's by kernel, how does
the kernel knows a bean from a product component? Will this lead to a
cyclic dependency like product component should depend on kernel and the
kernel should know the the product component to find the relevant config
bean?


>
>-
>
> Sample file looks like,
>
>   # Carbon Configuration Parameters
> wso2.carbon:
>   id: carbon-kernel
>   version: 5.2.0-SNAPSHOT
>   ports:
> offset: 0
>   ...
>
>   # Netty Transport Configurations
> wso2.transports.netty:
>   listeners:
> - id: msf4j-http
>   host: 127.0.0.1
>   port: 8080
>   bossThreadPoolSize: 2
>   workerThreadPoolSize: 250
>   parameters:
> - name: "executor.workerpool.size"
>   value: 60
>
> ...
>
> Along with the above design, we are going to introduce new annotation
> model to the configuration beans. So each component will have its
> configuration defined as one or more Java beans annotated with the
> following annotations
>
>- *org.wso2.carbon.kernel.annotations.Configuration* - *Class level
>annotation, This corresponds to a configuration bean to be used by a
>component*
>- *org.wso2.carbon.kernel.annotations.Element* - *Field level
>annotation, This corresponds to a fields of the class*
>- *org.wso2.carbon.kernel.annotations.Ignore* - *Field level
>annotation, This is to specify that field needs to be ignored when the
>configuration is generated*
>
> Sample bean class looks like,
>
> @Configuration(namespace = "wso2.carbon", description = "Carbon Configuration 
> Parameters")
> public class CarbonConfiguration {
>
> @Element(description = "value to uniquely identify a server", required = 
> true)
> private String id = "carbon-kernel";
>
> @Element(description = "server name")
> private String name = "WSO2 Carbon Kernel";
>
> @Element(description = "server version")
> private String version = "5.2.0";
>
> @Ignore
> private String tenant = Constants.DEFAULT_TENANT;
>
> ...
>
> }
>
> So we are going to generate the relevant segment of the configuration
> file(for documentation purposes) automatically at compile time by reading
> above annotations and default values.
>
> If anyone needs to override the default value, He needs to copy the
> particular segment of the configuration to the deployment.yaml and change
> the value.
>
> Appreciate your input on this.
>
> Thanks
> --
>
> *Danesh Kuruppu*
> Senior Software Engineer | WSO2
>
> Email: dan...@wso2.com
> Mobile: +94 (77) 1690552
> Web: WSO2 Inc 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks
Abimaran Kugathasan
Senior Software Engineer - API Technologies

Email : abima...@wso2.com
Mobile : +94 773922820


  
  
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Carbon C5 - Server Configuration Model

[Danesh Kuruppu]

Hi Abimaran,

Kernel going to provide the relevant config object. There will be an osgi
service to provide relevant object for the given bean class. Kernel doesn't
need to know exact bean class. We use reflection to generate the bean
class. Kernel will not dependent on any product component.

Thanks
Danesh

On Tue, Nov 29, 2016 at 10:23 PM, Abimaran Kugathasan 
wrote:

> Hi Danesh,
>
> On Mon, Nov 21, 2016 at 11:32 PM, Danesh Kuruppu  wrote:
>
>> Hi all,
>>
>> In Carbon C5, we are going to introduce new global configuration model
>> where we have only one configuration file for all server configurations.
>> So that user have to maintain only one config file for a server.
>>
>> With New Configuration Model,
>>
>>- Global configuration file (deployment.yaml) includes minimal sets
>>of configurations which need to override very often by default (e.g: 
>> server
>>ports etc).
>>- All user settable configurations must have default values and they
>>are burnt into compile codes.
>>- Any default configuration can overridden by adding the particular
>>configuration to the global configuration file(deployment.yaml).
>>- Defining all configurations in the configuration file in not
>>required. add only if we need to override the default value.
>>- If configurations are not specified in the configuration file,
>>values defined in the bean class will apply by default.
>>
>> In global configuration file (deployment.yaml),
>>
>>- Each component will have their own configurations with a unique
>>namespace (e.g: wso2.carbon, wso2.transports.netty etc) and it will be a
>>fragment of deployment.yaml file. Please find the sample file below.
>>- At runtime, the relevant config bean will be generated by
>>overriding the default values specified in bean class with values 
>> mentioned
>>in deployment.yaml file.
>>
>>
> Who will generate the relevant config beans? If it's by kernel, how does
> the kernel knows a bean from a product component? Will this lead to a
> cyclic dependency like product component should depend on kernel and the
> kernel should know the the product component to find the relevant config
> bean?
>
>
>>
>>-
>>
>> Sample file looks like,
>>
>>   # Carbon Configuration Parameters
>> wso2.carbon:
>>   id: carbon-kernel
>>   version: 5.2.0-SNAPSHOT
>>   ports:
>> offset: 0
>>   ...
>>
>>   # Netty Transport Configurations
>> wso2.transports.netty:
>>   listeners:
>> - id: msf4j-http
>>   host: 127.0.0.1
>>   port: 8080
>>   bossThreadPoolSize: 2
>>   workerThreadPoolSize: 250
>>   parameters:
>> - name: "executor.workerpool.size"
>>   value: 60
>>
>> ...
>>
>> Along with the above design, we are going to introduce new annotation
>> model to the configuration beans. So each component will have its
>> configuration defined as one or more Java beans annotated with the
>> following annotations
>>
>>- *org.wso2.carbon.kernel.annotations.Configuration* - *Class level
>>annotation, This corresponds to a configuration bean to be used by a
>>component*
>>- *org.wso2.carbon.kernel.annotations.Element* - *Field level
>>annotation, This corresponds to a fields of the class*
>>- *org.wso2.carbon.kernel.annotations.Ignore* - *Field level
>>annotation, This is to specify that field needs to be ignored when the
>>configuration is generated*
>>
>> Sample bean class looks like,
>>
>> @Configuration(namespace = "wso2.carbon", description = "Carbon 
>> Configuration Parameters")
>> public class CarbonConfiguration {
>>
>> @Element(description = "value to uniquely identify a server", required = 
>> true)
>> private String id = "carbon-kernel";
>>
>> @Element(description = "server name")
>> private String name = "WSO2 Carbon Kernel";
>>
>> @Element(description = "server version")
>> private String version = "5.2.0";
>>
>> @Ignore
>> private String tenant = Constants.DEFAULT_TENANT;
>>
>> ...
>>
>> }
>>
>> So we are going to generate the relevant segment of the configuration
>> file(for documentation purposes) automatically at compile time by reading
>> above annotations and default values.
>>
>> If anyone needs to override the default value, He needs to copy the
>> particular segment of the configuration to the deployment.yaml and change
>> the value.
>>
>> Appreciate your input on this.
>>
>> Thanks
>> --
>>
>> *Danesh Kuruppu*
>> Senior Software Engineer | WSO2
>>
>> Email: dan...@wso2.com
>> Mobile: +94 (77) 1690552
>> Web: WSO2 Inc 
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Thanks
> Abimaran Kugathasan
> Senior Software Engineer - API Technologies
>
> Email : abima...@wso2.com
> Mobile : +94 773922820 <+94%2077%20392%202820>
>
> 
> 

Re: [Architecture] Carbon C5 - Server Configuration Model

[Danesh Kuruppu]

Hi Dilan,

If all user-configurable properties are not readily available in the .yaml
> file by default, how would a user know which
> properties are configurable and which are not ?
>

All the configurable properties and their default values will be
documented. We are going to create this config document automatically by
reading the config bean class (using maven plugin).
We need to decide whether we pack those config documents in the product or
add to central location (doc page etc)

Thanks
-- 

*Danesh Kuruppu*
Senior Software Engineer | WSO2

Email: dan...@wso2.com
Mobile: +94 (77) 1690552
Web: WSO2 Inc 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Connection Pool Implementation for ESB Kafka and JMS Connectors

[Kathees Rajendram]

Hi,

I am working on connection pool implementation for Kafka [1] and JMS [2]
connectors. In the existing connectors, connections are created and closed
per message which gives the performance issue. I have improved the Kafka
connector with configurable connection pool parameter. When publishing the
messages, the maximum pool size parameter value can be changed in the
connector configuration. Now the implementation with connection pool gives
better performance.

The following results are with connection pool implementation.
Average throughput -  4980/s


*Threads & Pool Size* *Messages per a Thread* *No of Messages* *A Message
Size(byte)*
*Throughput (/s)*
10
500 5,000 106 3728
20 500 10,000 106 4757
100
2500 250,000 106 5283
100 1 1,000,000 106 4920


The following results were without connection pool implementation.
Average throughput -  2767/s

*Threads* *Messages per a Thread* *No of Messages* *A Message Size(byte)*
*Throughput (/s)*
10 500 5,000 106 1590
20 500 10,000 106 2251
100 250 25,000 106 2940
1,000 1500 1,500,000 106 2780
In my git repo [3], I have committed the connection pool implementation for
Kafka connector. Please give your suggestion.

[1] - https://wso2.org/jira/browse/ESBCONNECT-122
[2] - https://wso2.org/jira/browse/ESBCONNECT-142
[3] -
https://github.com/RKathees/esb-connector-kafka/blob/master/src/main/java/org/wso2/carbon/connector/KafkaConnectionPoolManager.java

Thanks,
Kathees
-- 
Kathees
Software Engineer,
email: kath...@wso2.com
mobile: +94772596173
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture