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/optimizing-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>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
