Hi all, This is not the case of a big document, only around 1Kb.
Well I dont exclude a network problem, since I assume that if data does not come through, the parser obviously cannot return from the call. Thanks for illuminating me with that. I will do some more investigation. best regards, Josef On 2/20/06, John Wilson <[EMAIL PROTECTED]> wrote: > > > On 20 Feb 2006, at 12:51, Jochen Wiedmann wrote: > > > > >> Seems like the call to parser.parse( ) at XmlRpc.java method parse > >> ( ) is the > >> culprit. There seem to be some occasions where this is taking 3 > >> seconds. > > > > Assuming that your document isn't overly large, this is extraordinary. > > > > How does the document look like? (Use a program like tcpmon, if you > > are unsure.) Does it contain a document type declaration, an external > > entity reference, or something similar? That's the only idea, I would > > have. (And, clearly, this can only occur, if the client is *not* an > > Apache XML-RPC client.) > > > If he's using MinML then things like external DTD subsets will not > make any difference to the speed of the parse. > > Measuring the time to parse is also measuring the time to read the > document. I would guess we are seeing some sort of network problem here. > > This also measures the time to execute the SAX callbacks. However we > don't do anything very complex in the callback. It's just possible > that a very big Base64 decode could be taking a long time but I'd be > very surprised if this was the case. > > If it's really a MinML problem I'd be delighted to see the document > which causes the problem - It's been three or four years since I've > had a bug reported;) > > > John Wilson > The Wilson Partnership > http://www.wilson.co.uk > > >
