Hi Milinda, Here are some implementation details:
- The message comes to the cache finder - A hash value is generated - This hash value is used to check if a cacheable response is there in the guava cache. If there's none create a new one - Check if the payload is null of this cacheableResponse object - if not null respond with the payload - If null add the CacheableResponse object to messageContext and continue to the next mediator - In this case when the response goes to collector store the payload in the CachableResponse object. Thanks, Riyafa On Fri, Aug 18, 2017 at 3:43 PM, Milinda Perera <[email protected]> wrote: > Hi Riyafa, > > What I expect is to find some implementation details without going through > the code. For example, what kind of data structure used to store cached > messages, whether there is a single data structure available to hold all > cached messages or whether there is cached message holder per service, > Whether messages are encoded to some other format, etc. If we have a little > high-level diagram (no need to very complex one with tiny details, just > expressing implementation details, that require attention) expressing that > information, that will be great. Some examples [1][2]. > > Does the documentation contain implementation information (if so that will > be great) or documentation for WSO2 EI docs? > > [1] mail:AS4 support in EI > [2] mail:[Architecture] MB4 active-passive clustering implementation > > Thanks, > Milinda > > On Fri, Aug 18, 2017 at 1:47 PM, Riyafa Abdul Hameed <[email protected]> > wrote: > >> Hi Milinda, >> >> What kind of diagram do you expect? >> I would soon be writing the documentation on this and will be sharing >> with everyone. >> >> Thanks. >> Riyafa >> >> On Fri, Aug 18, 2017 at 1:39 PM, Milinda Perera <[email protected]> >> wrote: >> >>> Hi Riyafa, >>> >>> Can you share some design diagram if it is possible to get some idea of >>> current implementation? >>> >>> Thanks, >>> Milinda >>> >>> On Mon, Jul 10, 2017 at 4:40 PM, Riyafa Abdul Hameed <[email protected]> >>> wrote: >>> >>>> 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-VgzAzjjSsLmG9a >>>> qAFEubmFgNkQhoDvqz8/edit >>>> >>>> >>>> Thank you. >>>> >>>> Yours sincerely, >>>> >>>> Riyafa >>>> >>>> >>>> On Thu, Jul 6, 2017 at 9:50 AM, Riyafa Abdul Hameed <[email protected]> >>>> wrote: >>>> >>>>> 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> >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 >>>> >>>> >>> >>> >>> -- >>> Milinda Perera >>> Senior Software Engineer; >>> WSO2 Inc. http://wso2.com , >>> Mobile: (+94) 714 115 032 <+94%2071%20411%205032> >>> >>> >> >> >> -- >> 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> >> > > > > -- > Milinda Perera > Senior Software Engineer; > WSO2 Inc. http://wso2.com , > Mobile: (+94) 714 115 032 <+94%2071%20411%205032> > > -- 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
