Hi Riyafa, Can we have some kind of user level caching as well, something similar to a session, since ei works in nhttp transport we don't have that feature in EI. WDYT? I believe there are some valid use cases when it comes to user level caching.
Thanks, Madhawa On Wed, Jul 5, 2017 at 3:32 PM, Riyafa Abdul Hameed <[email protected]> wrote: > Hi, > Please find the requirements doc below: > https://docs.google.com/document/d/1iPtArrW6C- > VgzAzjjSsLmG9aqAFEubmFgNkQhoDvqz8/edit?usp=sharing > Any suggestions would be highly appreciated. > Thank you. > Riyafa > > On Tue, Jul 4, 2017 at 5:37 PM, Riyafa Abdul Hameed <[email protected]> > wrote: > >> Hi all, >> >> Thank you for the suggestions. Yes the mediator should also work with the >> call mediator. >> >> Further on a discussion with the APIM team I have identified the >> following issues which points to requiring a rewrite of the cache mediator: >> >> 1. >> >> Current cache mediator[1] caches responses for all the HTTP Request >> Methods which include GET, POST, PUT and DELETE. Ideally a cache mediator >> should cache only the response for GET method and caching for POST method >> should be configurable (because POST is the only method used in SOAP >> implementations). The caching for PUT and DELETE methods should be >> completely omitted. The reason for caching responses only for GET is >> because in the REST world other methods (POST, PUT and DELETE) are used >> for >> creating, modifying or deleting existing records and hence the response >> would only mention the success or failure of the request. Caching these >> responses is meaningless and error prone. >> 2. >> >> Current cache mediator caches all the responses whether they are >> success or failure responses. Ideally the mediator should cache only >> success (200 OK) responses and not the failures >> 3. >> >> Current mediator hashes the payload (both DOMHASHGenerator and >> REQUESTHASHGenerator) which is a huge overhead for messages with larger >> bodies. The mediator should hash only the recipient (To) address of the >> request and the HTTP headers which can be easily handled when only >> responses for GET methods are hashed. Payload should be hashed only if PUT >> method is configured. >> 4. >> >> Current mediator does not allow configurations for omitting certain >> headers when hashing. For example there’s no point in hashing the >> timestamp >> header--it will almost always be different from message to message. >> 5. >> >> The current mediator does not honor the http headers[2]. For example >> the max-age header specifies the maximum time in seconds that the fetched >> response is allowed to be reused from the time of the request. Although >> cache timeout is allowed to be configured this header is not honored when >> it is specified in a message. >> 6. >> >> Although it is possible to set the maximum number of elements to be >> cached in bytes it might result in this set value exceeding the available >> memory at runtime. >> 7. >> >> The current mediator does not invoke the handleResponseInFlow or >> handleResponseOutFlow methods in handlers[3] >> >> >> >> [1] https://docs.wso2.com/display/EI611/Cache+Mediator >> >> [2] https://developers.google.com/web/fundamentals/performance/o >> ptimizing-content-efficiency/http-caching >> >> [3] https://docs.wso2.com/display/EI611/Writing+a+Synapse+Handler >> >> On Tue, Jul 4, 2017 at 4:28 PM, Isuru Udana <[email protected]> wrote: >> >>> Hi, >>> >>> On Tue, Jul 4, 2017 at 3:10 PM, Vijitha Ekanayake <[email protected]> >>> wrote: >>> >>>> Hi Riyafa, >>>> >>>> Apart from the issues that you have mentioned, we may need to consider >>>> following points while refactoring the cache mediator implementation. >>>> >>>> 1). Verify the cache mediator functionality with different >>>> configuration parameters and fix if there is anything broken. >>>> 2). Implement a mechanism to support caching when using the call >>>> mediator. >>>> 3). Feasibility to introduce native JSON caching support to cache >>>> mediator. >>>> 4). Feasibility to introduce service level caching which isn't support >>>> at the moment. >>>> >>> IMO, service level caching is not a requirement as long as we can >>> achieve all the requirements through the Cache Mediator. >>> >>> Thanks. >>> >>>> >>>> >>>> Thanks. >>>> >>>> >>>> On Tue, Jul 4, 2017 at 12:06 PM, Riyafa Abdul Hameed <[email protected]> >>>> wrote: >>>> >>>>> Dear all, >>>>> >>>>> By going through the issues faced by the customers in the past I >>>>> discovered the following issues: >>>>> >>>>> 1. Continue the execution on cache hit. Reported as an issue in >>>>> github[1] >>>>> 2. Issue in processing JSON array (payload) with a single element >>>>> when response caching is enabled where expected response is: >>>>> >>>>> [ >>>>> { >>>>> "msg":"Hello", >>>>> "services":[ >>>>> "elec", >>>>> "patrol" >>>>> ], >>>>> "test":"World." >>>>> }, >>>>> { >>>>> "msg":"Hi", >>>>> "services":[ >>>>> "water" >>>>> ], >>>>> "test":"Sri Lanka." >>>>> } >>>>> ] >>>>> >>>>> but received response is: >>>>> >>>>> [ >>>>> { "msg": "Hello", "services": [ "elec", "patrol" ], "test": "World." } >>>>> >>>>> , >>>>> { "msg": "Hi", "services": "water", "test": "Sri Lanka." } >>>>> >>>>> ] >>>>> >>>>> This issue has been fixed in the carbon mediation[2]. >>>>> >>>>> 3. When a xml body with processing instructions is stored >>>>> in cache and sent back as json it fails with an exception. Issue was >>>>> reported in 2015 and already has a fix in current EI. >>>>> >>>>> Since the last two issues have been already fixed, I would like to >>>>> know what other issues if any needs to be addressed and if a complete >>>>> rewrite of the cache mediator would be required. >>>>> >>>>> [1] https://github.com/wso2/product-ei/issues/695 >>>>> >>>>> [2]https://github.com/riyafa/carbon-mediation/commit/7aaf597 >>>>> 988a333e1cad36dc0b5057e24fb779a5c >>>>> >>>>> >>>>> Thank you. >>>>> >>>>> Riyafa >>>>> >>>>> -- >>>>> Riyafa Abdul Hameed >>>>> Software Engineer, WSO2 Lanka (Pvt) Ltd <http://wso2.com/> >>>>> >>>>> Email: [email protected] <[email protected]> >>>>> Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/> >>>>> <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa> >>>>> <http://twitter.com/Riyafa1> >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> [email protected] >>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Vijitha Ekanayake >>>> Software Engineer*, *WSO2, Inc.; http://wso2.com/ >>>> Mobile : +94 777 24 73 39 | +94 718 74 44 08 >>>> lean.enterprise.middleware >>>> >>> >>> >>> >>> -- >>> *Isuru Udana* >>> Senior Technical Lead >>> WSO2 Inc.; http://wso2.com >>> email: [email protected] cell: +94 77 3791887 <+94%2077%20379%201887> >>> blog: http://mytecheye.blogspot.com/ >>> >> >> >> >> -- >> Riyafa Abdul Hameed >> Software Engineer, WSO2 Lanka (Pvt) Ltd <http://wso2.com/> >> >> Email: [email protected] <[email protected]> >> Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/> >> <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa> >> <http://twitter.com/Riyafa1> >> > > > > -- > Riyafa Abdul Hameed > Software Engineer, WSO2 Lanka (Pvt) Ltd <http://wso2.com/> > > Email: [email protected] <[email protected]> > Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/> > <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa> > <http://twitter.com/Riyafa1> > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- *Madhawa Gunasekara* Senior Software Engineer WSO2 Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 719411002 <+94+719411002> blog: *http://madhawa-gunasekara.blogspot.com <http://madhawa-gunasekara.blogspot.com>* linkedin: *http://lk.linkedin.com/in/mgunasekara <http://lk.linkedin.com/in/mgunasekara>*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
