Hi all, As I am currently doing the implementation of this project, the json payload of the throttle event which is generated in the micro-gateway is published to traffic manager via http protocol. In here ‘throttleEventReceiver’ receives that throttle data and sends those data to ‘org.wso2.throttle.request.stream’. From that stream, data is sent to ‘requestPreProcessorExecutionPlan’ and through ‘org.wso2.throttle.processed.request.stream’ the data is published to execution plans. The throttled decisions are published to ‘org.wso2.throttle.globalThrottle.stream’ and those throttled decisions are sent to ‘jmsEventPublisher’. To receive the throttled decisions, the micro-gateway jms event listener is subscribed to the ‘throttleData’ topic. Then through that subscriber endpoint the throttled decisions which are in jms message format are received by the micro-gateway jms event listener. When throttled decision is received, the local maps in the micro-gateway are updated according to that.
[image: image.png] Thank you. On Wed, Sep 12, 2018 at 11:13 AM Jayanie Bogahawatta <[email protected]> wrote: > Hi All, > The project I have chosen in the internship is Project 194: Distributed > Throttling for Micro-gateway. > > Problem > > - > > Micro-gateway does not have access to central traffic manager system > with the current architecture. > - > > Micro-gateway manage throttling in node level by maintaining node > local counters. > - > > In scalable gateway environment this can be a problem as gateways > scale dynamically.When it comes to application level throttling and backend > throttling node level would not sufficient as number of instances can > multiply allowed limits. > > Solution > > - > > Existing traffic manager solution which is connected to API gateway > executes the throttle policies against data coming with every published > event and takes decisions based on the applicability of each throttle > policy available in the system. If a particular request is throttled, then > the Traffic Manager sends those details to a JMS topic. Every gateway node > is subscribed to this JMS topic; hence the gateway nodes get notified of > throttle decisions through JMS messages. > - > > This traffic manager solution can be used and need to be connected to > micro-gateway. > - > > In case of a lock down environment or offline mode which do not have > connection with Central Traffic management solution, node level throttling > is also required. > > Basic approach > > - > > The events should be published to the traffic manager from the > micro-gateway node. Binary or thrift transport can be used to publish this > data from micro-gateway to the Traffic Manager. > - > > Traffic manager sends throttling decisions calculated based on > received events to a JMS topic which should be listened and based on the > throttling decisions received, the local maps in micro-gateway need to be > updated. > > > > > > > > -- > > *Jayanie Bogahawatte* > *Software Engineering Intern* > WSO2 (University of Moratuwa) > *mobile *: *+94 777563324* | *email *: [email protected] > > > > > -- *Jayanie Bogahawatte* *Software Engineering Intern* WSO2 (University of Moratuwa) *mobile *: *+94 777563324* | *email *: [email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
