Hi all, At this stage of implementation enabling distributed throttling feature is done through "micro-gw.conf" file.
[throttlingConfig] enabledGlobalTMEventPublishing = false jmsConnectioninitialContextFactory = "bmbInitialContextFactory" jmsConnectionProviderUrl= "amqp://admin:admin@carbon/carbon?brokerlist='tcp://localhost:5672'" jmsConnectionUsername = "" jmsConnectionPassword = "" throttleEndpointUrl = "https://localhost:9443/endpoints"; If enabledGlobalTMEventPublishing is true then micro-gateway uses distributed throttling if it is false it disables publishing throttle events to traffic manager. In this configuration the user can configure throttleEndpointUrl which throttle events are published and jms Connection configurations. In that case other message brokers like Apache active mq can also be used to receive throttled decisions from traffic manager. To make the throttle event publishing asynchronous, a separate worker thread is used to publish throttle events to traffic manager or to internal throttle policies. Performance tests for this fetaure by using JMeter need to be done. 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
