Hi Amila, Agree with you, I did with this way because I ran all these in my PC for have an abstract idea. No perf testing environment was setup. But will do a exact test with the XPATH optimization changes.
Thanks AndunSLG On Mon, Sep 17, 2012 at 6:38 PM, Amila Suriarachchi <[email protected]> wrote: > > > On Mon, Sep 17, 2012 at 6:11 PM, Andun Sameera <[email protected]> wrote: > >> Hi All, >> >> I have developed the custom mediator AKA RawXSLTMediator to transform >> streams in binary relay mood. Samisa suggested some further improvements >> after looking at the code and currently I am working on those. With the >> existing implementation I did some test with ESB. The results of those >> tests are given below. For large message sizes, it has >> improved nearly twice. >> > > great. > > BTW did you warm up the server before taking the readings. For lower > concurrencies you are not sending enough messages. Better to vary both > concurrency and messags so that total would be around 50,000. > > thanks, > Amila. > >> >> 8k Message Raw XSLT Mediator Normal XSLT Mediator >> >> Request Per Second Time Taken Request Per Second Time Taken >> >> n=100, c=1 55.97 1.786816 55.89 1.789259 >> n=100, c=5 295.55 1.691735 158.39 3.156814 >> n=100, c=10 298.41 3.351045 162.28 6.162070 >> n=100, c=20 177.38 11.275533 168.38 11.877941 >> n=100, c=40 226.15 17.687198 170.03 23.524984 >> n=100, c=80 187.01 42.778756 165.54 48.325473 >> n=100, c=160 168.49 94.962065 165.00 96.969543 >> n=100, c=320 169.63 188.643735 164.23 194.848353 >> n=100, c=640 165.60 386.484129 122.07 524.308358 >> >> 100k Message Raw XSLT Mediator Normal XSLT Mediator >> >> Reuest Per Second Time Taken Request Per Second Time Taken >> n=100, c=1 49.85 2.005901 12.48 8.012235 >> n=100, c=5 233.87 2.137914 105.34 4.746719 >> n=100, c=10 297.86 3.357259 135.02 7.406090 >> n=100, c=20 294.79 6.784513 159.66 12.526382 >> n=100, c=40 263.21 15.196750 177.38 22.550458 >> n=100, c=80 228.47 35.015699 154.64 51.731678 >> n=100, c=160 230.33 69.465916 132.66 120.606647 >> n=100, c=320 232.24 137.787760 119.52 267.728523 >> n=100, c=640 243.97 262.322362 122.07 524.308358 >> >> Thanks >> AndunSLG >> >> On Sun, Sep 16, 2012 at 3:13 PM, Paul Fremantle <[email protected]> wrote: >> >>> Also presumably this approach would work very simply if someone didn't >>> use SOAP but simply wanted to transform Plain Ole XML. >>> >>> Paul >>> >>> On 16 September 2012 09:37, Andun Sameera <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> +1 For the idea about >>>> the trade-off between Performance and Flexibility. This will solve >>>> the problem I think. Because here I used a XSLT which will transform and >>>> give a element of the message. So If we give the responsibility to the >>>> person who write the transformation to preserve the SOAP message, It will >>>> solve all the issues. >>>> Also will try to find a way to write a extension which will give some >>>> more flexibility to user. >>>> >>>> Thanks >>>> AndunSLG >>>> >>>> >>>> On Sun, Sep 16, 2012 at 12:45 PM, Sanjiva Weerawarana <[email protected] >>>> > wrote: >>>> >>>>> IIRC the old xslt mediator had a "source" parameter to indicate what >>>>> should be sent in. Without that, its correct that we send in the entire >>>>> message - if its SOAP its the whole envelope etc.. If the transform should >>>>> produce a SOAP message that's up to the person to generate it. >>>>> >>>>> So IMO we should call this new high perf XSLT mediator a "raw xslt" >>>>> mediator or something like that and make clear what the responsibility of >>>>> the person writing the transform is. >>>>> >>>>> We could also (later) write an extension that supports a few source >>>>> parameters - e.g. "body" and then do some byte level parsing (a very basic >>>>> xml parser) that strips out the other stuff and passes the body thru. >>>>> >>>>> IMO we don't need that - we have a high perf one that requires you to >>>>> process the whole message and we have the current one which gives you a >>>>> lot >>>>> more flexibility at a performance tradeoff. >>>>> >>>>> So in other words, lets finish this and ship it! >>>>> >>>>> Sanjiva. >>>>> >>>>> On Sun, Sep 16, 2012 at 10:35 AM, Andun Sameera <[email protected]>wrote: >>>>> >>>>>> >>>>>> >>>>>> On Sun, Sep 16, 2012 at 5:50 AM, Hiranya Jayathilaka < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Sep 15, 2012 at 5:19 PM, Hiranya Jayathilaka < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> I don't know for sure whether this problem can be solved. But >>>>>>>> sometime back I wrote a custom mediator to do XSLT transformations >>>>>>>> using >>>>>>>> the StAX support available in the Java TrAX API. It showed a fairly >>>>>>>> good >>>>>>>> performance improvement against the existing implementation too. >>>>>>>> >>>>>>>> Solving the problem mentioned in this thread will be pretty hard. >>>>>>>> Perhaps we can relax the conditions a bit. We can wrap the output of >>>>>>>> the >>>>>>>> transformation in a SOAP envelope and put that back in the data >>>>>>>> handler. We >>>>>>>> will use >>>>>>>> >>>>>>> >>>>>>> s/use/loose/ >>>>>>> >>>>>>> >>>>>>>> any information in the original SOAP headers, but that won't be an >>>>>>>> issue for most practical scenarios. >>>>>>>> >>>>>>> >>>>>> Hi Hiranya, >>>>>> >>>>>> Your argument is correct Hirnaya. But I am also blocked while doing >>>>>> "wrap the output of the transformation in a SOAP envelope", because >>>>>> I don't know which part of the message is transformed. I blindly pass >>>>>> the input stream to transformer, because of the requirement of avoid >>>>>> opening the input stream using AXIOM. So without knowing which part of >>>>>> the >>>>>> message is transformed and given back, how can I find the place to >>>>>> replace >>>>>> in the newly created SOAP envelop. Sometimes it can be Envelop,Body, >>>>>> element etc. >>>>>> So any solution ? >>>>>> >>>>>> Thanks >>>>>> AndunSLG >>>>>> >>>>>> >>>>>>>> Thanks, >>>>>>>> Hiranya >>>>>>>> >>>>>>>> On Sat, Sep 15, 2012 at 9:23 AM, Andun Sameera <[email protected]>wrote: >>>>>>>> >>>>>>>>> Hi Amila, >>>>>>>>> >>>>>>>>> On Sat, Sep 15, 2012 at 9:22 PM, Amila Suriarachchi < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Does xslt engine supports xml stream level transformations? >>>>>>>>> >>>>>>>>> >>>>>>>>> Yes. But not 100% streams, but we can transform StreamSource >>>>>>>>> object to a StreamResult using the Transformer. >>>>>>>>> >>>>>>>>> >>>>>>>>>> After xslt transformations users may want to do further >>>>>>>>>> processing with the message. So in that case we can avoid building >>>>>>>>>> request >>>>>>>>>> Axiom object but may required to create the transformed Axiom object. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Yes your argument is correct, sometimes we have to create the >>>>>>>>> result message. But I got in to trouble even before. In >>>>>>>>> the present scenario, XSLT mediator read some parameters from the >>>>>>>>> request >>>>>>>>> using AXIOM. It read weather transformation is happening to SOAP body >>>>>>>>> or >>>>>>>>> SOAP envelop etc. Based on those parameters after >>>>>>>>> the transformation mediator reform the message. You can fine that >>>>>>>>> logic in >>>>>>>>> [1]<http://wso2.org/svn/browse/wso2/carbon/platform/branches/4.0.0/dependencies/synapse/2.1.0-wso2v7/modules/core/src/main/java/org/apache/synapse/mediators/transform/XSLTMediator.java?view=markup> >>>>>>>>> . >>>>>>>>> >>>>>>>>> But here I have no such parameters, I have only a input stream and >>>>>>>>> I transform it using the XSLT file. After transformation I have no >>>>>>>>> clue >>>>>>>>> to reform the message. What I do is set the output stream to >>>>>>>>> the data-handler in binary relay dummy message. So some parts of the >>>>>>>>> original message get dropped and everything crashes here after. >>>>>>>>> >>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> Amila. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sat, Sep 15, 2012 at 4:16 PM, Andun Sameera <[email protected]>wrote: >>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> My requirement is $Subject. Purpose of this is avoid using AXIOM >>>>>>>>>>> to to XSLT transformation. Our plan was to do all the >>>>>>>>>>> transformation using >>>>>>>>>>> Input, Output Streams. javax.xml.transform.Transformer is used to do >>>>>>>>>>> the transformation using streams. I developed the mediator using >>>>>>>>>>> the following logic, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - In the Binary Relay We get the Message as a Data Handler >>>>>>>>>>> in a Dummy SOAP Message. From that we can get a Input Stream for >>>>>>>>>>> the SOAP >>>>>>>>>>> message which needs to be transformed using XSLT. >>>>>>>>>>> - We can Get the input Stream for the XSLT file, which is in >>>>>>>>>>> registry or local. >>>>>>>>>>> - Using those two we can do the XSLT transformation. As a >>>>>>>>>>> result we get a stream for the transformed SOAP message. >>>>>>>>>>> - Finally I create a DataHandler using the stream and >>>>>>>>>>> attached it to the Relay's Dummy SOAP message replacing existing >>>>>>>>>>> one. >>>>>>>>>>> >>>>>>>>>>> The output of the mediator follows this logic is given below. I >>>>>>>>>>> used the Sample >>>>>>>>>>> 8<http://wso2.org/project/esb/java/4.0.3/docs/samples/message_mediation_samples.html#Sample8>of >>>>>>>>>>> ESB. I replaced the XSLT mediator with my custom mediator in the >>>>>>>>>>> Binary >>>>>>>>>>> Relay. >>>>>>>>>>> But there is a major problem here. Because of the logic we used >>>>>>>>>>> the original SOAP message, >>>>>>>>>>> >>>>>>>>>>> <soapenv:Envelope xmlns:soapenv=" >>>>>>>>>>> http://schemas.xmlsoap.org/soap/envelope/";><soapenv:Header >>>>>>>>>>> xmlns:wsa="http://www.w3.org/2005/08/addressing";><wsa:To> >>>>>>>>>>> http://localhost:9000/services/SimpleStockQuoteService</wsa:To><wsa:MessageID>urn:uuid:0f7403b4-c5bc-4347-8921-562f2736a2ab</wsa:MessageID><wsa:Action>urn:getQuote</wsa:Action></soapenv:Header><soapenv:Body><m0:CheckPriceRequest >>>>>>>>>>> xmlns:m0="http://services.samples >>>>>>>>>>> "><m0:Code>IBM</m0:Code></m0:CheckPriceRequest></soapenv:Body></soapenv:Envelope> >>>>>>>>>>> >>>>>>>>>>> is now converted to. >>>>>>>>>>> >>>>>>>>>>> <m:getQuote xmlns:m="http://services.samples";> >>>>>>>>>>> <m:request> >>>>>>>>>>> <m:symbol>IBM</m:symbol> >>>>>>>>>>> </m:request> >>>>>>>>>>> </m:getQuote> >>>>>>>>>>> >>>>>>>>>>> At the end Binary Relay Formatter will read the DataHandler and >>>>>>>>>>> above SOAP message will be sent to the AXIS2 Server and It will >>>>>>>>>>> crash, >>>>>>>>>>> because this is not a valid SOAP message. >>>>>>>>>>> This problem occurs because we are not using AXIOM anymore. In >>>>>>>>>>> the normal XSLT mediator it >>>>>>>>>>> uses org.apache.synapse.util.xpath.SourceXPathSupport class to find >>>>>>>>>>> the >>>>>>>>>>> part of the message which transformed using XSLT. So it can replace >>>>>>>>>>> the transformed part of the original message. But here we cant use >>>>>>>>>>> that >>>>>>>>>>> kind of a logic. Because we use only streams. We cant build >>>>>>>>>>> OMElements or >>>>>>>>>>> etc. >>>>>>>>>>> >>>>>>>>>>> Need help to solve this problem. The custom mediator java files >>>>>>>>>>> are attached here. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> AndunSLG >>>>>>>>>>> >>>>>>>>>>> References : >>>>>>>>>>> >>>>>>>>>>> [1] - >>>>>>>>>>> http://wso2.org/project/esb/java/4.0.3/docs/samples/message_mediation_samples.html#Sample8 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Console Output for the Custom Mediator : >>>>>>>>>>> >>>>>>>>>>> .....................Original SOAP >>>>>>>>>>> Envelop.......................... >>>>>>>>>>> <?xml version='1.0' encoding='utf-8'?><soapenv:Envelope >>>>>>>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope";><soapenv:Body><ns:binary >>>>>>>>>>> xmlns:ns="http://ws.apache.org/commons/ns/payload >>>>>>>>>>> ">PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz48c29hcGVudjpFbnZlbG9wZSB4bWxuczpzb2FwZW52PSJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy9zb2FwL2VudmVsb3BlLyI+PHNvYXBlbnY6SGVhZGVyIHhtbG5zOndzYT0iaHR0cDovL3d3dy53My5vcmcvMjAwNS8wOC9hZGRyZXNzaW5nIj48d3NhOlRvPmh0dHA6Ly9sb2NhbGhvc3Q6OTAwMC9zZXJ2aWNlcy9TaW1wbGVTdG9ja1F1b3RlU2VydmljZTwvd3NhOlRvPjx3c2E6TWVzc2FnZUlEPnVybjp1dWlkOjBmNzQwM2I0LWM1YmMtNDM0Ny04OTIxLTU2MmYyNzM2YTJhYjwvd3NhOk1lc3NhZ2VJRD48d3NhOkFjdGlvbj51cm46Z2V0UXVvdGU8L3dzYTpBY3Rpb24+PC9zb2FwZW52OkhlYWRlcj48c29hcGVudjpCb2R5PjxtMDpDaGVja1ByaWNlUmVxdWVzdCB4bWxuczptMD0iaHR0cDovL3NlcnZpY2VzLnNhbXBsZXMiPjxtMDpDb2RlPklCTTwvbTA6Q29kZT48L20wOkNoZWNrUHJpY2VSZXF1ZXN0Pjwvc29hcGVudjpCb2R5Pjwvc29hcGVudjpFbnZlbG9wZT4=</ns:binary></soapenv:Body></soapenv:Envelope> >>>>>>>>>>> >>>>>>>>>>> ................................................................................ >>>>>>>>>>> >>>>>>>>>>> .....................Original SOAP >>>>>>>>>>> Message........................ >>>>>>>>>>> <soapenv:Envelope xmlns:soapenv=" >>>>>>>>>>> http://schemas.xmlsoap.org/soap/envelope/";><soapenv:Header >>>>>>>>>>> xmlns:wsa="http://www.w3.org/2005/08/addressing";><wsa:To> >>>>>>>>>>> http://localhost:9000/services/SimpleStockQuoteService</wsa:To><wsa:MessageID>urn:uuid:0f7403b4-c5bc-4347-8921-562f2736a2ab</wsa:MessageID><wsa:Action>urn:getQuote</wsa:Action></soapenv:Header><soapenv:Body><m0:CheckPriceRequest >>>>>>>>>>> xmlns:m0="http://services.samples >>>>>>>>>>> "><m0:Code>IBM</m0:Code></m0:CheckPriceRequest></soapenv:Body></soapenv:Envelope> >>>>>>>>>>> >>>>>>>>>>> ................................................................................ >>>>>>>>>>> >>>>>>>>>>> Transforming On Progress..... >>>>>>>>>>> >>>>>>>>>>> ...................Transformed SOAP Message................... >>>>>>>>>>> <m:getQuote xmlns:m="http://services.samples";> >>>>>>>>>>> <m:request> >>>>>>>>>>> <m:symbol>IBM</m:symbol> >>>>>>>>>>> </m:request> >>>>>>>>>>> </m:getQuote> >>>>>>>>>>> >>>>>>>>>>> .............................................................................. >>>>>>>>>>> >>>>>>>>>>> ...................Transformed SOAP Envelop.................. >>>>>>>>>>> <?xml version='1.0' encoding='utf-8'?><soapenv:Envelope >>>>>>>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope";><soapenv:Body><ns:binary >>>>>>>>>>> xmlns:ns="http://ws.apache.org/commons/ns/payload >>>>>>>>>>> ">PG06Z2V0UXVvdGUgeG1sbnM6bT0iaHR0cDovL3NlcnZpY2VzLnNhbXBsZXMiPgogICA8bTpyZXF1ZXN0PgogICAgICA8bTpzeW1ib2w+SUJNPC9tOnN5bWJvbD4KICAgPC9tOnJlcXVlc3Q+CjwvbTpnZXRRdW90ZT4K</ns:binary></soapenv:Body></soapenv:Envelope> >>>>>>>>>>> >>>>>>>>>>> .............................................................................. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *Amila Suriarachchi* >>>>>>>>>> >>>>>>>>>> Software Architect >>>>>>>>>> WSO2 Inc. ; http://wso2.com >>>>>>>>>> lean . enterprise . middleware >>>>>>>>>> >>>>>>>>>> phone : +94 71 3082805 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Any suggestions to overcome this problem ? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> AndunSLG >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> http://wso2.org/svn/browse/wso2/carbon/platform/branches/4.0.0/dependencies/synapse/2.1.0-wso2v7/modules/core/src/main/java/org/apache/synapse/mediators/transform/XSLTMediator.java?view=markup >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Dev mailing list >>>>>>>>> [email protected] >>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Hiranya Jayathilaka >>>>>>>> Mayhem Lab/RACE Lab; >>>>>>>> Dept. of Computer Science, UCSB; http://cs.ucsb.edu >>>>>>>> E-mail: [email protected] <[email protected]>; Mobile: +1 (805) >>>>>>>> 895-7443 >>>>>>>> Blog: http://techfeast-hiranya.blogspot.com >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Hiranya Jayathilaka >>>>>>> Mayhem Lab/RACE Lab; >>>>>>> Dept. of Computer Science, UCSB; http://cs.ucsb.edu >>>>>>> E-mail: [email protected] <[email protected]>; Mobile: +1 (805) >>>>>>> 895-7443 >>>>>>> Blog: http://techfeast-hiranya.blogspot.com >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> [email protected] >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Sanjiva Weerawarana, Ph.D. >>>>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ >>>>> email: [email protected]; phone: +94 11 763 9614; cell: +94 77 787 6880| +1 >>>>> 650 265 8311 >>>>> blog: http://sanjiva.weerawarana.org/ >>>>> >>>>> Lean . Enterprise . Middleware >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >>> >>> -- >>> Paul Fremantle >>> CTO and Co-Founder, WSO2 >>> OASIS WS-RX TC Co-chair, VP, Apache Synapse >>> >>> UK: +44 207 096 0336 >>> US: +1 646 595 7614 >>> >>> blog: http://pzf.fremantle.org >>> twitter.com/pzfreo >>> [email protected] >>> >>> wso2.com Lean Enterprise Middleware >>> >>> Disclaimer: This communication may contain privileged or other >>> confidential information and is intended exclusively for the addressee/s. >>> If you are not the intended recipient/s, or believe that you may have >>> received this communication in error, please reply to the sender indicating >>> that fact and delete the copy you received and in addition, you should not >>> print, copy, retransmit, disseminate, or otherwise use the information >>> contained in this communication. Internet communications cannot be >>> guaranteed to be timely, secure, error or virus-free. The sender does not >>> accept liability for any errors or omissions. >>> >>> >> > > > -- > *Amila Suriarachchi* > > Software Architect > WSO2 Inc. ; http://wso2.com > lean . enterprise . middleware > > phone : +94 71 3082805 > >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
