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