Thank you for the suggestions Rajkumar.
On Thu, Jul 6, 2017 at 6:57 AM, Rajkumar Rajaratnam <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[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 >>> >>> >> >> >> -- >> 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: [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
