+1 for the approach. Yes we can avoid using durable subscriptions since we are pre-loading the throttle database snapshot into gateway nodes at the time they are spawning. We may need to address how existing users will migrate and adapt the new design.As Sanjeewa mentioned, some users may won't be need of using complex deployment. So I think we need to revisit how we can address it. We may can implement simple throttling mechanism in our CEP based local throttle component or support both existing implementation along with our new implementation. Both involves in maintenance overhead.
On Wed, Mar 2, 2016 at 9:21 AM, Sanjeewa Malalgoda <sanje...@wso2.com> wrote: > +1 for this approach. > Still i think we need to have other alternative for this(web service call > and pooling mechanism) as some of our users may not need complex deployment > like this. > WDYT? > > Thanks, > sanjeewa. > > On Wed, Mar 2, 2016 at 12:12 AM, Sriskandarajah Suhothayan <s...@wso2.com> > wrote: > >> >> >> On Tue, Mar 1, 2016 at 11:17 PM, Pamod Sylvester <pa...@wso2.com> wrote: >> >>> Hi Nuwan, >>> >>> AFAIU this will not require *durable* subscriptions created between the >>> GW and the broker, since each time the GW node starts or reconnects it will >>> sync/snapshot with the DB to obtain the current state. Also i assume in >>> this case the keys will first be persisted in the DB and then it'll be >>> broadcasted to a topic. >>> >>> If that is the case in the 2nd approach (d) could be omitted if you >>> subscribe the GW nodes to a non durable topic. >>> >>> +1 for the approach, >> Need to make sure no events missed and at the end only the latest events >> remains at GW. >> >> >> >>> Thanks, >>> Pamod >>> >>> On Tue, Mar 1, 2016 at 7:16 PM, Nuwan Dias <nuw...@wso2.com> wrote: >>> >>>> Hi, >>>> >>>> According to the new throttling architecture in API Manager, the >>>> throttling decision will be taken by a global throttling engine (CEP). The >>>> Gateway nodes publishes events to the throttling engine and the throttling >>>> engine evaluates data within those events to decide whether a particular >>>> 'key' is throttled or not. Note: Each event will have a 'key' against which >>>> throttling counters are maintained. When the throttling engine decides a >>>> particular key is to be throttled out, it will persist this data to a >>>> Database. It will later clean this record from the DB when the state of key >>>> is reverted later. >>>> >>>> The next problem is on how this decision that is made by the throttling >>>> engine is communicated to the Gateway cluster. We evaluated two options as >>>> below. >>>> >>>> 1. Each Gateway node keeps polling the throttling engine periodically >>>> (every 5 secs or so) and gets a snapshot of the DB into local memory. >>>> >>>> 2. Using a pub-sub mechanism where the throttling engine publishes a >>>> state change event of a key to a topic and each Gateway node will have >>>> subscribed to that topic and hence receive updates as and when state >>>> changes occur. This pattern is illustrated in a diagram below. >>>> >>>> The first approach has some drawbacks such as >>>> a) Each Gateway has to poll the engine even if no events are throttled >>>> out. >>>> b) The amount of data being transferred over the network can be large. >>>> c) The load on the throttling engine increases as more Gateways start >>>> polling it. >>>> d) The load on the DB reads can be high (can use a cache to avoid this). >>>> >>>> The second approach looks better than the first but still have a few >>>> other drawbacks such as >>>> a) We will anyway need to get a snapshot from the DB the first time a >>>> Gateway starts to get the current state. >>>> b) Deployment complexities when scaling out. We would probably need to >>>> have a separate message broker cluster in larger deployments. >>>> c) Need to maintain a consistent http connection between the Gateway >>>> and the message broker. >>>> d) If a Gateway node disconnects, the messages intended for that node >>>> will pile up on the message broker. >>>> >>>> We have currently opted for option 2. Please share your thoughts, >>>> suggestions on this approach. >>>> >>>> >>>> [image: Inline image 1] >>>> >>>> Thanks, >>>> NuwanD. >>>> >>>> -- >>>> Nuwan Dias >>>> >>>> Technical Lead - WSO2, Inc. http://wso2.com >>>> email : nuw...@wso2.com >>>> Phone : +94 777 775 729 >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Pamod Sylvester * >>> >>> *WSO2 Inc.; http://wso2.com <http://wso2.com>* >>> cell: +94 77 7779495 >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> *S. Suhothayan* >> Technical Lead & Team Lead of WSO2 Complex Event Processor >> *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>* >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > *Sanjeewa Malalgoda* > WSO2 Inc. > Mobile : +94713068779 > > <http://sanjeewamalalgoda.blogspot.com/>blog > :http://sanjeewamalalgoda.blogspot.com/ > <http://sanjeewamalalgoda.blogspot.com/> > > > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Harsha Kumara Software Engineer, WSO2 Inc. Mobile: +94775505618 Blog:harshcreationz.blogspot.com
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
