Hi Sanjeewa,
On 2 December 2013 17:00, Sanjeewa Malalgoda <[email protected]> wrote: > > > > On Sun, Dec 1, 2013 at 11:01 PM, Lakmali Baminiwatta <[email protected]>wrote: > >> Hi all, >> >> When processing the response, if the request is REST then soap format, >> transport headers and message type are also stored. Similarly when >> retrieving the cached response, if the request is REST then stored values >> are used to compose the response message. With these modifications cache >> mediator returns the response correctly for non SOAP requests. >> >> But we have another issue here. Currently the request Hash value is >> derived from the SOAP message body. So for REST calls it gets the same hash >> value for all requests which sent without a payload. >> >> ex: Both below requests are recognized as the same request according to >> the hash value derived from DOMHASHGenerator. >> >> curl -v -H "Authorization: Bearer 1EV6Qqa_DboaBzNj2JfiyXoO1Ysa" >> http://localhost:8280/test/1.0.0?regNo=001 >> curl -v -H "Authorization: Bearer 1EV6Qqa_DboaBzNj2JfiyXoO1Ysa" >> http://localhost:8280/test/1.0.0?regNo=002<http://localhost:8280/test/1.0.0?regNo=001> >> >> So right now we need to figure out a mechanism to generate hash value for >> REST calls. >> > How if we consider full request path(including query params and etc) + > headers. For above example something like follows (full request path and > "," separated transport headers list). We can compute hash value of that > string and store it. > > *"http://localhost:8280/test/1.0.0?regNo=002,Authorization > <http://localhost:8280/test/1.0.0?regNo=002,Authorization>: Bearer > 1EV6Qqa_DboaBzNj2JfiyXoO1Ysa"* > > Here we cannot only consider full request path as we take some decisions > at backend based on headers. WDYT? > Yeah, need to consider request path + headers. But I think we don't need hash Authorization headers, as request hits the cache mediator after going through the handlers. So in default case, at the time of hashing we don't have the authorization header. So AFAIU, the only concern which comes up here is, same request invoked using different keys may get the response from the cache. I believe that is ok. WDYT? I am writing a new Digest Generator implementation by extending DOMHASHGenerator. This basically does what DOMHASHGenerator had been doing and additionally it digests request path and available transport headers as well. Thanks, Lakmali > > Thanks, > sanjeewa. > >> >> Thanks, >> Lakmali >> >> >> On 29 November 2013 00:18, Lakmali Baminiwatta <[email protected]> wrote: >> >>> Hi all, >>> >>> Currently Cache mediator stores the response message as a byte array and >>> builds the soap envelope from that when sending the cached response[1]. >>> When building the response, it checks whether the request format is in >>> SOAP11 or SOAP12 and do the build accordingly. >>> >>> For SOAP requests, the SOAP format for response and request messages are >>> same since most of the time a WSDL is used. So above logic works. >>> >>> But the response message for REST calls may be in different SOAP formats >>> than the request. This results in errors when building the message. >>> >>> ex: >>> >>> Below REST call's request message context is SOAP12. But the response >>> SOAP envelope is SOAP11. Hence building the message throws an exception. >>> >>> curl -v -H "Authorization: Bearer 1EV6Qqa_DboaBzNj2JfiyXoO1Ysa" >>> http://localhost:8280/test/1.0.0?regNo=001 >>> >>> Further Content-Type of the responses can be different (ex: >>> application/xml, application/json). So I think we should store the actual >>> SOAP format and the Content-Type of the response than just storing the >>> response envelope. One option would be to store them in CachableResponse >>> object[2] (May be in a property map?) >>> >>> Any better way to fix this? >>> >>> [1] >>> https://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/dependencies/synapse/2.1.2-wso2v2/modules/core/src/main/java/org/apache/synapse/mediators/builtin/CacheMediator.java >>> [2] >>> https://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/dependencies/commons/caching/4.0.2/modules/core/src/main/java/org/wso2/caching/CachableResponse.java >>> >>> Thanks, >>> Lakmali >>> >>> >>> On 22 November 2013 15:59, Sumedha Rubasinghe <[email protected]> wrote: >>> >>>> Dinusha, >>>> Did you identify what needs to be fixed? I think ESB team is busy with >>>> a release. >>>> >>>> >>>> On Thu, Nov 21, 2013 at 7:09 PM, Dinusha Senanayaka >>>> <[email protected]>wrote: >>>> >>>>> Hi All, >>>>> >>>>> We are trying to add response caching as a default feature in API >>>>> Manager using Cache mediator. There, we found that Cache mediator could >>>>> handle only SOAP-1.1 or SOAP-1.2 messages. >>>>> >>>>> - If backend returns a POX response, it throws the following exception >>>>> [1] when request is served from the cache. >>>>> - If backend returns a JSON response, and once the response get added >>>>> to cache, client does not receive a response until cache expires. (No >>>>> backend errors) >>>>> >>>>> Is it possible to fix those for API Manager-1.6.0 release ? >>>>> >>>>> [1] [2013-11-21 13:33:18,044] ERROR - NativeWorkerPool Uncaught >>>>> exception >>>>> org.apache.axiom.soap.SOAPProcessingException: Transport level >>>>> information does not match with SOAP Message namespace URI >>>>> at >>>>> org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.identifySOAPVersion(StAXSOAPModelBuilder.java:187) >>>>> at >>>>> org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.<init>(StAXSOAPModelBuilder.java:170) >>>>> at org.apache.axis2.saaj.SOAPPartImpl.<init>(SOAPPartImpl.java:194) >>>>> at >>>>> org.apache.axis2.saaj.SOAPMessageImpl.<init>(SOAPMessageImpl.java:112) >>>>> at >>>>> org.apache.axis2.saaj.MessageFactoryImpl.createMessage(MessageFactoryImpl.java:132) >>>>> at >>>>> org.wso2.caching.util.SOAPMessageHelper.buildSOAPEnvelopeFromBytes(SOAPMessageHelper.java:77) >>>>> at >>>>> org.apache.synapse.mediators.builtin.CacheMediator.processRequestMessage(CacheMediator.java:319) >>>>> at >>>>> org.apache.synapse.mediators.builtin.CacheMediator.mediate(CacheMediator.java:170) >>>>> at >>>>> org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:77) >>>>> at >>>>> org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:47) >>>>> at >>>>> org.apache.synapse.mediators.filters.FilterMediator.mediate(FilterMediator.java:160) >>>>> at >>>>> org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:77) >>>>> at >>>>> org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:47) >>>>> at >>>>> org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:131) >>>>> at org.apache.synapse.rest.Resource.process(Resource.java:297) >>>>> at org.apache.synapse.rest.API.process(API.java:341) >>>>> at >>>>> org.apache.synapse.rest.RESTRequestHandler.dispatchToAPI(RESTRequestHandler.java:76) >>>>> at >>>>> org.apache.synapse.rest.RESTRequestHandler.process(RESTRequestHandler.java:63) >>>>> at >>>>> org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage(Axis2SynapseEnvironment.java:220) >>>>> at >>>>> org.apache.synapse.core.axis2.SynapseMessageReceiver.receive(SynapseMessageReceiver.java:83) >>>>> at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180) >>>>> at >>>>> org.apache.synapse.transport.passthru.ServerWorker.processNonEntityEnclosingRESTHandler(ServerWorker.java:337) >>>>> at >>>>> org.apache.synapse.transport.passthru.ServerWorker.processEntityEnclosingRequest(ServerWorker.java:378) >>>>> at >>>>> org.apache.synapse.transport.passthru.ServerWorker.run(ServerWorker.java:184) >>>>> at >>>>> org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172) >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) >>>>> at java.lang.Thread.run(Thread.java:619) >>>>> >>>>> Regards, >>>>> Dinusha. >>>>> >>>>> >>>>> >>>>> -- >>>>> Dinusha Dilrukshi >>>>> Senior Software Engineer >>>>> WSO2 Inc.: http://wso2.com/ >>>>> Mobile: +94725255071 >>>>> Blog: http://dinushasblog.blogspot.com/ >>>>> >>>> >>>> >>>> >>>> -- >>>> /sumedha >>>> m: +94 773017743 >>>> b : bit.ly/sumedha >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >>> >>> -- >>> Lakmali Baminiwatta >>> Software Engineer >>> WSO2, Inc.: http://wso2.com >>> lean.enterprise.middleware >>> mobile: +94 71 2335936 >>> blog : lakmali.com >>> >>> >> >> >> -- >> Lakmali Baminiwatta >> Software Engineer >> WSO2, Inc.: http://wso2.com >> lean.enterprise.middleware >> mobile: +94 71 2335936 >> blog : lakmali.com >> >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > > *Sanjeewa Malalgoda* > Senior Software Engineer > WSO2 Inc. > Mobile : +94713068779 > > <http://sanjeewamalalgoda.blogspot.com/>blog > :http://sanjeewamalalgoda.blogspot.com/<http://sanjeewamalalgoda.blogspot.com/> > > > -- Lakmali Baminiwatta Software Engineer WSO2, Inc.: http://wso2.com lean.enterprise.middleware mobile: +94 71 2335936 blog : lakmali.com
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
