You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by "SHEREEF ABDULLA (JIRA)" <xe...@xml.apache.org> on 2007/09/13 20:31:32 UTC
[jira] Created: (XERCESJ-1268) parsing bix XMLs take very long
time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to
complete parsing and start processing web service.
parsing bix XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Key: XERCESJ-1268
URL: https://issues.apache.org/jira/browse/XERCESJ-1268
Project: Xerces2-J
Issue Type: Improvement
Components: DOM (Level 3 Core)
Environment: Operating System: All
Platform: All
Reporter: SHEREEF ABDULLA
parsing bix XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.
Observed that the SOAP messages are read line by line and CharacterDataImpl.append() is getting called for each line. This appends each line to the string data which stores the previously read xml part. This call results in many string additions (say 20000+ for 1MB SOAP) of big string and the thread is most of the time blocked in StringBuilder.expandcapacity due to long string additions.
JAX RPC webservice with SOAP messages bigger than 1MB take 5 mins and more just for the web service implementation to start working as the jaxrpc does a SOAPMessage.getenvelop call to do HandlerChainImpl.checkMustUnderstand() checking for the request message header. Same problem happens for response also. for time being we commented checkMustUnderstand method so that the parsing doesn't happen at all.
String additions for each of the lines would have been avoided, either by creating the whole data single time or using string buffer instead of string. I tried to modify the data field to use StringBuffer instead of String but the underlying CoreDocumentImpl.modifiedCharacterData() and all underlying calls takes the string params so couldn't go ahead with it.
bug # XERCESJ-102 looks like the same issue..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Issue Comment Edited: (XERCESJ-1268) parsing bix XMLs take
very long time. A JAXRPC webservice request of soap size 2MB takes above 5
mins to complete parsing and start processing web service.
Posted by "Michael Glavassevich (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESJ-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527218 ]
mrglavas@ca.ibm.com edited comment on XERCESJ-1268 at 9/13/07 12:02 PM:
-------------------------------------------------------------------------
The application you've described here is using the DOM API inefficiently. A Text node is not a StringBuffer. The result of calling appendData() is a new string value for the Node so it's not surprising that it's slow if you keep calling it in this way. Text should be accumulated in a real buffer before setting it on the Text node. Your improvement request should be re-directed to whichever application is using the DOM in this way. We can't change the API.
was (Author: mrglavas@ca.ibm.com):
The application you've described here is using the DOM API inefficiently. A Text node is not a StringBuffer. The result of calling appendData() is a new string value for the Node so it's not surprising that it's slow if you keep calling it in this way. Text should be accumulated in real buffer before setting it on the Text node. Your improvement request should be re-directed to whichever application is using the DOM in this way. We can't change the API.
> parsing bix XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1268
> URL: https://issues.apache.org/jira/browse/XERCESJ-1268
> Project: Xerces2-J
> Issue Type: Improvement
> Components: DOM (Level 3 Core)
> Environment: Operating System: All
> Platform: All
> Reporter: SHEREEF ABDULLA
> Attachments: JaxRPCProcessRequest.java, WrkingBigSOAP.txt
>
>
> parsing bix XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.
> Observed that the SOAP messages are read line by line and CharacterDataImpl.append() is getting called for each line. This appends each line to the string data which stores the previously read xml part. This call results in many string additions (say 20000+ for 1MB SOAP) of big string and the thread is most of the time blocked in StringBuilder.expandcapacity due to long string additions.
> JAX RPC webservice with SOAP messages bigger than 1MB take 5 mins and more just for the web service implementation to start working as the jaxrpc does a SOAPMessage.getenvelop call to do HandlerChainImpl.checkMustUnderstand() checking for the request message header. Same problem happens for response also. for time being we commented checkMustUnderstand method so that the parsing doesn't happen at all.
> String additions for each of the lines would have been avoided, either by creating the whole data single time or using string buffer instead of string. I tried to modify the data field to use StringBuffer instead of String but the underlying CoreDocumentImpl.modifiedCharacterData() and all underlying calls takes the string params so couldn't go ahead with it.
> bug # XERCESJ-102 looks like the same issue..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Reopened: (XERCESJ-1268) parsing bix XMLs take very long
time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to
complete parsing and start processing web service.
Posted by "SHEREEF ABDULLA (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESJ-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
SHEREEF ABDULLA reopened XERCESJ-1268:
--------------------------------------
The attached java class is just to compare the performance difference b/w String and StringBuffer, and to illustrate the performance degredation caused by calling the CharacterDataImpl.appendData(), for each lines in the SOAP message.
The XML Parser is doing this call for each lines of the SOAP Message so when the JAXRPC Web service request with around 1 MB takes more than 5 mins to parse the message and to return the envelop.
Given down the complete thread stacktrace which leads to the appendData() method call..
"http18001-Processor4" daemon prio=6 tid=0x2db16d10 nid=0x180 runnable [0x3092d000..0x3092fa18]
at java.lang.String.<init>(String.java:208)
at java.lang.StringBuffer.toString(StringBuffer.java:586)
- locked <0x05370030> (a java.lang.StringBuffer)
at org.apache.xerces.dom.CharacterDataImpl.appendData(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.SAX2DOM.characters(SAX2DOM.java:88)
at com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.characters(ToXMLSAXHandler.java:542)
at org.xml.sax.helpers.XMLFilterImpl.characters(XMLFilterImpl.java:564)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.characters(AbstractSAXParser.java:570)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanCDATASection(XMLDocumentFragmentScannerImpl.java:1160)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1740)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:588)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:642)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:281)
at com.sun.xml.messaging.saaj.soap.EnvelopeFactory.createEnvelope(EnvelopeFactory.java:82)
at com.sun.xml.messaging.saaj.soap.ver1_1.SOAPPart1_1Impl.createEnvelopeFromSource(SOAPPart1_1Impl.java:34)
at com.sun.xml.messaging.saaj.soap.SOAPPartImpl.getEnvelope(SOAPPartImpl.java:82)
at com.sun.xml.rpc.client.HandlerChainImpl.checkMustUnderstand(HandlerChainImpl.java:209)
at com.sun.xml.rpc.server.StreamingHandler.callRequestHandlers(StreamingHandler.java:684)
at com.sun.xml.rpc.server.StreamingHandler.preHandlingHook(StreamingHandler.java:629)
at com.sun.xml.rpc.server.StreamingHandler.handle(StreamingHandler.java:70)
at com.sun.xml.rpc.server.http.JAXRPCServletDelegate.doPost(JAXRPCServletDelegate.java:316)
at com.sun.xml.rpc.server.http.JAXRPCServlet.doPost(JAXRPCServlet.java:74)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:768)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:861)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:289)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:318)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:205)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:283)
at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:102)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:192)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:263)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:156)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:569)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:261)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:215)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:156)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:569)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:200)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:156)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:180)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:154)
at com.sun.enterprise.webservice.EjbWebServiceValve.invoke(EjbWebServiceValve.java:134)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:154)
at com.sun.enterprise.security.web.SingleSignOn.invoke(SingleSignOn.java:254)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:154)
at com.sun.enterprise.web.VirtualServerValve.invoke(VirtualServerValve.java:209)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:154)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:569)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:161)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:156)
at com.sun.enterprise.web.VirtualServerMappingValve.invoke(VirtualServerMappingValve.java:173)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:154)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:569)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:979)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:211)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:692)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:647)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:589)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:691)
at java.lang.Thread.run(Thread.java:595)
> parsing bix XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1268
> URL: https://issues.apache.org/jira/browse/XERCESJ-1268
> Project: Xerces2-J
> Issue Type: Improvement
> Components: DOM (Level 3 Core)
> Environment: Operating System: All
> Platform: All
> Reporter: SHEREEF ABDULLA
> Attachments: JaxRPCProcessRequest.java, WrkingBigSOAP.txt
>
>
> parsing bix XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.
> Observed that the SOAP messages are read line by line and CharacterDataImpl.append() is getting called for each line. This appends each line to the string data which stores the previously read xml part. This call results in many string additions (say 20000+ for 1MB SOAP) of big string and the thread is most of the time blocked in StringBuilder.expandcapacity due to long string additions.
> JAX RPC webservice with SOAP messages bigger than 1MB take 5 mins and more just for the web service implementation to start working as the jaxrpc does a SOAPMessage.getenvelop call to do HandlerChainImpl.checkMustUnderstand() checking for the request message header. Same problem happens for response also. for time being we commented checkMustUnderstand method so that the parsing doesn't happen at all.
> String additions for each of the lines would have been avoided, either by creating the whole data single time or using string buffer instead of string. I tried to modify the data field to use StringBuffer instead of String but the underlying CoreDocumentImpl.modifiedCharacterData() and all underlying calls takes the string params so couldn't go ahead with it.
> bug # XERCESJ-102 looks like the same issue..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Issue Comment Edited: (XERCESJ-1268) parsing bix XMLs take
very long time. A JAXRPC webservice request of soap size 2MB takes above 5
mins to complete parsing and start processing web service.
Posted by "SHEREEF ABDULLA (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESJ-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527214 ]
sabdulla edited comment on XERCESJ-1268 at 9/13/07 11:45 AM:
--------------------------------------------------------------------
Attached test program 'JaxRPCProcessRequest.java' reads a 900KB SOAP message line by line and adds them by using different method; StringBuffer, String and xerces.dom.TextImpl.appendData(which is used by xerces), and I got the following time metrics
Method time in milli sec
StringBuffer 140
String 638532
TextImpl 639687
Each string addition takes around 30-45 ms when the XML data is big. which causes very long time for big SOAP messages and most of the time client wait time out..
was (Author: sabdulla):
Attached test program 'JaxRPCProcessRequest.java' reads a 900KB SOAP message line by line and adds them by using different method; StringBuffer, String and xerces.dom.TextImpl(which is used by xerces), and I got the following time metrics
Method time in milli sec
StringBuffer 140
String 638532
TextImpl 639687
Each string addition takes around 30-45 ms when the XML data is big. which causes very long time for big SOAP messages and most of the time client wait time out..
> parsing bix XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1268
> URL: https://issues.apache.org/jira/browse/XERCESJ-1268
> Project: Xerces2-J
> Issue Type: Improvement
> Components: DOM (Level 3 Core)
> Environment: Operating System: All
> Platform: All
> Reporter: SHEREEF ABDULLA
> Attachments: JaxRPCProcessRequest.java, WrkingBigSOAP.txt
>
>
> parsing bix XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.
> Observed that the SOAP messages are read line by line and CharacterDataImpl.append() is getting called for each line. This appends each line to the string data which stores the previously read xml part. This call results in many string additions (say 20000+ for 1MB SOAP) of big string and the thread is most of the time blocked in StringBuilder.expandcapacity due to long string additions.
> JAX RPC webservice with SOAP messages bigger than 1MB take 5 mins and more just for the web service implementation to start working as the jaxrpc does a SOAPMessage.getenvelop call to do HandlerChainImpl.checkMustUnderstand() checking for the request message header. Same problem happens for response also. for time being we commented checkMustUnderstand method so that the parsing doesn't happen at all.
> String additions for each of the lines would have been avoided, either by creating the whole data single time or using string buffer instead of string. I tried to modify the data field to use StringBuffer instead of String but the underlying CoreDocumentImpl.modifiedCharacterData() and all underlying calls takes the string params so couldn't go ahead with it.
> bug # XERCESJ-102 looks like the same issue..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Commented: (XERCESJ-1268) parsing big XMLs take very long
time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to
complete parsing and start processing web service.
Posted by "Michael Glavassevich (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESJ-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527317 ]
Michael Glavassevich commented on XERCESJ-1268:
-----------------------------------------------
The stack trace that you've posted shows that you're using Sun's implementation of JAXP (note all of the com.sun.org.apache.* classes). Specifically their fork of XSLTC from the Xalan project is the one constructing the DOM using appendData() so it's not the parser that's calling this method. Looks like this commit [1] to Xalan might be the culprit of this perf issue. Going to transfer this JIRA issue over to them.
[1] http://svn.apache.org/viewvc/xalan/java/trunk/src/org/apache/xalan/xsltc/trax/SAX2DOM.java?r1=337874&r2=338001&diff_format=h
> parsing big XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1268
> URL: https://issues.apache.org/jira/browse/XERCESJ-1268
> Project: Xerces2-J
> Issue Type: Improvement
> Components: DOM (Level 3 Core)
> Environment: Operating System: All
> Platform: All
> Reporter: SHEREEF ABDULLA
> Attachments: JaxRPCProcessRequest.java, WrkingBigSOAP.txt
>
>
> parsing bix XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.
> Observed that the SOAP messages are read line by line and CharacterDataImpl.append() is getting called for each line. This appends each line to the string data which stores the previously read xml part. This call results in many string additions (say 20000+ for 1MB SOAP) of big string and the thread is most of the time blocked in StringBuilder.expandcapacity due to long string additions.
> JAX RPC webservice with SOAP messages bigger than 1MB take 5 mins and more just for the web service implementation to start working as the jaxrpc does a SOAPMessage.getenvelop call to do HandlerChainImpl.checkMustUnderstand() checking for the request message header. Same problem happens for response also. for time being we commented checkMustUnderstand method so that the parsing doesn't happen at all.
> String additions for each of the lines would have been avoided, either by creating the whole data single time or using string buffer instead of string. I tried to modify the data field to use StringBuffer instead of String but the underlying CoreDocumentImpl.modifiedCharacterData() and all underlying calls takes the string params so couldn't go ahead with it.
> bug # XERCESJ-102 looks like the same issue..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Resolved: (XERCESJ-1268) parsing bix XMLs take very long
time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to
complete parsing and start processing web service.
Posted by "Michael Glavassevich (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESJ-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Glavassevich resolved XERCESJ-1268.
-------------------------------------------
Resolution: Won't Fix
The application you've described here is using the DOM API inefficiently. A Text node is not a StringBuffer. The result of calling appendData() is a new string value for the Node so it's not surprising that it's slow if you keep calling it in this way. Text should be accumulated in real buffer before setting it on the Text node. Your improvement request should be re-directed to whichever application is using the DOM in this way. We can't change the API.
> parsing bix XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1268
> URL: https://issues.apache.org/jira/browse/XERCESJ-1268
> Project: Xerces2-J
> Issue Type: Improvement
> Components: DOM (Level 3 Core)
> Environment: Operating System: All
> Platform: All
> Reporter: SHEREEF ABDULLA
> Attachments: JaxRPCProcessRequest.java, WrkingBigSOAP.txt
>
>
> parsing bix XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.
> Observed that the SOAP messages are read line by line and CharacterDataImpl.append() is getting called for each line. This appends each line to the string data which stores the previously read xml part. This call results in many string additions (say 20000+ for 1MB SOAP) of big string and the thread is most of the time blocked in StringBuilder.expandcapacity due to long string additions.
> JAX RPC webservice with SOAP messages bigger than 1MB take 5 mins and more just for the web service implementation to start working as the jaxrpc does a SOAPMessage.getenvelop call to do HandlerChainImpl.checkMustUnderstand() checking for the request message header. Same problem happens for response also. for time being we commented checkMustUnderstand method so that the parsing doesn't happen at all.
> String additions for each of the lines would have been avoided, either by creating the whole data single time or using string buffer instead of string. I tried to modify the data field to use StringBuffer instead of String but the underlying CoreDocumentImpl.modifiedCharacterData() and all underlying calls takes the string params so couldn't go ahead with it.
> bug # XERCESJ-102 looks like the same issue..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Commented: (XERCESJ-1268) parsing bix XMLs take very long
time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to
complete parsing and start processing web service.
Posted by "SHEREEF ABDULLA (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESJ-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527283 ]
SHEREEF ABDULLA commented on XERCESJ-1268:
------------------------------------------
When the SOAP Message size is about 4MB it leads to indefenite block of the thread due to String capacity increment issues..
> parsing bix XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1268
> URL: https://issues.apache.org/jira/browse/XERCESJ-1268
> Project: Xerces2-J
> Issue Type: Improvement
> Components: DOM (Level 3 Core)
> Environment: Operating System: All
> Platform: All
> Reporter: SHEREEF ABDULLA
> Attachments: JaxRPCProcessRequest.java, WrkingBigSOAP.txt
>
>
> parsing bix XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.
> Observed that the SOAP messages are read line by line and CharacterDataImpl.append() is getting called for each line. This appends each line to the string data which stores the previously read xml part. This call results in many string additions (say 20000+ for 1MB SOAP) of big string and the thread is most of the time blocked in StringBuilder.expandcapacity due to long string additions.
> JAX RPC webservice with SOAP messages bigger than 1MB take 5 mins and more just for the web service implementation to start working as the jaxrpc does a SOAPMessage.getenvelop call to do HandlerChainImpl.checkMustUnderstand() checking for the request message header. Same problem happens for response also. for time being we commented checkMustUnderstand method so that the parsing doesn't happen at all.
> String additions for each of the lines would have been avoided, either by creating the whole data single time or using string buffer instead of string. I tried to modify the data field to use StringBuffer instead of String but the underlying CoreDocumentImpl.modifiedCharacterData() and all underlying calls takes the string params so couldn't go ahead with it.
> bug # XERCESJ-102 looks like the same issue..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Updated: (XERCESJ-1268) parsing big XMLs take very long
time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to
complete parsing and start processing web service.
Posted by "SHEREEF ABDULLA (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESJ-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
SHEREEF ABDULLA updated XERCESJ-1268:
-------------------------------------
Summary: parsing big XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service. (was: parsing bix XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.)
> parsing big XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1268
> URL: https://issues.apache.org/jira/browse/XERCESJ-1268
> Project: Xerces2-J
> Issue Type: Improvement
> Components: DOM (Level 3 Core)
> Environment: Operating System: All
> Platform: All
> Reporter: SHEREEF ABDULLA
> Attachments: JaxRPCProcessRequest.java, WrkingBigSOAP.txt
>
>
> parsing bix XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.
> Observed that the SOAP messages are read line by line and CharacterDataImpl.append() is getting called for each line. This appends each line to the string data which stores the previously read xml part. This call results in many string additions (say 20000+ for 1MB SOAP) of big string and the thread is most of the time blocked in StringBuilder.expandcapacity due to long string additions.
> JAX RPC webservice with SOAP messages bigger than 1MB take 5 mins and more just for the web service implementation to start working as the jaxrpc does a SOAPMessage.getenvelop call to do HandlerChainImpl.checkMustUnderstand() checking for the request message header. Same problem happens for response also. for time being we commented checkMustUnderstand method so that the parsing doesn't happen at all.
> String additions for each of the lines would have been avoided, either by creating the whole data single time or using string buffer instead of string. I tried to modify the data field to use StringBuffer instead of String but the underlying CoreDocumentImpl.modifiedCharacterData() and all underlying calls takes the string params so couldn't go ahead with it.
> bug # XERCESJ-102 looks like the same issue..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Updated: (XERCESJ-1268) parsing bix XMLs take very long
time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to
complete parsing and start processing web service.
Posted by "SHEREEF ABDULLA (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESJ-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
SHEREEF ABDULLA updated XERCESJ-1268:
-------------------------------------
Attachment: WrkingBigSOAP.txt
JaxRPCProcessRequest.java
Attached test program 'JaxRPCProcessRequest.java' reads a 900KB SOAP message line by line and adds them by using different method; StringBuffer, String and xerces.dom.TextImpl(which is used by xerces), and I got the following time metrics
Method time in milli sec
StringBuffer 140
String 638532
TextImpl 639687
Each string addition takes around 30-45 ms when the XML data is big. which causes very long time for big SOAP messages and most of the time client wait time out..
> parsing bix XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1268
> URL: https://issues.apache.org/jira/browse/XERCESJ-1268
> Project: Xerces2-J
> Issue Type: Improvement
> Components: DOM (Level 3 Core)
> Environment: Operating System: All
> Platform: All
> Reporter: SHEREEF ABDULLA
> Attachments: JaxRPCProcessRequest.java, WrkingBigSOAP.txt
>
>
> parsing bix XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.
> Observed that the SOAP messages are read line by line and CharacterDataImpl.append() is getting called for each line. This appends each line to the string data which stores the previously read xml part. This call results in many string additions (say 20000+ for 1MB SOAP) of big string and the thread is most of the time blocked in StringBuilder.expandcapacity due to long string additions.
> JAX RPC webservice with SOAP messages bigger than 1MB take 5 mins and more just for the web service implementation to start working as the jaxrpc does a SOAPMessage.getenvelop call to do HandlerChainImpl.checkMustUnderstand() checking for the request message header. Same problem happens for response also. for time being we commented checkMustUnderstand method so that the parsing doesn't happen at all.
> String additions for each of the lines would have been avoided, either by creating the whole data single time or using string buffer instead of string. I tried to modify the data field to use StringBuffer instead of String but the underlying CoreDocumentImpl.modifiedCharacterData() and all underlying calls takes the string params so couldn't go ahead with it.
> bug # XERCESJ-102 looks like the same issue..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org