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/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
