On Fri, Jun 30, 2017 at 3:33 PM, Maninda Edirisooriya <[email protected]> wrote:
> > On Fri, Jun 30, 2017 at 2:47 PM, Lakmal Warusawithana <[email protected]> > wrote: > >> Hi Maninda, >> >> On Fri, Jun 30, 2017 at 12:02 PM, Maninda Edirisooriya <[email protected]> >> wrote: >> >>> Hi Dinusha, >>> >>> Why do we think it is the responsibility of the CEP to pull poilcies >>> from the APIM? Just forgetting the APIM case, if we think this as a general >>> feature of CEP, here the CEP is periodically pulling artifacts from a given >>> set of APIs. There are 2 drawbacks I see in this approach. >>> >>> 1. Updating the CEP with latest artifacts is restricted by the given >>> polling time interval. (realtime CEP artifact updates are not possible from >>> an external party which is important as CEP is dealing with realtime >>> requirements) >>> >>> 2. Dynamically adding unplanned artifacts to a running CEP server is not >>> possible as the polling APIs has to be pre configured. For example this can >>> happen when the existing APIM server is stopped and a different APIM server >>> is started with a different host address. In that case the CEP also has to >>> be restarted to update the policy API location, which would lose some data >>> in the running CEP. Correct me if I am wrong. >>> >>> Therefore I think the current policy push based approach is correct. We >>> should be able to correct the syncing policies across the CEP nodes with a >>> different approach like deploment synchronizing, registry based approach, >>> with a shared database based approach or with a clustering solution like >>> Hazelcast. >>> >> >> This is exactly what we want to avoid. :) >> >> #1 is not an valid concern. We are not going to solve generic case here. >> In the APIM, throttling policy update not a frequent thing. Sometimes it >> only doing one time for a deployment. >> > Yeah if we just want to fix the APIM requirement that would be enough. But > realtime policy updating would certainly be an valid scenario in the CEP > user's point of view. Suppose a customer system (or an ESB) wants to update > the execution plans right away. Then it would be useful. > >> >> I can't understand #2 concern. No need CEP to restart anytime. >> > I may be wrong. As I understand the CEP should be given the API location > of policies URL in somewhere in configuration. If the host address is > changed in that URL, the CEP should be restarted. Isn't it? may be we can > give the URL in a registry location and each time the cron job is running, > the URL can be obtained from the registry. > No registry. Its LB end point. it doest not change if individual API Core instance change. > >> >>> >>> Thanks. >>> >>> >>> *Maninda Edirisooriya* >>> Senior Software Engineer >>> >>> *WSO2, Inc.*lean.enterprise.middleware. >>> >>> *Blog* : http://maninda.blogspot.com/ >>> *E-mail* : [email protected] >>> *Skype* : @manindae >>> *Twitter* : @maninda >>> >>> On Thu, Jun 29, 2017 at 5:10 PM, Dinusha Dissanayake <[email protected]> >>> wrote: >>> >>>> +Adding architecture >>>> >>>> On Thu, Jun 29, 2017 at 5:05 PM, Nuwan Dias <[email protected]> wrote: >>>> >>>>> Let's discuss publicly please, this thread is internal only. >>>>> >>>>> On Thu, Jun 29, 2017 at 5:01 PM, Dinusha Dissanayake < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> In earlier versions of APIM, throttle policy deployment for CEP was >>>>>> handled using push mechanism meaning APIM itself had to deploy throttle >>>>>> policies in CEP. If there are multiple CEP nodes, then the Siddhi >>>>>> apps/execution plans syncing would be an issue here. >>>>>> >>>>>> We were thinking of pull based mechanism from CEP side to overcome >>>>>> this. To do that, from APIM side we need to add an API to the core which >>>>>> allows CEP to get all Siddhi apps for existing throttle policies. Then >>>>>> every CEP node will call APIM (once or periodically) and then it will >>>>>> check >>>>>> the DB and generate a zip containing all the Siddhi Apps for existing >>>>>> throttle policies. >>>>>> >>>>>> >>>>>> This API will only need GET resource. The resource path for this API >>>>>> would be *"export/policies/throttle"*. As mentioned above, this will >>>>>> return a zip. Mutual SSL would be used to secure the API since if we use >>>>>> OAuth2, then the token may expire in a while. >>>>>> >>>>>> Exported zip can be manually deployed in the CEP or deployment can >>>>>> be done using e a curl command. If this needs to be happened >>>>>> periodically, >>>>>> then a cron job can be written. >>>>>> >>>>>> Please provide suggestions for improvements. >>>>>> >>>>>> Thanks & Regards. >>>>>> -- >>>>>> Dinusha Dissanayake >>>>>> Software Engineer >>>>>> WSO2 Inc >>>>>> Mobile: +94712939439 <+94%2071%20293%209439> >>>>>> <https://wso2.com/signature> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Nuwan Dias >>>>> >>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>> email : [email protected] >>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>> >>>> >>>> >>>> >>>> -- >>>> Dinusha Dissanayake >>>> Software Engineer >>>> WSO2 Inc >>>> Mobile: +94712939439 <+94%2071%20293%209439> >>>> <https://wso2.com/signature> >>>> >>> >>> >> >> >> -- >> Lakmal Warusawithana >> Director - Cloud Architecture; WSO2 Inc. >> Mobile : +94714289692 <071%20428%209692> >> Blogs : https://medium.com/@lakwarus/ >> http://lakmalsview.blogspot.com/ >> >> > -- Lakmal Warusawithana Director - Cloud Architecture; WSO2 Inc. Mobile : +94714289692 Blogs : https://medium.com/@lakwarus/ http://lakmalsview.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
