Dear all, I came up with the following configurations for the cache mediator rewrite:
> <cache [id="string"] [hashGenerator="class"] [timeout="seconds"] > [scope=(per-host | per-mediator)] collector=(true | false) > [maxMessageSize="in-bytes"] HTTPMethodToCache = (GET | POST)]> > > <onCacheHit [sequence="key"] [continueExecution=(true | false)]> > > (mediator)+ > > </onCacheHit>? > > <implementation type=(memory | disk) maxSize="int"/> > > </cache> > As I have mentioned in the requirements doc[1], the only reason we are allowing responses to POST messages to be cached is because POST is the only method used in SOAP implementations. Now having looked at the implementation details further I understand that it is possible to identify whether a request is soap or not without having it externally configured. So my question is whether the configuration "HTTPMethodToCache" is actually required because it can be internally processed whether request is SOAP or REST and then cache accordingly. [1] https://docs.google.com/document/d/1iPtArrW6C-VgzAzjjSsLmG9aqAFEubmFgNkQhoDvqz8/edit Thank you. Yours sincerely, Riyafa On Thu, Jul 6, 2017 at 9:50 AM, Riyafa Abdul Hameed <riy...@wso2.com> wrote: > Thank you for the suggestions Rajkumar. > > > On Thu, Jul 6, 2017 at 6:57 AM, Rajkumar Rajaratnam <rajkum...@wso2.com> > wrote: > >> Also the existing cache mediator doesn't honor the cache ID as per my >> testing sometimes back (not sure it's fixed though). It means caching works >> globally, not at cache mediator instance level. >> >> If we can't correlate a finder with a collector (using cache mediator >> ID), then we are going to hit memory issues. >> >> Here is the reason. >> >> Let's say we have two APIs - location and exchange. >> >> 1. /location API response size is 10 MB and we have 100 different >> responses >> 2. /exchange API response size is 1MB and we have 1000 different >> responses >> >> If we want to enable response caching for these two APIs, if we can >> correlate a finder with a collector (i.e if we support caching at cache >> mediator instance level), then I can allocate 100*10 + 1000*1 = 2000 MB >> memory to the JVM in addition to our recommended memory settings, so that >> it will never go OOM. >> >> If we can't correlate a finder with a collector (i.e, if we support >> global caching), then I have to allocate 1100 * 10 = 11000 MB memory. See I >> have to use additional 9000 MB if we don't honor cache ID. It's not >> practical and efficient because memory is expensive - so it doesn't scale. >> >> Can we fix this issue and honor cache ID please in the next EI release? >> > > Yes we need to honor this as you suggest and I shall include it in the > requirements document. > >> >> On Wed, Jul 5, 2017 at 9:18 PM, Rajkumar Rajaratnam <rajkum...@wso2.com> >> wrote: >> >>> Is this going to be a rewrite or improvement to existing cache mediator? >>> If this is a rewrite, will it be included in next EI release? >>> >> Yes it's going to be a rewrite. We hope to include it in the EI 6.2.x > release. > >> >>> Also can we also implement cache eviction as part of this effort? >>> >>> Ideally, we should be able to configure how many maximum responses we >>> can cache (not sure whether it's there already, it was not working >>> sometimes back) and what's the maximum message size (it's already there) we >>> can cache to avoid OOM. Then we need to have cache eviction in place to >>> evict some cached items when cache is full, in-order to give space for most >>> recent responses. >>> >>> I guess configuring the maximum responses is currently available and we > shall consider your suggestions in the rewrite. > >> Thanks. >>> >>> On Wed, Jul 5, 2017 at 6:02 AM, Riyafa Abdul Hameed <riy...@wso2.com> >>> wrote: >>> >>>> Hi, >>>> Please find the requirements doc below: >>>> https://docs.google.com/document/d/1iPtArrW6C-VgzAzjjSsLmG9a >>>> qAFEubmFgNkQhoDvqz8/edit?usp=sharing >>>> Any suggestions would be highly appreciated. >>>> Thank you. >>>> Riyafa >>>> >>>> On Tue, Jul 4, 2017 at 5:37 PM, Riyafa Abdul Hameed <riy...@wso2.com> >>>> 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 <isu...@wso2.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> On Tue, Jul 4, 2017 at 3:10 PM, Vijitha Ekanayake <vijit...@wso2.com> >>>>>> 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 < >>>>>>> riy...@wso2.com> 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: riy...@wso2.com <riyafa...@cse.mrt.ac.lk> >>>>>>>> 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 >>>>>>>> Dev@wso2.org >>>>>>>> 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: isu...@wso2.com 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: riy...@wso2.com <riyafa...@cse.mrt.ac.lk> >>>>> 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: riy...@wso2.com <riyafa...@cse.mrt.ac.lk> >>>> 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 >>>> Dev@wso2.org >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >>> >>> -- >>> Rajkumar Rajaratnam >>> Committer & PMC Member, Apache Stratos >>> Senior Software Engineer, WSO2 >>> >> >> >> >> -- >> Rajkumar Rajaratnam >> Committer & PMC Member, Apache Stratos >> Senior Software Engineer, WSO2 >> > > > > -- > Riyafa Abdul Hameed > Software Engineer, WSO2 Lanka (Pvt) Ltd <http://wso2.com/> > > Email: riy...@wso2.com <riyafa...@cse.mrt.ac.lk> > 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: riy...@wso2.com <riyafa...@cse.mrt.ac.lk> 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 Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
