can we use a block on carbon.xml for configuring throttle persistence
support and the jndi URL? Something like the following...
<throttling-configuration>
<enable-throttle-persistence>true</enable-throttle-persistence>
<jndiConfig>
<name>jdbc/WSO2CarbonDB</name>
</jndiConfig>
</throttling-configuration>
wdyt?
Manoj
On Wed, Jan 29, 2014 at 9:11 PM, Manoj Fernando <[email protected]> wrote:
> Initially I thought the cluster awareness plays a role in throttle
> decision making within a cluster, but now I see that was a bit of a silly
> thought :). The ClusterAwareCallerContext can accommodate the additional
> info needed for cluster replication.
> +1. We will have one decision engine.
>
> Regards,
> Manoj
>
>
> On Wed, Jan 29, 2014 at 5:17 PM, Afkham Azeez <[email protected]> wrote:
>
>> Again, we don't need 2 engines, and an AbstractEngine. Depending on
>> whether Hazelcast is available or not, the engine will work accordingly. We
>> need a single class. Better to keep things simple.
>>
>> Azeez
>>
>>
>> On Wed, Jan 29, 2014 at 1:36 PM, Manoj Fernando <[email protected]> wrote:
>>
>>> @Sanjeewa - Yes, we will have to consider the policy loading part as
>>> well (basically to instantiate a CallerConfiguration object based on
>>> throttling policies).
>>>
>>> Throttle replication and Counter updating is indeed a task of the
>>> engine. We have basically created 2 engine
>>> implementations... ClusterAwareThrottleDecisionEngine
>>> and SimpleThrottleDecisionEngine, The former will depend on an
>>> ExecutorService to plumb with Hazelcast to maintain a cluster wide counter.
>>>
>>> Regards,
>>> Manoj
>>>
>>>
>>> On Tue, Jan 28, 2014 at 11:43 AM, Sanjeewa Malalgoda
>>> <[email protected]>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jan 28, 2014 at 7:31 AM, Manoj Fernando <[email protected]>wrote:
>>>>
>>>>> Thought of some improvements.
>>>>>
>>>>> - We shall have an AbstractThrottleDecisionEngine so that we can
>>>>> extend the core to support various decision engines later on (to
>>>>> accommodate suggestions from Suho and Senaka).
>>>>>
>>>> +1 for doing this. Then we might need methods like
>>>> loadThrottlingPolicy(Policy throttlePolicy) and canAccess(ThrottleContext
>>>> context). Then we can call underlying throttle engine with necessary data
>>>> and data format(based on throttle engine implementation - it can be either
>>>> siddhi based engine or current throttling implementation). AFAIU
>>>> replication and counter updating should be a task of throttle decision
>>>> engine. WDYT?
>>>>
>>>> Thanks,
>>>> sanjeewa.
>>>>
>>>>> - Make CallerContext abstract so extend into ClusterAwareCallerContext
>>>>> and SingleNodeCallerContext.
>>>>>
>>>>> Regards,
>>>>> Manoj
>>>>>
>>>>>
>>>>> On Mon, Jan 27, 2014 at 5:33 PM, Manoj Fernando <[email protected]>wrote:
>>>>>
>>>>>> Initial code checked in @
>>>>>> http://svn.wso2.org/repos/wso2/people/manojf .
>>>>>>
>>>>>> Next : implementing periodic counter replication, persistence.
>>>>>>
>>>>>> - Manoj
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 27, 2014 at 9:16 AM, Srinath Perera <[email protected]>wrote:
>>>>>>
>>>>>>> Hi Suho,
>>>>>>>
>>>>>>> I think we need throttling to work without having to run a
>>>>>>> distributed CEP. Using Siddhi is fine, as that is transparent, but need
>>>>>>> for
>>>>>>> Strom to run thottling usecae is too much IMO.
>>>>>>>
>>>>>>> --Srinath
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 3, 2014 at 4:55 PM, Sriskandarajah Suhothayan <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Is there any possibility of using Distributed CEP/Siddhi here?
>>>>>>>> Because with Siddhi we can have some flexibility in the way we want to
>>>>>>>> throttle and throttling is a common usecase of CEP. Its underline
>>>>>>>> architecture also uses Hazelcast or Storm for distributed processing.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Suho
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Dec 24, 2013 at 8:54 AM, Manoj Fernando <[email protected]>wrote:
>>>>>>>>
>>>>>>>>> +1. Changing caller contexts in to a Hazlecast map would require
>>>>>>>>> some significant changes to the throttle core, which may eventually be
>>>>>>>>> re-written.
>>>>>>>>>
>>>>>>>>> Will update the design.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Manoj
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Dec 23, 2013 at 4:09 PM, Srinath Perera
>>>>>>>>> <[email protected]>wrote:
>>>>>>>>>
>>>>>>>>>> Manoj, above plan look good.
>>>>>>>>>>
>>>>>>>>>> I chatted with Azeez, and we cannot register a Entry listener as
>>>>>>>>>> I mentioned before because hazecast does not support entry listeners
>>>>>>>>>> for
>>>>>>>>>> atomic long.
>>>>>>>>>>
>>>>>>>>>> --Srinath
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Dec 23, 2013 at 11:15 AM, Manoj Fernando <[email protected]
>>>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>>> Short update after the discussion with Azeez.
>>>>>>>>>>>
>>>>>>>>>>> - The need to re-write the throttle core is still at large, so
>>>>>>>>>>> the best was to see how we can decouple the persistence logic from
>>>>>>>>>>> the
>>>>>>>>>>> throttle core (at least as much as possible).
>>>>>>>>>>> - A cluster updatable global counter will be included to the
>>>>>>>>>>> ThrottleContext. The idea is that each node will periodically
>>>>>>>>>>> broadcast
>>>>>>>>>>> the local counter info to the members in the cluster and the
>>>>>>>>>>> ThrottleConfiguration will update the value of the Global counter
>>>>>>>>>>> summing
>>>>>>>>>>> up the local counter values.
>>>>>>>>>>> - The ThrottleConfiguration will also push the global counter
>>>>>>>>>>> values to the Axis2 Configuration Context; a K, V pairs identified
>>>>>>>>>>> by the
>>>>>>>>>>> ThrottleContext ID.
>>>>>>>>>>> - A new platform component needs to be written to read the
>>>>>>>>>>> throttle related Axis2 Config Context list and persist them
>>>>>>>>>>> periodically
>>>>>>>>>>> (duration configurable). The throttle core will have no visibility
>>>>>>>>>>> into
>>>>>>>>>>> this persistence logic, so this will be completely decoupled.
>>>>>>>>>>> - So who should do the persistence? We can start with letting
>>>>>>>>>>> all nodes to persist first, but later (or in parallel) we can
>>>>>>>>>>> improve the
>>>>>>>>>>> Hazlecast's leader election (if that's not already there), so that
>>>>>>>>>>> the
>>>>>>>>>>> leader takes the responsibility of persisting.
>>>>>>>>>>> - The counters will be read off the persistence store at the
>>>>>>>>>>> time of Hazlecast Leader election takes place? (An alternative is
>>>>>>>>>>> to load
>>>>>>>>>>> the global counters at the init of ThrottleConfiguration but that
>>>>>>>>>>> means
>>>>>>>>>>> coupling throttle core with persistence.)
>>>>>>>>>>>
>>>>>>>>>>> I will update the design accordingly.
>>>>>>>>>>>
>>>>>>>>>>> Any more thoughts or suggestions?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Manoj
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Dec 19, 2013 at 12:30 PM, Manoj Fernando <
>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> +1. Let me setup a time.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Manoj
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thursday, December 19, 2013, Srinath Perera wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> We need Azeez's feedback. Shall you, myself, and Azeez chat
>>>>>>>>>>>>> sometime and decide on the first Arch design?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Dec 19, 2013 at 11:55 AM, Manoj Fernando <
>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Srinath,
>>>>>>>>>>>>>
>>>>>>>>>>>>> That sounds like a much cleaner solution. We can perhaps use
>>>>>>>>>>>>> the native map-store declarative [1] which I think does something
>>>>>>>>>>>>> similar.
>>>>>>>>>>>>> It may sound a little silly to ask... but are we keeping
>>>>>>>>>>>>> Hazlecast active
>>>>>>>>>>>>> on a single node environment as well? :) Otherwise we will have
>>>>>>>>>>>>> to handle
>>>>>>>>>>>>> persistence on a single node in a different way. This is with
>>>>>>>>>>>>> the
>>>>>>>>>>>>> assumption of needing to persist throttle data on a single node
>>>>>>>>>>>>> environment
>>>>>>>>>>>>> as well (but questioning if we really need to do that is not
>>>>>>>>>>>>> totally
>>>>>>>>>>>>> invalid IMO).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Shall we go ahead with the Hazlecast option targeting cluster
>>>>>>>>>>>>> deployments then?
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Manoj
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] https://code.google.com/p/hazelcast/wiki/MapPersistence
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Dec 19, 2013 at 10:51 AM, Srinath Perera <
>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> One another way to do this use Hazelcast and then use "though
>>>>>>>>>>>>> cache" or "Change listener's" in Hazecast for persistence.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --Srinath
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Dec 17, 2013 at 4:49 PM, Manoj Fernando <
>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> +1 for persisting through a single (elected?) node, and let
>>>>>>>>>>>>> Hazlecast do the replication.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I took into consideration the need to persist periodically
>>>>>>>>>>>>> instead of at each and every request (by spawning a separate
>>>>>>>>>>>>> thread that
>>>>>>>>>>>>> has access to the callerContext map)... so yes... we should
>>>>>>>>>>>>> think in the
>>>>>>>>>>>>> same way for replicating the counters across the cluster as well.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Instead of using a global counter, can we perhaps use the last
>>>>>>>>>>>>> updated timestamp of each CallerContext? It's actually not a
>>>>>>>>>>>>> single
>>>>>>>>>>>>> counter we need to deal with, and each CallerContext instance
>>>>>>>>>>>>> will have
>>>>>>>>>>>>> separate counters mapped to their throttling policy AFAIK.
>>>>>>>>>>>>> Therefore, I
>>>>>>>>>>>>> think its probably better to update CallerContext instances based
>>>>>>>>>>>>> on the
>>>>>>>>>>>>> last update timestamp.
>>>>>>>>>>>>>
>>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>>
>>>>>>>>>>>>> If agree, then I need to figure out how to make delayed
>>>>>>>>>>>>> replication on hazlecast (is it through
>>>>>>>>>>>>> the hazelcast.heartbeat.interval.seconds config item?)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Manoj
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Dec 17, 2013 at 4:22 PM, Srinath Perera <
>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> We need to think it a cluster setup do we need persistence as
>>>>>>>>>>>>> well? As we can have replication using Hazelcast?
>>>>>>>>>>>>>
>>>>>>>>>>>>> If we need persistence, I think it is a good if a single node
>>>>>>>>>>>>> persists the current throttling values, and if that node fails,
>>>>>>>>>>>>> someone
>>>>>>>>>>>>> else takes it place?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Current implementation sync the values across the cluster per
>>>>>>>>>>>>> each message, which introduce significant overhead. I think we
>>>>>>>>>>>>> should go to
>>>>>>>>>>>>> a model where each node collects and update the values once few
>>>>>>>>>>>>> seconds.
>>>>>>>>>>>>>
>>>>>>>>>>>>> idea is
>>>>>>>>>>>>> 1) there is a global counter, that we use to throttle
>>>>>>>>>>>>> 2) Each node keep a global counter, and periodically it update
>>>>>>>>>>>>> the global counter using value in location counter and reset the
>>>>>>>>>>>>> counter
>>>>>>>>>>>>> and read the current global counter.
>>>>>>>>>>>>> 3) Until next update, each node make decisions based on local
>>>>>>>>>>>>> global counter values it has read already
>>>>>>>>>>>>>
>>>>>>>>>>>>> This will mean that the throttling will throttle close to the
>>>>>>>>>>>>> limit, not exactly at the limit. However, IMHO, that is not a
>>>>>>>>>>>>> problem for
>>>>>>>>>>>>> throttling usecase.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --Srinath
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Dec 16, 2013 at 7:20 PM, Manoj Fernando <
>>>>>>>>>>>>> [email protected]> wrot
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Manoj Fernando
>>>>>>>>>>>> Director - Solutions Architecture
>>>>>>>>>>>>
>>>>>>>>>>>> Contact:
>>>>>>>>>>>> LK - +94 112 145345
>>>>>>>>>>>> Mob: +94 773 759340
>>>>>>>>>>>> www.wso2.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Manoj Fernando
>>>>>>>>>>> Director - Solutions Architecture
>>>>>>>>>>>
>>>>>>>>>>> Contact:
>>>>>>>>>>> LK - +94 112 145345
>>>>>>>>>>> Mob: +94 773 759340
>>>>>>>>>>> www.wso2.com
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> ============================
>>>>>>>>>> Srinath Perera, Ph.D.
>>>>>>>>>> http://people.apache.org/~hemapani/
>>>>>>>>>> http://srinathsview.blogspot.com/
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Manoj Fernando
>>>>>>>>> Director - Solutions Architecture
>>>>>>>>>
>>>>>>>>> Contact:
>>>>>>>>> LK - +94 112 145345
>>>>>>>>> Mob: +94 773 759340
>>>>>>>>> www.wso2.com
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Architecture mailing list
>>>>>>>>> [email protected]
>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> *S. Suhothayan *
>>>>>>>> Associate Technical Lead,
>>>>>>>> *WSO2 Inc. *http://wso2.com
>>>>>>>> * <http://wso2.com/>*
>>>>>>>> lean . enterprise . middleware
>>>>>>>>
>>>>>>>>
>>>>>>>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog:
>>>>>>>> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>
>>>>>>>> twitter:
>>>>>>>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> |
>>>>>>>> linked-in:
>>>>>>>> http://lk.linkedin.com/in/suhothayan
>>>>>>>> <http://lk.linkedin.com/in/suhothayan>*
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ============================
>>>>>>> Srinath Perera, Ph.D.
>>>>>>>
>>>>>>> Director, Research, WSO2 Inc.
>>>>>>> Visiting Faculty, University of Moratuwa
>>>>>>> Member, Apache Software Foundation
>>>>>>> Research Scientist, Lanka Software Foundation
>>>>>>> Blog: http://srinathsview.blogspot.com/
>>>>>>> Photos: http://www.flickr.com/photos/hemapani/
>>>>>>> Phone: 0772360902
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Architecture mailing list
>>>>>>> [email protected]
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Manoj Fernando
>>>>>> Director - Solutions Architecture
>>>>>>
>>>>>> Contact:
>>>>>> LK - +94 112 145345
>>>>>> Mob: +94 773 759340
>>>>>> www.wso2.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Manoj Fernando
>>>>> Director - Solutions Architecture
>>>>>
>>>>> Contact:
>>>>> LK - +94 112 145345
>>>>> Mob: +94 773 759340
>>>>> www.wso2.com
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> [email protected]
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Sanjeewa Malalgoda*
>>>> Senior Software Engineer
>>>> WSO2 Inc.
>>>> Mobile : +94713068779
>>>>
>>>> <http://sanjeewamalalgoda.blogspot.com/>blog
>>>> :http://sanjeewamalalgoda.blogspot.com/<http://sanjeewamalalgoda.blogspot.com/>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> [email protected]
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Manoj Fernando
>>> Director - Solutions Architecture
>>>
>>> Contact:
>>> LK - +94 112 145345
>>> Mob: +94 773 759340
>>> www.wso2.com
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Afkham Azeez*
>> Director of Architecture; WSO2, Inc.; http://wso2.com
>> Member; Apache Software Foundation; http://www.apache.org/
>> * <http://www.apache.org/>*
>> *email: **[email protected]* <[email protected]>
>> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: *
>> *http://blog.afkham.org* <http://blog.afkham.org>
>> *twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
>> * linked-in: **http://lk.linkedin.com/in/afkhamazeez
>> <http://lk.linkedin.com/in/afkhamazeez>*
>>
>> *Lean . Enterprise . Middleware*
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Manoj Fernando
> Director - Solutions Architecture
>
> Contact:
> LK - +94 112 145345
> Mob: +94 773 759340
> www.wso2.com
>
--
Manoj Fernando
Director - Solutions Architecture
Contact:
LK - +94 112 145345
Mob: +94 773 759340
www.wso2.com
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
