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