[Architecture] [MB] Delayed Delivery for Rejected Messages.

[Hemika Kodikara]

Hi All,

Currently when a message is being rejected by a subscriber client, the
client is able to delay returning the message to the server. This is done
by setting the "AndesAckWaitTimeOut" system property.

But the message cannot be delayed from the server side. I.E when a message
rejected is received, the message is requeued straight away to the
subscriber client.

A delay should be able to added from the server side allowing the clients
not being pushed with rejected messages.

Solution is to have a configurable value in the broker.xml which applies a
delay for each rejected message before being requeued.

Each subscription(LocalSubscription) will have a delayed queue[1] which
will store the rejected messages with the configuration value in
broker.xml. When a rejected message is received, accepting new messages
will be stopped from getting delivered to the client by using the
LocalSubscription#hasRoomToAcceptMessages() method. New messages will only
be accepted only when these rejected messages are accepted by the client or
sent to the DLC.

There will be a separate scheduled task which consists of subscriptions
that has rejected messages. The scheduler will go through each of those
subscriptions and deliver the messages to the outbound disruptor.


​

See redmine for more details[2]

[1] -
https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/DelayQueue.html
[2] - https://redmine.wso2.com/issues/5248

Regards,
Hemika

Hemika Kodikara
Software Engineer
WSO2 Inc.
lean . enterprise . middleware
http://wso2.com

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

Re: [Architecture] How do we get DAS server location?

[Gokul Balakrishnan]

Hi all,

I have completed implementation of this component, and the relevant PR may
be found at [1].

If I explain the mechanism a bit, an mDNS service is registered for the
Thrift server (i.e. DAS, CEP or product-analytics distributions), provided
that a system flag "receiverDiscoveryEnabled" is set. The service will be
automatically maintained per each network interface found on the server
node (since as explained above, we cannot infer the network interface(s)
reachable from outside the node/LAN).

A Thrift client (in this case, the EventStreamService OSGi service which is
our recommended way of publishing data to DAS/CEP/product-analytics), if
started with the same flag, is then able to discover the above service, and
it will resolve the first available Thrift endpoint through multicast DNS.
Then, its local configuration will be overwritten with the discovered
Thrift endpoint (with a log printed stating this fact). The client is then
able to send events to the Thrift server with zero configuration from the
user's part.

Questions/comments welcome.

Thanks,

[1] https://github.com/wso2/carbon-analytics-common/pull/270

On 30 June 2016 at 16:49, Gokul Balakrishnan  wrote:

> Sure Srinath. However, prior to committing, there are a few concerns with
> the approach which I think should be considered: most importantly, how we
> should resolve the hostname/IP of the Thrift server. Currently, the Thrift
> server is set to listen to all interfaces for incoming connections
> (0.0.0.0), whether valid or not. This is to overcome the earlier issues
> we've had where the Thrift server would bind to the first Network interface
> it found.
>
> On the server side, we will need to initialize the service discovery to a
> specific network interface which is also capable of accepting Thrift
> connections. The issue is that it's not possible to always guarantee that
> this interface is reachable from outside the local machine or LAN. For
> instance, the IP that we've bound to the multicast service could be from a
> virtual network interface. Normally, within a single node, this will not
> pose an issue, but overcoming this issue in a multi-node environment will
> mean maintaining a configuration which points to the correct IP which could
> accept incoming Thrift connections from outside the node (since we can't
> infer this information from the Thrift server, as it's already bound to ALL
> interfaces). This of course will negate our goal of zero configuration.
>
> The alternative is to let the analytics (server) node provide the list of
> ALL its network interfaces to the client and the client then going through
> them one by one to try and create a socket connection, to see if one or
> more them is accepting Thrift connections. This is not desirable due to
> obvious reasons.
>
> How shall we proceed?
>
> Thanks,
>
> On 30 June 2016 at 08:52, Srinath Perera  wrote:
>
>> Thanks, sound good. Please do ASAP. We are at beta, so too late even now.
>>
>> --Srinath
>>
>> On Thu, Jun 30, 2016 at 8:09 AM, Gokul Balakrishnan 
>> wrote:
>>
>>> Hi Srinath,
>>>
>>> As per our offline chat earlier, the initial plan is to locate
>>> the Thrift endpoint  through mDNS service discovery, considering the host
>>> and port first.
>>>
>>> I have used the JmDNS library pointed by Nirmal to do a PoC on this
>>> scenario, and I've also already incorporated the logic into the databridge
>>> Thrift server to enable service registration through a system property the
>>> users could set (-DenableDiscovery). The corresponding client code goes
>>> into the publisher OSGi service initialisation. This too is controllable by
>>> the same system property the user could set on the Thrift client (which
>>> will be the product talking to DAS/CEP).
>>>
>>> I'm doing some testing on the entire scenario, and once completed, I'll
>>> commit the changes into the relevant repos and send an update to this
>>> thread.
>>>
>>> Thanks,
>>>
>>>
>>> On Thursday, 30 June 2016, Srinath Perera  wrote:
>>>
 Resending as it hits a filter rule.

 Gokul, please give an update on this?

 --Srinath

>>>
>>>
>>> --
>>> Gokul Balakrishnan
>>> Senior Software Engineer,
>>> WSO2, Inc. http://wso2.com
>>> M +94 77 5935 789 | +44 7563 570502
>>>
>>>
>>>
>>
>>
>> --
>> 
>> Srinath Perera, Ph.D.
>>http://people.apache.org/~hemapani/
>>http://srinathsview.blogspot.com/
>>
>
>
>
> --
> Gokul Balakrishnan
> Senior Software Engineer,
> WSO2, Inc. http://wso2.com
> M +94 77 5935 789 | +44 7563 570502
>
>


-- 
Gokul Balakrishnan
Senior Software Engineer,
WSO2, Inc. http://wso2.com
M +94 77 5935 789 | +44 7563 570502
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Provide Support to run Jaggery apps in Tomcat Server

[Manjula Rathnayake]

Hi Nisala and Kasun,

Great. This will help us to include AS6 as a jaggery runtime in AppCloud.

thank you.

On Mon, Jul 4, 2016 at 3:04 PM, KasunG Gajasinghe  wrote:

>
>
> On Mon, Jul 4, 2016 at 1:48 PM, Nisala Nanayakkara 
> wrote:
>
>> Hi Manjula,
>>
>> Yes.Jaggery support will be inbuilt into the server with the release of
>> AS-6.0.0 next milestone. This email and documentation is provided to inform
>> the procedure of running jaggery apps in a pure tomcat server, not in the
>> AS-6.0.0. I will update the finalized documentation and configuration
>> details for AS-6.0.0 in a separate mail thread, once we finished the
>> fine-tuning process.
>>
>> Thanks,
>> Nisala
>>
>> On Mon, Jul 4, 2016 at 1:39 PM, Manjula Rathnayake 
>> wrote:
>>
>>> Hi all,
>>>
>>> IIUC, when we release the next AS-6.0.0 milestone, jaggery support is
>>> inbuilt into the server. And users do not need to follow above instructions
>>> to copy jars etc. Please correct If it is not.
>>>
>>
> Yes, that's the case. So, we need separate documentation on how to deploy
> Jaggery apps in AS6 as well.
>
>
>>
>>> thank you.
>>>
>>> On Mon, Jul 4, 2016 at 12:42 PM, Sinthuja Ragendran 
>>> wrote:
>>>
 Hi,

 Anyhow ultimately when all the carbon products move to AS 6.0 based
 platform, we can merge all those into one.

 Thanks,
 Sinthuja.

 On Mon, Jul 4, 2016 at 12:38 PM, Nisala Nanayakkara 
 wrote:

> Hi Kasun,
>
> Yes.We can do a performance round. Currently we manage the Tomcat
> Jaggery/ AS6 support code base under a new branch [1] in our jaggery
> repository. Current jaggery is based on tomcat version 7 and Tomcat 
> Jaggery
> implementation is based on tomcat version 8. So there are some api changes
> in the jaggery level. So it is difficult to manage these codebases in same
> place.
>
> Thanks,
> Nisala
>
> On Sun, Jul 3, 2016 at 9:01 AM, KasunG Gajasinghe 
> wrote:
>
>>
>> Good work Nisala.
>>
>> Can we also do a performance round to see whether there are any perf
>> gains when running Jaggery apps in vanilla Tomcat/AS6?
>>
>> How are you going to manage the codebase for Carbon vs Tomcat Jaggery
>> support? Better if we can maintain it in the same place.
>>
>> On Sat, Jul 2, 2016 at 12:51 PM, Nisala Nanayakkara 
>> wrote:
>>
>>> Hi all,
>>>
>>> This is an update regarding the feature 'Provide Support to run
>>> Jaggery apps in Tomcat Server'.
>>>
>>> At present Jaggery scripts can only be executed in a jaggery server.
>>> Because Jaggery Server which is powered by WSO2 carbon OSGi Runtime, is 
>>> the
>>> Runtime Environment that hosts Jaggery applications. The goal of this
>>> feature is to provide support to run jaggery apps in a pure tomcat 
>>> server
>>> without any modifications to the jaggery apps.This will enable 
>>> developers
>>> to write Jaggery scripts and directly deploy them in apache tomcat 
>>> server.
>>> So this will improve the flexibility of the jaggery apps.
>>>
>>> This is an extension for the Apache tomcat 8 to run the jaggery app
>>> without modifying it. Although this is implemented as a requirement of 
>>> WSO2
>>> Application Server 6, Users who want to run jaggery apps without jaggery
>>> server, can use this feature to run their jaggery apps in Apache tomcat
>>> server.
>>>
>>> I have attached the documentation and sample jaggery with this
>>> email. Please find these attachments and relevant jaggery branch 
>>> here[1].
>>> Please feel free to ask any questions.
>>>
>>> [1] - https://github.com/wso2/jaggery/tree/tomcat-8.0.x-jaggery
>>>
>>> Thanks,
>>> Nisala
>>>
>>> --
>>> *Nisala Niroshana Nanayakkara,*
>>> Software Engineer
>>> Mobile:(+94)717600022
>>> WSO2 Inc., http://wso2.com/
>>>
>>> ___
>>> Dev mailing list
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>>
>> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
>> email: kasung AT spamfree wso2.com
>> linked-in: http://lk.linkedin.com/in/gajasinghe
>> blog: http://kasunbg.org
>>
>>
>>
>
>
>
> --
> *Nisala Niroshana Nanayakkara,*
> Software Engineer
> Mobile:(+94)717600022
> WSO2 Inc., http://wso2.com/
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


 --
 *Sinthuja Rajendran*
 Technical Lead
 WSO2, Inc.:http://wso2.com

 Blog: http://sinthu-rajan.blogspot.com/
 Mobile: +94774273955

Re: [Architecture] [Dev] Provide Support to run Jaggery apps in Tomcat Server

[KasunG Gajasinghe]

On Mon, Jul 4, 2016 at 12:42 PM, Sinthuja Ragendran 
wrote:

> Hi,
>
> Anyhow ultimately when all the carbon products move to AS 6.0 based
> platform, we can merge all those into one.
>

Since, Carbon products will still be OSGi based using the embedded Tomcat,
Jaggery needs to support that as well.

As I understood, the deployment part differs mainly. ie. for AS6, you are
using a LifecycleListener; for Carbon, you have the JaggeryDeployer. The
rest can stay the same to a great extent. So, it's better if these two can
be merged into a single branch.

Thanks,
KasunG


> Thanks,
> Sinthuja.
>
> On Mon, Jul 4, 2016 at 12:38 PM, Nisala Nanayakkara 
> wrote:
>
>> Hi Kasun,
>>
>> Yes.We can do a performance round. Currently we manage the Tomcat
>> Jaggery/ AS6 support code base under a new branch [1] in our jaggery
>> repository. Current jaggery is based on tomcat version 7 and Tomcat Jaggery
>> implementation is based on tomcat version 8. So there are some api changes
>> in the jaggery level. So it is difficult to manage these codebases in same
>> place.
>>
>> Thanks,
>> Nisala
>>
>> On Sun, Jul 3, 2016 at 9:01 AM, KasunG Gajasinghe 
>> wrote:
>>
>>>
>>> Good work Nisala.
>>>
>>> Can we also do a performance round to see whether there are any perf
>>> gains when running Jaggery apps in vanilla Tomcat/AS6?
>>>
>>> How are you going to manage the codebase for Carbon vs Tomcat Jaggery
>>> support? Better if we can maintain it in the same place.
>>>
>>> On Sat, Jul 2, 2016 at 12:51 PM, Nisala Nanayakkara 
>>> wrote:
>>>
 Hi all,

 This is an update regarding the feature 'Provide Support to run Jaggery
 apps in Tomcat Server'.

 At present Jaggery scripts can only be executed in a jaggery server.
 Because Jaggery Server which is powered by WSO2 carbon OSGi Runtime, is the
 Runtime Environment that hosts Jaggery applications. The goal of this
 feature is to provide support to run jaggery apps in a pure tomcat server
 without any modifications to the jaggery apps.This will enable developers
 to write Jaggery scripts and directly deploy them in apache tomcat server.
 So this will improve the flexibility of the jaggery apps.

 This is an extension for the Apache tomcat 8 to run the jaggery app
 without modifying it. Although this is implemented as a requirement of WSO2
 Application Server 6, Users who want to run jaggery apps without jaggery
 server, can use this feature to run their jaggery apps in Apache tomcat
 server.

 I have attached the documentation and sample jaggery with this email.
 Please find these attachments and relevant jaggery branch here[1]. Please
 feel free to ask any questions.

 [1] - https://github.com/wso2/jaggery/tree/tomcat-8.0.x-jaggery

 Thanks,
 Nisala

 --
 *Nisala Niroshana Nanayakkara,*
 Software Engineer
 Mobile:(+94)717600022
 WSO2 Inc., http://wso2.com/

 ___
 Dev mailing list
 d...@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>>
>>> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
>>> email: kasung AT spamfree wso2.com
>>> linked-in: http://lk.linkedin.com/in/gajasinghe
>>> blog: http://kasunbg.org
>>>
>>>
>>>
>>
>>
>>
>> --
>> *Nisala Niroshana Nanayakkara,*
>> Software Engineer
>> Mobile:(+94)717600022
>> WSO2 Inc., http://wso2.com/
>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Sinthuja Rajendran*
> Technical Lead
> WSO2, Inc.:http://wso2.com
>
> Blog: http://sinthu-rajan.blogspot.com/
> Mobile: +94774273955
>
>
>


-- 

*Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
email: kasung AT spamfree wso2.com
linked-in: http://lk.linkedin.com/in/gajasinghe
blog: http://kasunbg.org
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Provide Support to run Jaggery apps in Tomcat Server

[KasunG Gajasinghe]

On Mon, Jul 4, 2016 at 1:48 PM, Nisala Nanayakkara  wrote:

> Hi Manjula,
>
> Yes.Jaggery support will be inbuilt into the server with the release of
> AS-6.0.0 next milestone. This email and documentation is provided to inform
> the procedure of running jaggery apps in a pure tomcat server, not in the
> AS-6.0.0. I will update the finalized documentation and configuration
> details for AS-6.0.0 in a separate mail thread, once we finished the
> fine-tuning process.
>
> Thanks,
> Nisala
>
> On Mon, Jul 4, 2016 at 1:39 PM, Manjula Rathnayake 
> wrote:
>
>> Hi all,
>>
>> IIUC, when we release the next AS-6.0.0 milestone, jaggery support is
>> inbuilt into the server. And users do not need to follow above instructions
>> to copy jars etc. Please correct If it is not.
>>
>
Yes, that's the case. So, we need separate documentation on how to deploy
Jaggery apps in AS6 as well.


>
>> thank you.
>>
>> On Mon, Jul 4, 2016 at 12:42 PM, Sinthuja Ragendran 
>> wrote:
>>
>>> Hi,
>>>
>>> Anyhow ultimately when all the carbon products move to AS 6.0 based
>>> platform, we can merge all those into one.
>>>
>>> Thanks,
>>> Sinthuja.
>>>
>>> On Mon, Jul 4, 2016 at 12:38 PM, Nisala Nanayakkara 
>>> wrote:
>>>
 Hi Kasun,

 Yes.We can do a performance round. Currently we manage the Tomcat
 Jaggery/ AS6 support code base under a new branch [1] in our jaggery
 repository. Current jaggery is based on tomcat version 7 and Tomcat Jaggery
 implementation is based on tomcat version 8. So there are some api changes
 in the jaggery level. So it is difficult to manage these codebases in same
 place.

 Thanks,
 Nisala

 On Sun, Jul 3, 2016 at 9:01 AM, KasunG Gajasinghe 
 wrote:

>
> Good work Nisala.
>
> Can we also do a performance round to see whether there are any perf
> gains when running Jaggery apps in vanilla Tomcat/AS6?
>
> How are you going to manage the codebase for Carbon vs Tomcat Jaggery
> support? Better if we can maintain it in the same place.
>
> On Sat, Jul 2, 2016 at 12:51 PM, Nisala Nanayakkara 
> wrote:
>
>> Hi all,
>>
>> This is an update regarding the feature 'Provide Support to run
>> Jaggery apps in Tomcat Server'.
>>
>> At present Jaggery scripts can only be executed in a jaggery server.
>> Because Jaggery Server which is powered by WSO2 carbon OSGi Runtime, is 
>> the
>> Runtime Environment that hosts Jaggery applications. The goal of this
>> feature is to provide support to run jaggery apps in a pure tomcat server
>> without any modifications to the jaggery apps.This will enable developers
>> to write Jaggery scripts and directly deploy them in apache tomcat 
>> server.
>> So this will improve the flexibility of the jaggery apps.
>>
>> This is an extension for the Apache tomcat 8 to run the jaggery app
>> without modifying it. Although this is implemented as a requirement of 
>> WSO2
>> Application Server 6, Users who want to run jaggery apps without jaggery
>> server, can use this feature to run their jaggery apps in Apache tomcat
>> server.
>>
>> I have attached the documentation and sample jaggery with this email.
>> Please find these attachments and relevant jaggery branch here[1]. Please
>> feel free to ask any questions.
>>
>> [1] - https://github.com/wso2/jaggery/tree/tomcat-8.0.x-jaggery
>>
>> Thanks,
>> Nisala
>>
>> --
>> *Nisala Niroshana Nanayakkara,*
>> Software Engineer
>> Mobile:(+94)717600022
>> WSO2 Inc., http://wso2.com/
>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
>
> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
> email: kasung AT spamfree wso2.com
> linked-in: http://lk.linkedin.com/in/gajasinghe
> blog: http://kasunbg.org
>
>
>



 --
 *Nisala Niroshana Nanayakkara,*
 Software Engineer
 Mobile:(+94)717600022
 WSO2 Inc., http://wso2.com/

 ___
 Dev mailing list
 d...@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>> *Sinthuja Rajendran*
>>> Technical Lead
>>> WSO2, Inc.:http://wso2.com
>>>
>>> Blog: http://sinthu-rajan.blogspot.com/
>>> Mobile: +94774273955
>>>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Manjula Rathnayaka
>> Associate Technical Lead
>> WSO2, Inc.
>> Mobile:+94 77 743 1987
>>
>
>
>
> --
> *Nisala Niroshana Nanayakkara,*
> Software Engineer
> 

Re: [Architecture] [Dev] Provide Support to run Jaggery apps in Tomcat Server

[Nisala Nanayakkara]

Hi Manjula,

Yes.Jaggery support will be inbuilt into the server with the release of
AS-6.0.0 next milestone. This email and documentation is provided to inform
the procedure of running jaggery apps in a pure tomcat server, not in the
AS-6.0.0. I will update the finalized documentation and configuration
details for AS-6.0.0 in a separate mail thread, once we finished the
fine-tuning process.

Thanks,
Nisala

On Mon, Jul 4, 2016 at 1:39 PM, Manjula Rathnayake 
wrote:

> Hi all,
>
> IIUC, when we release the next AS-6.0.0 milestone, jaggery support is
> inbuilt into the server. And users do not need to follow above instructions
> to copy jars etc. Please correct If it is not.
>
> thank you.
>
> On Mon, Jul 4, 2016 at 12:42 PM, Sinthuja Ragendran 
> wrote:
>
>> Hi,
>>
>> Anyhow ultimately when all the carbon products move to AS 6.0 based
>> platform, we can merge all those into one.
>>
>> Thanks,
>> Sinthuja.
>>
>> On Mon, Jul 4, 2016 at 12:38 PM, Nisala Nanayakkara 
>> wrote:
>>
>>> Hi Kasun,
>>>
>>> Yes.We can do a performance round. Currently we manage the Tomcat
>>> Jaggery/ AS6 support code base under a new branch [1] in our jaggery
>>> repository. Current jaggery is based on tomcat version 7 and Tomcat Jaggery
>>> implementation is based on tomcat version 8. So there are some api changes
>>> in the jaggery level. So it is difficult to manage these codebases in same
>>> place.
>>>
>>> Thanks,
>>> Nisala
>>>
>>> On Sun, Jul 3, 2016 at 9:01 AM, KasunG Gajasinghe 
>>> wrote:
>>>

 Good work Nisala.

 Can we also do a performance round to see whether there are any perf
 gains when running Jaggery apps in vanilla Tomcat/AS6?

 How are you going to manage the codebase for Carbon vs Tomcat Jaggery
 support? Better if we can maintain it in the same place.

 On Sat, Jul 2, 2016 at 12:51 PM, Nisala Nanayakkara 
 wrote:

> Hi all,
>
> This is an update regarding the feature 'Provide Support to run
> Jaggery apps in Tomcat Server'.
>
> At present Jaggery scripts can only be executed in a jaggery server.
> Because Jaggery Server which is powered by WSO2 carbon OSGi Runtime, is 
> the
> Runtime Environment that hosts Jaggery applications. The goal of this
> feature is to provide support to run jaggery apps in a pure tomcat server
> without any modifications to the jaggery apps.This will enable developers
> to write Jaggery scripts and directly deploy them in apache tomcat server.
> So this will improve the flexibility of the jaggery apps.
>
> This is an extension for the Apache tomcat 8 to run the jaggery app
> without modifying it. Although this is implemented as a requirement of 
> WSO2
> Application Server 6, Users who want to run jaggery apps without jaggery
> server, can use this feature to run their jaggery apps in Apache tomcat
> server.
>
> I have attached the documentation and sample jaggery with this email.
> Please find these attachments and relevant jaggery branch here[1]. Please
> feel free to ask any questions.
>
> [1] - https://github.com/wso2/jaggery/tree/tomcat-8.0.x-jaggery
>
> Thanks,
> Nisala
>
> --
> *Nisala Niroshana Nanayakkara,*
> Software Engineer
> Mobile:(+94)717600022
> WSO2 Inc., http://wso2.com/
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


 --

 *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
 email: kasung AT spamfree wso2.com
 linked-in: http://lk.linkedin.com/in/gajasinghe
 blog: http://kasunbg.org



>>>
>>>
>>>
>>> --
>>> *Nisala Niroshana Nanayakkara,*
>>> Software Engineer
>>> Mobile:(+94)717600022
>>> WSO2 Inc., http://wso2.com/
>>>
>>> ___
>>> Dev mailing list
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Sinthuja Rajendran*
>> Technical Lead
>> WSO2, Inc.:http://wso2.com
>>
>> Blog: http://sinthu-rajan.blogspot.com/
>> Mobile: +94774273955
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Manjula Rathnayaka
> Associate Technical Lead
> WSO2, Inc.
> Mobile:+94 77 743 1987
>



-- 
*Nisala Niroshana Nanayakkara,*
Software Engineer
Mobile:(+94)717600022
WSO2 Inc., http://wso2.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Provide Support to run Jaggery apps in Tomcat Server

[Sinthuja Ragendran]

Hi,

Anyhow ultimately when all the carbon products move to AS 6.0 based
platform, we can merge all those into one.

Thanks,
Sinthuja.

On Mon, Jul 4, 2016 at 12:38 PM, Nisala Nanayakkara  wrote:

> Hi Kasun,
>
> Yes.We can do a performance round. Currently we manage the Tomcat Jaggery/
> AS6 support code base under a new branch [1] in our jaggery repository.
> Current jaggery is based on tomcat version 7 and Tomcat Jaggery
> implementation is based on tomcat version 8. So there are some api changes
> in the jaggery level. So it is difficult to manage these codebases in same
> place.
>
> Thanks,
> Nisala
>
> On Sun, Jul 3, 2016 at 9:01 AM, KasunG Gajasinghe  wrote:
>
>>
>> Good work Nisala.
>>
>> Can we also do a performance round to see whether there are any perf
>> gains when running Jaggery apps in vanilla Tomcat/AS6?
>>
>> How are you going to manage the codebase for Carbon vs Tomcat Jaggery
>> support? Better if we can maintain it in the same place.
>>
>> On Sat, Jul 2, 2016 at 12:51 PM, Nisala Nanayakkara 
>> wrote:
>>
>>> Hi all,
>>>
>>> This is an update regarding the feature 'Provide Support to run Jaggery
>>> apps in Tomcat Server'.
>>>
>>> At present Jaggery scripts can only be executed in a jaggery server.
>>> Because Jaggery Server which is powered by WSO2 carbon OSGi Runtime, is the
>>> Runtime Environment that hosts Jaggery applications. The goal of this
>>> feature is to provide support to run jaggery apps in a pure tomcat server
>>> without any modifications to the jaggery apps.This will enable developers
>>> to write Jaggery scripts and directly deploy them in apache tomcat server.
>>> So this will improve the flexibility of the jaggery apps.
>>>
>>> This is an extension for the Apache tomcat 8 to run the jaggery app
>>> without modifying it. Although this is implemented as a requirement of WSO2
>>> Application Server 6, Users who want to run jaggery apps without jaggery
>>> server, can use this feature to run their jaggery apps in Apache tomcat
>>> server.
>>>
>>> I have attached the documentation and sample jaggery with this email.
>>> Please find these attachments and relevant jaggery branch here[1]. Please
>>> feel free to ask any questions.
>>>
>>> [1] - https://github.com/wso2/jaggery/tree/tomcat-8.0.x-jaggery
>>>
>>> Thanks,
>>> Nisala
>>>
>>> --
>>> *Nisala Niroshana Nanayakkara,*
>>> Software Engineer
>>> Mobile:(+94)717600022
>>> WSO2 Inc., http://wso2.com/
>>>
>>> ___
>>> Dev mailing list
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>>
>> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
>> email: kasung AT spamfree wso2.com
>> linked-in: http://lk.linkedin.com/in/gajasinghe
>> blog: http://kasunbg.org
>>
>>
>>
>
>
>
> --
> *Nisala Niroshana Nanayakkara,*
> Software Engineer
> Mobile:(+94)717600022
> WSO2 Inc., http://wso2.com/
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Sinthuja Rajendran*
Technical Lead
WSO2, Inc.:http://wso2.com

Blog: http://sinthu-rajan.blogspot.com/
Mobile: +94774273955
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Provide Support to run Jaggery apps in Tomcat Server

[Nisala Nanayakkara]

Hi Kasun,

Yes.We can do a performance round. Currently we manage the Tomcat Jaggery/
AS6 support code base under a new branch [1] in our jaggery repository.
Current jaggery is based on tomcat version 7 and Tomcat Jaggery
implementation is based on tomcat version 8. So there are some api changes
in the jaggery level. So it is difficult to manage these codebases in same
place.

Thanks,
Nisala

On Sun, Jul 3, 2016 at 9:01 AM, KasunG Gajasinghe  wrote:

>
> Good work Nisala.
>
> Can we also do a performance round to see whether there are any perf gains
> when running Jaggery apps in vanilla Tomcat/AS6?
>
> How are you going to manage the codebase for Carbon vs Tomcat Jaggery
> support? Better if we can maintain it in the same place.
>
> On Sat, Jul 2, 2016 at 12:51 PM, Nisala Nanayakkara 
> wrote:
>
>> Hi all,
>>
>> This is an update regarding the feature 'Provide Support to run Jaggery
>> apps in Tomcat Server'.
>>
>> At present Jaggery scripts can only be executed in a jaggery server.
>> Because Jaggery Server which is powered by WSO2 carbon OSGi Runtime, is the
>> Runtime Environment that hosts Jaggery applications. The goal of this
>> feature is to provide support to run jaggery apps in a pure tomcat server
>> without any modifications to the jaggery apps.This will enable developers
>> to write Jaggery scripts and directly deploy them in apache tomcat server.
>> So this will improve the flexibility of the jaggery apps.
>>
>> This is an extension for the Apache tomcat 8 to run the jaggery app
>> without modifying it. Although this is implemented as a requirement of WSO2
>> Application Server 6, Users who want to run jaggery apps without jaggery
>> server, can use this feature to run their jaggery apps in Apache tomcat
>> server.
>>
>> I have attached the documentation and sample jaggery with this email.
>> Please find these attachments and relevant jaggery branch here[1]. Please
>> feel free to ask any questions.
>>
>> [1] - https://github.com/wso2/jaggery/tree/tomcat-8.0.x-jaggery
>>
>> Thanks,
>> Nisala
>>
>> --
>> *Nisala Niroshana Nanayakkara,*
>> Software Engineer
>> Mobile:(+94)717600022
>> WSO2 Inc., http://wso2.com/
>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
>
> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
> email: kasung AT spamfree wso2.com
> linked-in: http://lk.linkedin.com/in/gajasinghe
> blog: http://kasunbg.org
>
>
>



-- 
*Nisala Niroshana Nanayakkara,*
Software Engineer
Mobile:(+94)717600022
WSO2 Inc., http://wso2.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Supporting coordination for non worker-manager clusters

[Rajith Vitharana]

Hi All,

Public jira for this is [1], and documentation jira is [2]

[1] - https://wso2.org/jira/browse/ESBJAVA-4677
[2] - https://wso2.org/jira/browse/DOCUMENTATION-3554

Thanks,

On Mon, Jul 4, 2016 at 12:04 PM, Rajith Vitharana  wrote:

> Hi All,
>
> This is done as mentioned in previous mail with git pull [1], [2],
> currently we just identify clustering pattern as *not* "WorkerManager"
> for ESB task purposes, hence may need to come up with other possible
> pattern names in future.
>
> [1] - https://github.com/wso2/carbon-mediation/pull/652
> 
> [2] - https://github.com/wso2/product-esb/pull/551
>
> Thanks,
>
> On Fri, Jul 1, 2016 at 7:43 AM, Isuru Udana  wrote:
>
>> Hi All,
>>
>> In ESB 4.9.0, we introduced coordination for following features
>> - Scheduled Tasks
>> - Inbound Endpoints
>> - Message Processors
>>
>> In all these features coordination is implemented tightly coupling to the
>> worker-manager deployment pattern.
>>
>> But we have the requirement to support coordination for clusters which is
>> not following the worker-manager deployment pattern.
>>
>> Currently we are executing a task in a node by looking at following logic.
>>
>> IF  clustered == False OR worker-node == True
>>execute = true
>> ELSE
>>execute = false
>>
>> So if a node belongs to a cluster, it must be a worker node. We identify
>> the worker node by looking at the -DworkerNode=true argument.
>> Ideally we should identify the manager node and stop executing the task
>> for that, but unfortunately there is no way to do that.
>>
>> So to support coordination for clusters which are not clustered in worker
>> manager pattern, we need to identify the clustering pattern.
>>
>> So we thought of introducing a new parameter for the clustering
>> configuration in axis2.xml.
>>
>>  WorkerManager
>>
>> We had an offline discussion on this with Azeez and Sagara as well, it
>> seems like this is the best possible way we can handle this for the moment.
>>
>> Thanks,
>> IsuruU
>>
>> --
>> *Isuru Udana*
>> Technical Lead
>> WSO2 Inc.; http://wso2.com
>> email: isu...@wso2.com cell: +94 77 3791887
>> blog: http://mytecheye.blogspot.com/
>>
>
>
>
> --
> Rajith Vitharana
>
> Software Engineer,
> WSO2 Inc. : wso2.com
> Mobile : +94715883223
> Blog : http://lankavitharana.blogspot.com/
>



-- 
Rajith Vitharana

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94715883223
Blog : http://lankavitharana.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Supporting coordination for non worker-manager clusters

[Rajith Vitharana]

Hi All,

This is done as mentioned in previous mail with git pull [1], [2],
currently we just identify clustering pattern as *not* "WorkerManager" for
ESB task purposes, hence may need to come up with other possible pattern
names in future.

[1] - https://github.com/wso2/carbon-mediation/pull/652

[2] - https://github.com/wso2/product-esb/pull/551

Thanks,

On Fri, Jul 1, 2016 at 7:43 AM, Isuru Udana  wrote:

> Hi All,
>
> In ESB 4.9.0, we introduced coordination for following features
> - Scheduled Tasks
> - Inbound Endpoints
> - Message Processors
>
> In all these features coordination is implemented tightly coupling to the
> worker-manager deployment pattern.
>
> But we have the requirement to support coordination for clusters which is
> not following the worker-manager deployment pattern.
>
> Currently we are executing a task in a node by looking at following logic.
>
> IF  clustered == False OR worker-node == True
>execute = true
> ELSE
>execute = false
>
> So if a node belongs to a cluster, it must be a worker node. We identify
> the worker node by looking at the -DworkerNode=true argument.
> Ideally we should identify the manager node and stop executing the task
> for that, but unfortunately there is no way to do that.
>
> So to support coordination for clusters which are not clustered in worker
> manager pattern, we need to identify the clustering pattern.
>
> So we thought of introducing a new parameter for the clustering
> configuration in axis2.xml.
>
>  WorkerManager
>
> We had an offline discussion on this with Azeez and Sagara as well, it
> seems like this is the best possible way we can handle this for the moment.
>
> Thanks,
> IsuruU
>
> --
> *Isuru Udana*
> Technical Lead
> WSO2 Inc.; http://wso2.com
> email: isu...@wso2.com cell: +94 77 3791887
> blog: http://mytecheye.blogspot.com/
>



-- 
Rajith Vitharana

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94715883223
Blog : http://lankavitharana.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture